Save the Programmable Block ;)

Totally agree with the opinion that the PB is kind of the heart and soul of SE. There are newer, better looking, more dynamic games than SE set is space launched over all those years, but why for me at least SE washes off all concurrent games from the playground so far is the extent at which SE is scriptable thru the PB practically allowing you to make your own game.

I think that real space engineers when they will actually exist they will spent a significant part of their jobtime programming devices, so from this point of you view PB adds kind of a weird (?) realism to the game, too :)

I totally agree with that. In my opinion, the only reason the PB is not the single most important block in the game is because the ore detector does not support it and because there is no auto-complete.

When searching for Ore Detector API, I found out, there is already an existing pull request to that and

Auto-completion is a standard feature in any editor,

so BOTH are simple improvements, that would enable beginners to access this great feature and even motivate to learn programming, an essential part of contemporary REAL LIFE, which would qualify Space Engineers as educational mean for informaticians. ;)

I'm sorry, but they actually tried to make ore detector support, but they couldn't find a way that was performant. The existence of a pull request, I'm afraid, means little if it's not fast enough. You're also underestimating the workload for autocomplete. It's not like they can use any existing editor. Besides, one can use a real IDE like Visual Studio to write their scripts anyway. The ingame editor is just a receptacle. I.e. none of those are "simple improvements".

Thank you!

Concerning ore detector api: It would be a great step to do it somehow and just put it in experimental mode with its own little checkbox... If there are performance issues, everbody can decide by himself to use it or not, but at least it would be possible.

Concerning autocomplete and real IDEs: Autocomplete might not be a one-liner, but since the PB is so unique to Space Engineers, i think bringing a minimalistic but real ide ingame is well invested time adding to the immersiveness. Playing a game by using another piece of software half the time is somehow weird, in my opinion...

By the way:

I made seperate feature suggestions for both ore detector api and auto-complete.

I been playing SE since version 0.2 around, The programmable block has been one of the greatest implementation in SE.

I developed a few scripts in my games and the layer it add is so great that playing without them make SE less interesting.

I understand there is some major issue with CPU/GPU time using those and it's very easy to have some bad script or intentional malware that will load the memory or lag game to death, it did happen to me trying to parse large string data size, I had to rethink my script methods to stop my game from freezing frequently.

Some idea to make it better:

- I think update every 1 tick is very fast and any script using it is just over taxing cpu. I usually try to make my script work with update100, maybe it should be the only option there.

- There should be some option to limit cpu/gpu time on PB script, if a PB go over that it should "disable" itself with some kind of overloading error and a long cooling down time to reactivate (to prevent another PB to reactivate it right away), which would force "software engineers" to rethink their code properly, multiple overloading error should increment that cooling time to prevent any reactivation loop to keep having it reactivated too frequently.

- It could even be an option in game setting where you decide the maximum cpu/gpu time all PB in the world can take, like say 5% or 10% maximum of CPU/GPU time.

That doesn't really fix the core problem though. For the PB to be safe it must not be possible to slow a game down significantly - or worse - stop it.

What about measuring the performance of the code and if it goes over the limit, simply kill it?

The torch server has a plugin for this which damages PBs that exceed certain rules.

The problem is that, by that time, the damage is already done. People on the server have already been inconvenienced by the lower performance of the server as a result.

To make PBs safe they would have to take away too much of what makes them so damned useful.

i know but is isn't the program block that is the problem it's only the script that is i made a feature suggestion that uses the visual builder DSK to write code with that any limits you not allowed to use would simply be stopped before i couldn't explain it well and i am going to revise once i understand what's going on

what this will do is stop a lot of features that go too far

explanation of how it works is on there

I just read the reddit review and couldn't agree more.

When you say "module-centric visual scripting (or 'circuitry') interface" you mean like this?

Because I've used something like that for programming legos in gradeschool and it was easy to understand. It would be nice to have more sensors too if that's the case.

Yeah, something like that. Conveniently, they already have a visual scripting tool that comes with space engineers for levels and such:

Doing something visual is just one option, it could still be typed scripts, or even stay as C#. However, in my eyes it must be rewritten, like I detailed in the root comment of this thread.

omg please dont remove them. MM scripts and Floor plan makes ship bridges come alive and removing them would ruin many of my ships including my entire colonial fleet .

I know that there is audience for visual scripting and I am fine with that as an alternative for normal programming, but I would uninstall SE from quite a few computers and forget it if that became the only option. There are lots of reasons why visual scripting does not "click" in my case, but the most notable are:

• visual scripting is time waster in times of magnitude when you start working on larger and more complex scripts. It wastes time for both, initial code entering and then maintaining, debugging, understanding it, especially if it is creation of different person. If you ever looked into MMaster's LCD script, try to imagine it in visual scripting form..
• that would kill educational use of this game, I had used it to teach several young guys programming in C# and was planning to keep doing this. It is also a reason why I love the fact that it is real world language, not LUA or some other misunderstanding. Yepyepyep, there are good reasons behind those alternative choices, but having C# makes SE special for me. I do not know other game with that. Please give me steam link in case you do.

