Submit Feedback
Space Engineers PC SupportTopicFeedback
Properties
Category Uncategorized

A way to move Programmagle block out of experimental mode

Timotei~ shared this feedback 6 years ago
Submitted

As I understand, the programmable block was moved to experimental mode due to it's unpredictable performances strain and so, it's PCU score can't be defined.

But what if the user could define the PCU by himself?

My idea it to implement a configurable watchdog on the programmable block. This watchdog would make sure the script runs within a predefined time. Otherwise, the watchdog will stop the execution and lock the PB until recompiled.


The time limit of that watchdog would be directly linked to the PCU cost of the PB and could be adjusted at the compilation time by the user.

That way, a small airlock script that runs fast could be set to cost less PCU than an heavy inventory management scripts.

Thank you for your attention. Please tell me if this is a good or bad idea.

16 I like this feedback
Best Answer
photo
Malware ● 6 years ago

We've wanted to do this ever since the beginning, but I'm afraid you can't arbitrarily kill the PB after an arbitrary time. It's not running on an interpreter or anything like that. It's normal compiled code just like the game itself. It's not running on a thread but the main game thread, because the game engine isn't threadsafe and there's no threadsafe layer between the PB and the game. Even if you could kill it, it might very well be in the middle of changing some game state... and then you're in an undefined state which is quite likely to either crash your game or at best glitch it out badly. We've spent a lot of time trying to solve these issues. The only real solution I see is a complete PB API rewrite, to separate it and make it threadsafe, and I can't say I see that happening any time soon. It would also probably break a whole lot if not all scripts out there. I would do this job as well if I knew it would be merged and had a chance at making it go into non-experimental mode.

Replies (2)

photo
4
Malware ● 6 years ago ●

We've wanted to do this ever since the beginning, but I'm afraid you can't arbitrarily kill the PB after an arbitrary time. It's not running on an interpreter or anything like that. It's normal compiled code just like the game itself. It's not running on a thread but the main game thread, because the game engine isn't threadsafe and there's no threadsafe layer between the PB and the game. Even if you could kill it, it might very well be in the middle of changing some game state... and then you're in an undefined state which is quite likely to either crash your game or at best glitch it out badly. We've spent a lot of time trying to solve these issues. The only real solution I see is a complete PB API rewrite, to separate it and make it threadsafe, and I can't say I see that happening any time soon. It would also probably break a whole lot if not all scripts out there. I would do this job as well if I knew it would be merged and had a chance at making it go into non-experimental mode.

Reply
photo
1
Timotei~ ● 6 years ago

Thank you @Malware for this clarification. I was expecting C# to have a way to monitor execution using time based error trowing and thread monitoring like I saw was possible in python. But as you said C# is not an interpreted language like python and so they can't really be compared. I should have checked before suggesting this. Anyway, I think your answer will be informative for anyone wondering why using watchdog is not possible.

photo
1
Malware ● 6 years ago

Oh if we could run the PB on a thread, we could have killed it after a time - but not without the outlined consequences. It's one of the options we considered.

photo
2
Mike Mortensen ● 6 years ago

I would love it if the Pb got some attention.This game is not the same without PB or pressurization.

photo
1
Dragonmaster_42 ● 6 years ago

Some much great scripts would be lost forever, if the PB was gone...

I would most likely stop playing.

photo
1
Zoli K. ● 6 years ago

What about this approach: the script code of the BP is called again and again by the game logic, so what if for scripts that do not fall into the permitted execution time limits (based on the measurements done by watchdog logic OP suggested) their code will not be called but exception thrown saying smthing like "Sorry, script does not seem to fit into script constrains set on this server, pls revise" ?

photo
1
Malware ● 6 years ago

I'm afraid that isn't good enough, since it's possible - with just a little bit of knowhow - to write a script that is not only slow but will never terminate on its own.

photo
1
Patrick van der Willik ● 5 years ago

One of the ways to accomplish (better) isolation would be to wrap all the available interfaces in a proxy(Castle Proxies ftw) that would collect all issued commands (such as WritePublicText on an LCD and ClearQueue on an Assembler). Instead of executing all the commands directly, the proxy would cache the calls(with the parameters) and after running all the PB threads, the issued commands would be collected and executed on the main thread.


This kind of isolation is relatively easy and has probably been tried but even if it hasn't been tried yet: cancelling the thread of a PB that an evil (or unknowing) user sent into an infinite loop using a while (true) loop is still not possible. Sure, there is Thread.Abort() but since it is impossible to know what kind of code is running inside the PB, calling Abort() at just the wrong time could result in the entire application locking up due to heap locks(which is the reason that the .NET framework discourages the use of Thread.Abort, and in .NET Core the method in its entirety was removed).


I suppose the devs could have a proxy throw a ThreadAbortedException once the timeout expires and block all the PBs of a user from running if at least one thread doesn't terminate within the timeout period but that would still keep at least 1 thread running wild. And on top of that it still brings a lot of additional complexities with it, such as ensuring that reading from a proxied object doesn't give incomplete/invalid results, synchronization issues while waiting for PB threads to run and finish their tasks.


While it's a bummer(I only recently bought the game, less than 24 hours played) and I absolutely love automating all the things in the game. On the other end, since I play single player for the creative survival experience, I don't mind running the experimental mode.

photo
1
Malware ● 5 years ago

That has indeed already been considered, of course, Patrick. The problem is that it's a large amount of work for a small fraction of the user base, and still doesn't eliminate all the reasons why the PB is experimental. And you are of course completely right about the thread/abort, that is quite simply not an option.

photo
1
Patrick van der Willik ● 5 years ago

My reply was mostly meant as agreeing with the point you made and that the complexity of this change isn't something to be underestimated.


By glancing around the forum it appears you either have close relations with Keen or are a team member(posting under personal name perhaps?). Do you know of statistics on the number of players that actually use the PBs? I've glanced over the workshop but quickly realized that that is probably a bad reference frame because most players that might use the PB might actually write their own scripts.

photo
photo
1
domingo ● 6 years ago

Currently the game without scripts (and some mods) ranges from tedious at best, through frustrating to impossible at worst when you build something a little bit more complicated than one big grid with few supporting subgrids that use only "reverse" on pistons/rotors. (Even then looking at button bar is confusing with many same-looking buttons).

What about keeping programming block in but allow only "signed" scripts to run on them if experimental mode is disabled ?

Reply
photo
1
Timotei~ ● 6 years ago

I heard that Torch had this feature. And honestly, I think it could be the best workaround for this issue. The server could have a whitelist for scripts that make sure only approved scripts can be run. It wouldn't be possible to do online scripting but at least the PB would still be usable in a narrower band of possibilities.

photo
1
Malware ● 6 years ago

"Signed" by who though? The reason the PB is put into experimental is that its performance impact is outside of Keen's control, plus that there's still plenty of ways to crash the game or worse, a server, with PB code. From how it was explained to me, non-experimental mode is where Keen is trying to guarantee certain performance, to a reasonable degree. They simply can't do that with programmable block scripts as they work today. Unfortunately. Very unfortunately.

photo
Leave a Comment
 
Attach a file