Suggestion: Programmable Block implementation

DasBaconfist shared this feedback ago

Submitted

As you all know, there are some limitations to the PB.

I think most of this limitations are there to prevent slowing down the game to much.

The problem is: We want to do more than just display roomnames above doors.

In the current implementation the PB scripts are somewhat inbetween the frames. just like: do physics and gamestuff -> do PB scripts -> do physics and game stuff -> ... .

What about an Programmable block Thread?

If the PB scripts would be run in an dedicated Thred, they wont slow down the game anymore.

To accomplish this in a useable way I have an Idea.

First: you can't just push all scripts to an extra thread. that would lead to inconsistency.

I'll call the Thread for Programmable Block Script PB-Thread and everything else Game-Thread (Game-Thread is everything else no matteer how many threads)

The PB-Thread handles all the scripts and runs them.

1. The Game-Thread sends a request with current block/grid states to the PB-Thread if it has any block-changes to be assigned (like "open this door" or "set lcd text to whatever")

2. Game-Thread looks if PB-Thread is done running the scripts. If NOT => skip it an look on the next update. (This way a long running script will only affect other scripts and not the whole game)

3. If PB-Thread is done: apply changes from Scripts and continue at step 1

I like this feedback

Replies (1)

Vissery ●

Multithreading is one of those ideas that might sound very promising at first glance, but reveal many pitfalls once investigated further.

In this particular case, the most obvious one is that of the "Race condition". If a script runs uninterrupted through multiple consecutive ticks, the game state it has to work with will constantly and unpredictably change.

Consider:

[PB] Suppose an inventory manager makes a certain assertion ("There's a [QUANTITY] of [ITEMTYPE] in the [SLOT]"), and...
[PB] ...tries to do something that depends on it ("Move items from [SLOT] to the [ASSEMBLER]")...
[GT] But just after the assertion (1) is successfully made, the game proceeds with the next tick:
[GT] The game state changes (a collector sucks in the item)...
[PB] ...and then the action segment (2) crashes with an exception ("I can't move [ITEM]! There's nothing in the [SLOT]!!!").

The "floating" bugs caused by this are hard as hecc to catch and debug, and a curse of all programmers who work with multithreading.

And what of conditions that depend on the immediate result of block changes - like performing an attachment (rotors, connectors, etc.) and acting on the blocks of the other grid? This one, granted, is not a blocking issue, simply something that slightly restricts PB utility and needed to be kept in mind when programming (do a connection and then poll until the game reports it as successful) - however, if the suggested behavior is implemented in the future, it would introduce backwards incompatibility with some of the existing scripts, which could be downright frustrating for users who download old scripts that are polished out, have good reviews and seem to work well... but unexpectedly break at a completely random moment.

As much as I appreciate the concept of multithreading Programmable Blocks, I'm afraid it's simply not as easy as you are suggesting.

Reply URL

DasBaconfist ●

I understand wehat xou mean. Im aware of the Problems. But most problems could be handled by the game itself. maybe an inventory you want to move items to is now full or the item itself is gone. I mean, just throw an "ItemNotFound" Exeption or someting like this. Sure, you have to add Exeptionhandling in your scripts. On the other hand they could a "RetryOnExeption" checkbox or a Multithreading Compiler flag in the script. So older scripts could work in "old-mode" and after some time remove the flag. And I know how this sound like :-p.

My Intension is to decouple the PB's performance issues from the game itself.

URL