I would say that effort to implement proper visual scripting is own project by itself. So:

• given lack of complexity in current implementation (am comparing it with full blown visual scripting solution with debugging capabilities) and amount of times and ways existing implementation was broken or changed during recent years;
• having observation that those, who were the most visible and API related work of whom was positively the most sensible are not with Keen anymore;
• taking into account current state of SE development and the fact that v1 needs to be finalised and released better sooner than later if we want to see SE2, SE3, etc. in future;
• given amount of open issues, much more critical for SE1 to succeed (i.e. moving PBs from experimental);

.. I believe that jumping into work on visual scripting solutions as replacement for current PBs would be playing with fire. Rewriting APIs too. That would break almost everything we use because vanilla does not offer that and if that happens now, that would essentially kill SE1. I agree that PB API could use more understandable for consumers terms and abstract more low level technicalities, but I would leave such revolutions for SE2.

To conclude: I am deep supporter of changes needed to move PB from experimental. Regarding everything else - dump in backlog of SE2 and focus on survival rebalance (or something else of similar importance) for SE1 instead.

Any visual editor should simply be writing real code under the pretty UI anyway. Thus it should still be possible for advanced users to edit that code directly.

The big difference between poorly behaving mods and poorly behaving scripts is that mods are the server-admin's to manage, it's in their best interest to only deploy performant mods which add to the experience without too much overhead.

Scripts are player content and if not well managed by server-side rules are very open to exploitation by someone who wants to troll a server. The cost to reward ratio for a troll setting up on a new server, farming enough materials for a battery and PB and then run a stupid script to calculate the Fibonacci sequence to 300 billion digits is too great right now.

Kristian Williams Yeah, I see that being a problem, maybe they can limit the computing capabilities of PB like:

This server doesn't trotle down these scrips:

[List of script that can run full power and are allowed by the admins, you can clic here and copy the program to your PB]

Any other scrip has a top executions per second of [Limit set in the config of the world]. Any scrip beyonf this point would be [Option set on the config of the world. Stoped; delayed, other?].

I'm not gonna go into details, Acynder, but several programmers, professional and no, Keen and no, has been trying to solve this particular issue for a long time without finding a "simple" solution. A script simply can't be arbitrarily stopped or killed because that would set the game in an undefined state.

The only way to really "fix" the PB API is to completely rewrite how it works from the bottom up. The probability of Keen spending that kind of time, as well as breaking each and every existing script out there, now, is... well. Microscopic.

Malware Soo... the scrips cant run in a miniVM and slowed down?... then I dont know... Im just an Industrial Robotics tecnician, I only know Siemen's Tia Portal and a little bit of arduino. I wish that at least keen included the API wiki on the game because I dont even know how to move a piston with the PB... Tia Portal and Logo Soft Control have an built in wiki explaining what everything does...

Of course it can, Acynder, but it isn't. And just wrapping it won't work (and will add general performance pressure, currently scripts run as fast as the rest of the game - because they're compiled the same way). Hence the need for a big rewrite.

As for learning PB scripting:

https://github.com/malware-dev/MDK-SE/wiki/Quick-Introduction-to-Space-Engineers-Ingame-Scripts

and of course the Keen discord, the dedicated ingame programming channel, where there's lots of people willing and able to help.

It is easy to make them balanced in both ability and server performance, it is a question of whether or not Keen is willing to invest the time. Trotteling is no rocket science and can be done easily.

I am pretty sure that Timer blocks take more performance of a server than Programmable blocks, so they are not a solution to the issue.

Beauty of SE is that if you want to go over the board - you can. :) There is quite a list of competitors who are limited in that regard. I do not really see much value for SE doing same thing.

I think the server should have a toggle for the PB, like Disabled, Admins, White list, and Enabled.

Enable/Disabled are self explanitory

Admins, is like it is now where only select people can use it.

And white list is a drop down list of authorized scripts anyone can run.

Also another feature for admins to limit the commands(like have a blacklist of words that will make the script not run), length of text, and max run time per minute/hour.

With the combined effort of block limits the scripting could easily be managed.

For server use I agree with spam blah that whitlisting some scripts should be a good way. Most script users are only using existing scripts, and in many cases its a quite short list of scripts.

An extra otion would be as suggested earlier to allow client only scripts, that is scripts that run on the client computer, if the user is offline the script is not running, those scripts would not need to be whitelisted and could also be allowed to do much heavier processing, but will then be a bit limited.

But it would still allow for much customization of ships and bases without risk for the server owner.

