Save the Programmable Block ;)

the New Guy shared this feedback 10 months ago
Under Consideration

Please don't move the PB to experimental mode.

Just a polite request. :)

I don't know how to code but I deeply admire those in the community who do. They can create incredible scripts that add so much to the game. Like the things Whiplash, Wellstat, Rdav, and others share on the workshop and on Reddit. For me, the programmable block is what really make SE unique.

I would like to see scripts working smoothly in both single and multi-player games. Like Vector Thrust, TIM, or Alyssius's Easy Lidar Homing Script. It would be awesome if we could run multiple scripts like these and not have the sim speed drop.


Everyone share your favorite scripts and show the authors some love :)

Comments (27)

photo
7

I'm afraid there's very good reasons for the PB being experimental. This is not merely about "optimization" like it was with the pressurization stuff, but the fact that scripters can write highly performance impacting scripts - and that's simply beyond Keen's control. Only big changes can deal with this problem, changes which most likely will have to break every existing script out there. So... it's experimental mode.

photo
2

Hi, we will consider our options and let you know.

photo
8

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 :)

photo
2

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. ;)

photo
3

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".

photo
1

Thank you!

photo
2

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...

photo
2

By the way:

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

photo
2

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.

photo
photo
1

I really hope they can do something like tying the power usage of a PB to it's Instructions/Tick, perhaps even exponentially.

So a very simple inventory sorter using 1000 instructions per cycle could use 1KW, but a complex ship systems manager hitting almost 50000 could use 5MW.

photo
2

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.

photo
1

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

photo
1

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.

photo
photo
3

I think to save the PB it should be rewritten. It should not share selectively exposed modding API calls, and should only be exposed to APIs created specifically for it. This would plug up most of the exploits that are achievable with it. There are many ways to go about this, maybe by using another language other than C#, or moving to a more module-centric visual scripting (or 'circuitry') interface. Still, the PB as it is now should be remade, rather than 'fixed up'.


Since I believe it should be rewritten, I also believe that it should not be rescued for SE1, and instead be implemented in a future edition.


This detailed piece of feedback posted on Mar 7th 2015 is something I still think about and agree with today

https://www.reddit.com/r/spaceengineers/comments/2y80ks/why_i_really_dont_like_how_programming_was/

e99daec5e98e567250f377ec0d703c54

photo
1

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

photo
3

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

9022e6025a045b79b16e5595b4c1a9b4

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.

photo
2

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


0f54053e170429ad9eb4d1c5aac6a51c


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.

photo
1

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 .

photo
2

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.

photo
1

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.

photo
photo
5

There are two easy solutions for the programmable block performance issue:

1. It is calculated on the client only.

Benefit: not much extra performance is required, as only the actual world-affecting actions have to be processed by the server.

Drawback: the block only works when the owner is online (which is also some form of a benefit).

2. Limit the amount of instructions a PB can perform per server tick.

Benefit: PBs can never cause lag to the server, as in worst case they are throttled down to a point where they barely work.

Drawback: PBs become unreliable, as high server load can almost shut them down.


I would go for a combined approach here: PBs are calculated on the client whenever the owner is online, but world-affecting actions limited to a specific amount per tick, which is dependent on the current server load. Once the owner goes offline the PBs are set to low priority mode and the whole script only executes several steps and only if the server has some spare time. There should be a way to check the current mode inside the script, to skip CPU-intensive operations when the client is offline.

This way while the player is online he will have the full effect of his scripting (unless it does some very crazy stuff), and he can still run critically important scripts while he is offline as long as the script is very basic and fast (like solar panels tracking the sun).

photo
1

I was surprised to see this thread tonight ! Of all the issues under consideration this is not one I would expect.

I agree with Malware's comment ' Scripters can write highly performance impacting scripts '. And that admittedly IS a problem.

You can make that same argument about the Mods as well - I can think of several that make a mess of things immediately available for your gaming frustration. So what comes next ? no longer support the mods ?


A Mod / script that kills game play will be unused or fixed. The very fact that I and others can write and publish scripts that ADD small things to the game play that improve the immersive quality is FREE GOLD FROM THE HEAVENS :) Did we not learn the lesson of Minecraft Mods ?


As a software author - allowing a bad script to run and letting the player figure out that maybe they don't want to use that script is -1 karma points... allowing a bad script to run and making sure you have given 100% support so they can avoid writing bad scripts is +10 karma points. They will break things... it will be work... it will grow things in unforseen directions... and the COMMUNITY will LOVE YOU for it !


Just my meager $0.02

photo
2

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.

photo
2

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?].

photo
2

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.

photo
2

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...

photo
3

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.

photo