And given the whitelisting solution, optionally servers could allow only whistlisting of scripts from steam workshop and also report usage which then could be used to optimize the API to help frekvently used scripts with dedicated functions for heavy tasks.

Another way to make scripts less likely to hog the performance would be to first make all interactions with the game state asynchronous so you call a method to get some state, when you get that state you perform action and any state changes is also an asynchronous call, that means that game tick can keep going.

And using the new Roslyn compilation the PB could also process all code before it gets fully compiled and add an extra async call in the start or end of each loop.

This would make it so that you cannot ddos the server with a tight loop since each iteration would call a noop method what could then wait if sim speed is low, and by using some round robin semaphores all scripts can be allowed to run, they just run slower if the server is under heavy load.

This will make some usage impractical in multiplayer if the script is dependent on doing a lot each tick, but it would still allow a lot of current scripts to keep working.

And if the async is built into the getters and setters of any object we interact with it might not even need any redesign of the scripts, they could just keep working :)

Disagree with whitelisting. It's a band-aid at best, not a solution. It's kind of circularly self-defeating, too: To be a candidate for a whitelist, enough players need a need for the script. -> It needs to fit enough players' applications. -> To fit enough players' applications, either the applications need to be very strict (drastically lowering players' interest in the script), or the script must be coded to be highly compatible. -> Highly compatible scripts are big and bloaty. (Granted, unnecessary functions can be made disable-able, but someone has to code them that way.) -> But you don't want big and bloaty scripts in the first place. Or the script's dev does not want to make it big and bloaty -> The script is not a candidate for a whitelist anymore.

@andersenman.

Whitelisting would be a server governed feature, not centrally managed by keen.

That way script makers can try them out on their own servers and players can ask server owners to whitelist scripts.

Yes it will require a bit more from server managers but making it server owner governed makes it easy to update the list and different servers can use different scripts.

Yes, I meant per-server, not per-Keen.

And as written, it's not just more work for managers, it's more work for players to make their builds comply with the script requirements and more work for script coders to make their scripts compatible to be or remain usable.

It's just not a smart way to solve the fundamental issue. It's just a band-aid.

PB Scripts come in 3 broad groups. You have the big guidance system control type scripts, which are likely to cause issues if badly written, the medium level, adjust the angle of your solar panels to track the sun, type scripts, which while complex aren't that likely to cause issues, and the very small scripts for doing things like changing the 'script' display on a screen somewhere.

The later feeds into a gripe I have, about the list of 'scripts' available on any screen. It should be customisable by admins, using the PB to add scripts to those available, that would allow flexibility, at the admins discretion.

As for the other stuff, I would prioritise 1) give a setting which allows admins to edit scripts, and no-one else, rather than require the whole server and all who use it to go onto experimental mode.

2) Allow an in game way to edit the scripts that show on the lcd screens, again, potentially split by faction or just to admins, so there is some in game approach to expanding the screen options

3) Extent that to allow the PB to access a set, and limited number of external blocks. That would drastically reduce the scope for large projects, if all thats allowed is something simple.

As an aside, adding a sequence block, which would execute all the commands in Ctrl+1 then all the commands in Ctrl+2 then Ctrl +3 etc each time with a delay or pause between them, would allow a lot of flexibility. I wanted a 10 stage machine for mining, and moving along a track, using pistons to walk. I ultimately did it with a PB, but it should have been doable with a Timer, if I could store a sequence.

Finally, if you had some means of applying a condition to a timer, like don't run unless this connector is locked or this entity is empty, or contains the same or more items than that other container. Then you could do things like have a process only start if the assembler has finished or if its safe to proceed.

Maybe allow the PB in non-experimental, but only allow pre-approved scripts pretty much everyone uses (Automatic LCDs 2, Whip's Doors, heck, anything made by Whip, etc.).

I know some games like Ark: Survival Evolved has a thing like that on their Steam Workshop, where mods that are known to be clean get a little green puzzle piece next to them. Maybe KSH could do the same, effectively giving their blessing to certain scripts that work great and are low performance that pretty much everyone uses, and those scripts can be used anywhere. Have the script library deny loading scripts to the PB if they don't meet this qualification, unless in experimental mode, and deny editing to the PB script dialogue/console. You could still alter custom data for blocks, so for example, you can specify door timers and exclusions for Whip's Doors.

I appreciate the gravity of the situation, that PBs can be used for abuse, but I think that's been mentioned above already as a non-issue for certain servers where you must apply for a scripting role, given at an admin's discretion.

Quite frankly, I only play in experimental mode, as the PB and air pressurization are just too crucial to a great gaming experience in SE.

Definitely giving this topic an up-vote. Don't ever get rid of our beloved PB!

Late to the party, but at the very least PBs should be optional / configurable per save / server. PBs can give players crazy advantages they would not otherwise have, borderline cheats in some cases. I would not want to face these in a PvP server setting.

PBs have been optional for years, Old Duck.