Status Of The Programming Block

With the latest patch the programming block has been moved to the "experimental" section of the game as if to discourage its official use and with this it will probably mean it will receive less support in the way of fixing bugs.

Setting the programming block as not part of the official game is a terrible idea as the programming block is one of the best and very unique features of this game. I can only think of one other game that lets you write code in it to automate tasks (Dual Universe has it planned) among other things.

In PVP the programming blocks really spices the gameplay up a lot. Without it PVP just comes down to turrets and kinetic weapons but with it there are so many more possibilities like homing missiles, guided missiles, complex fighter designs, bombers, advanced missiles. It really does add a huge amount to the game.

I hope this change is reconsidered as it is very bad for PVP to not have the programming block.

 

It was the only reason I kept playing for as long as I did

 

Server admins can still have PB on.

 

They have not got rid of it. If your server admin will not allow PBs on your server you may have to move to one more accomodating. As for the "experimental" branch, it smells to me like they are shovelling everything they can into it so they can get the game out of the door and if those features are buggy or broken they can say "well we did say they were experimental and not supported". A pre-planned excuse.

 

Non-experimental mode is supposed to provide some guarantee of performance. The PB... Well, there are very good reasons for putting the PB into experimental mode, even apart from the fact that Keen can't guarantee the performance of code they haven't written (the scripts).

As for updates to it... that's just business as usual. Keen as a company never did much for it, that was a couple of dedicated devs going above and beyond for us, as well as certain community members. That hasn't really changed.

I hope that the fact that I, as the author of the current programmable block compiler and probably highest proponent of the PB as a vanilla feature, must admit that the move is reasonable, is somewhat telling. This is not a battle we can win.

 

I have never actually used the programmable block in one of my own creations because I don't know how to use them, but I have looked at some cool ships from the workshop that used them to do things like display ship information just outside of the cockpit on a little display panel that I thought was really cool, it was like.... showing the horizon level on the screen, I kind of wish that function was available on the screen inside of the cockpits.

And another was player made guided missiles where you pointed the camera and the missile followed where you look, that was just amazing, I wish the game had something like that without having to use programmable blocks.

Timer blocks though, I am dumb enough to know how to use those.... hahaha/

 

Why do you use PB only for weapons? A few simple examples:
The machine of horizontal flight in the atmosphere (not very simple);
Pistons at the drilling rig - pushes at a low speed, folds at a high speed, without the need to manually change the parameters of the pistons;
Setting the lamps on the base - build how much you need, run the PB - all lamps are adjusted to the desired lighting and color.
PB automates routine operations. Without him, it's boring.

 

I understand that Keen want new players to play on their Official servers and they want those servers to run at the best sim speeds so therefore not having someone a block where someone code write some bad code is ideal. That said I don't see why they just don't disable the block on those servers, since on most Unofficial servers there are fairly active admins that can deal with players writing bad code or using badly optimized scripts.

 

@Bullet_Force I'm just the messenger. Any unofficial servers can activate experimental mode and use the programmable block just like before.

Experimental mode isn't just for servers. Space Engineers isn't just multiplayer.

 

I'm not crazy about scripting being moved to Experimental Mode, but, it is pretty much the paradigmatic case of an advanced feature.

 

Why not use some kind of watchdog mechanics. If the script take too long to run, the PB get locked and you need to recompile to make it run again.
There could even be a slider for the watchdog time of each PBs with an associated PCU cost on it.
Want a more complex program? Allocate more PCUs to it.
If it's reasonable enough, I will make this suggestion on the support site.

 

Damn....the glory of seeing functional dual axis tracking solar arrays almost makes me shiver. No more?


-Morloc

 

Weaponry seems to be the least common interest for the programmable block IMHO. I'm not knocking it. I just know there's a wealth of other stuff it's used for on a server.

Take MMaster's LCD script. Hands down it's the most USEFUL script out there. Honestly, I don't design a ship without using it do to the wealth of information you can easily program into an LCD. @Whiplash141 has entire archive of very useful scripts that range from weaponry to the mentioned horizontal flight, to drop pods, to rotating thruster nacelles, and so and and so forth. Rdav made a great attempt at fleet control (not sure if he fully developed it), and so forth.

There are a ton of great and useful scripts out there if you dig deep enough. I was looking for a simple script that executes a timer block a specified altitudes... bang... there was one. There's a lot more cool stuff out there that's actually useful. We're using the hell out of them.

 

Since nobody did, I decided to make the suggestion in the support site. https://support.keenswh.com/spaceen...e-programmagle-block-out-of-experimental-mode

 

@Timotei~ 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...

I should add that to your suggestion, shouldn't I...

 

Before being labeled "experimental" there was a simple button to enable or disable in-game scripts. Think of it as redefining that switch rather than being cast into Mordor.

@Malware My only question is that NPC ships usually run off of programmable blocks. So does that mean no more NPC ships with programmable blocks?

 

@Ronin1973 Don't ask me... NPCs are also driven by that visual scripter thing, isn't it. Hang on, are even the NPC things non-experimental? I don't know what is or isn't any more. It's blocking off everything fun.

 

I think the whole architecture of the programmable block is stupid as hell. Sure it can run code faster, but it has way too many drawback. They could just add a very very simple JS or LUA engine, and at each game cycle, let it run for X time (or X instruction). Since there are only fixed instruction per frame, ther would be nearly zero perfromance drawback, in the cost that your code won't run in one frame. I don't really see any reason to implement a whole compiler in the game for such a basic stuff as calling methods on interfaces. You could also use infinite loops without ever worrying about crashing the server.

 

All I can say is that i'll keep on running SE in experimental mode. In single player or when no one is connected to my DS its always fun to get into dogfights with cargo ships that have AI scripts (such as the IMDC Atlas). 1KM out of range (manual fire MK1 battery and it turned around and charged me, weapons blazing. Then there is the IMDC Protos, which fired its rocket batteries and obliterated my ship when I attacked it.

 

@Rabir Noone "implemented a whole compiler". The original PB made by Keen used the built-in compiler of .NET, and used IL injection to insert security systems. It didn't work. I added support for the newer Roslyn compiler instead, which provides easy access to source code based security injection instead to avoid all the complexity and bugs of an IL based system. After that it worked correctly.

The only reason we have scripting at all is the fact that they could use a preexisting compiler. If not we wouldn't have had anything. They would not have spent the time needed to add a secondary runtime, no matter how simple. I think you underestimate the amount of work that would be. You can't "just add a simple" anything if the very base of the game doesn't support being called in such an off-hand way. You will need an API in between to support it. That API would have made the current PB a whole lot better and safer as it is, we could even shunt the PB over on its own thread and it would have been better performance wise than any other solution. But we aren't getting that API. It's as simple as that. I've been fighting to get it since day 1 as - like you - I dislike the current one, since it's way too close to the game engine itself. This is what's causing the most issues. But Keen as a company isn't willing to spend the time and money to do it. They prioritize using those resources elsewhere.

 

I know that there is built-in compiler in .NET, yet I still think this is a bit overcomplicated and limits the variety of scripts the player can use. I actually understand the reason behind, but I don't accept it. SE is horribly empty game. The API is already there as mods use interfaces to work and KSH decide what to expose to those interfaces. Also adding a fukin JS engine (basically download one from NuGet) and a simple implementation into the engine would give so fucking many benefit. As mods could preserve backward compatiblity as you can alias methods and types for the script engine. Admins would be able to easily edit and upload scripts to a server on the fly. There would be zero need to limit programmable block, as the admins could reduce the instruction / frame on the server if really needed. Maybe there would be server-only mods? Like RPG gamemode, chat commands, trading, exp, limit blocks, etc...
I know that there are already a mod for several of these, but the amount of effort you need to use/create/maintain/update them is a bit ridiculous, compared to simply placing a .js file into a folder.

So no hate on you (as I know) you do it by hobby and you made an amazing job. But shame on KSH that they doesnt want to improve this feature of the game at all, even tho for many player, this is the only things keeps them playing. Indeed this takes some time, but I don't think it would need more than one dev from them, the rest can work on whatever they are doing.

 

@Rabir I'm sorry, but you can't just tack on a JS engine from NuGet and call it a day, because the game systems it would have to access wouldn't be able to deal. You'd need a specialized layer between designed to deal with the change of data types, with the wildly random access times as opposed to the fully controlled the way the PB is, protections during save and a whole slew of things I can't even think of at this moment. It might seem like a simple job, but trust me, it's not. We're talking weeks, plural, for a single dev, especially if we take QA into account. This is my estimation as a professional programmer with some experience. And one dev is quite a lot when you don't have many to take from to begin with.

The language, compiler and runtime is not what is limiting this. It's just the API. If the API was specialized to the programmable block, designed for scripters and not for a game engine, things would be very different.

No. The .NET compiler does not limit the variety of scripts the player can make. All the limitations of the programmable block are imposed. And yet it's absolutely unbelievable what a skilled scripter can do with the PB. All the performance restrictions can be worked around safely and performance friendly with enough know-how. The rest, the security restrictions, those would have to be there regardless.

Again we come back to the API. If the API was better, it would be easier to learn, easier to use and safer to use. The language is irrelevant.


There are already server-only mods. You can already do game modes, chat commands, trading, experience, block limitations... All of that is already possible right now. You even have a form of mod called plugins that the servers can run that has no restrictions at all.


The whole argument is moot though. They can't change this now anyway, the outrage from the scripting community would be hellish, with all their scripts getting scrapped.

What they should have done, at the beginning, was make a more visual kind of scripting system instead. Something that would allow more people to automate their builds without having to learn to program. Something that would include more than a few tiny fractions of the player base. That is what they should have spent time on. The fact that we're so few is part of the reason why we're not getting any love from Keen.



I will withdraw from this argument now, as it's making me sad thinking about what we could have had.

 

@Malware

Apparently you can just get a JS engine from NuGet. C# JS (or LUA) engines are excatly what you mentioned, that they bind C# objects to the interpreter and vice versa, they are that "specialized layer". Or, at least it took me like 15 minutes to build a working test when I was playing around with these. All I needed to do is enter the JS code as string into the engine, and bind some C# object as global variable. From this point, all you need is start the Main() and run the engine for X statement each time.
Writing the JS engine would be that hard task that needs an experienced developer, but just adding a pre-made interpreter especially built for C# is not some PhD stuff.

Also, I didn't said the compiler does. BUT the way it is implemented do. As I know there is currently 1 sec limit on scripts? So you can't really build state-controlled autonomous stuff. Sure you can with timer block, but this sounds a little bit stupid as we are talking about "programmable" block. Not talking about thanks to the current way it is implemented, it is in experimental and many many server prohibites it's usage.

So we are left with: Yeah we have it, but most probably no, you can't use it.

And adding this feature wouldn't cause all old mods "scrapped". There could be a "migration" period, where they leave in the old way, and let you use the new one. You don't have to be that radical to instantly drop the support.

And2 I agree with you, this is the strange way KSH could implement a scripting. Even if not visual, they would have way less trouble and problem with an interpreted language, so they wouldn't need useless restrictions like that 1sec run time. Or even a stupid "assembly-like" stuff, like:
RUN Assembler
MOVE CONTAINER2, ASSEMBLER, IRON_ORE, 2000
IF PISTON.EXTENDED_FULLY THEN_LABEL ELSE_LABEL

Not because it looks better or more versatile or faster or anything (because its none), but because it require less programming knowledge (minimal algorithim mind) and is easier to maintain compatiblity, control the flow (limit the time it runs) and more "readable" in that shitty in-game editor-called textbox.

By the way I know they won't change it. But we are here to discuss stuff, not to "order" KSH to do specific tasks. We can "brainstorm" on what could be better or worse.

 

@Rabir I know you can just get a JS engine from NuGet. I'm using one in my personal projects. But that doesn't mean you can just plug it in and use it against a preexisting complex system just like that and expect it to work correctly. They do not work like that specialized layer. That's just a fraction of what needs to be done. For example, the JS engine can't control when you send a command from a script that is invoked at a time when the game engine is not ready to or even expects to see any hint of that operation. It won't work. It'll crash and crash badly. The engine itself needs to be able to deal with those operations. It doesn't today. You would need to write all those C# objects to pass to the engine, objects which could wait until the right time when the given operations can be invoked safely.

I think you need to do a bit more research on how ingame scripts work. You seem to have a horribly skewed view on what you can do with programmable blocks. No, there's no 1 second limit on scripts. There's a limit on how many instructions you can do within a single tick, but nothing is preventing you from running your script over multiple ticks, without the need of timers. There's built-in systems to facilitate this. Have you even seen MMaster's LCD2 script and all the things it displays on LCDs, all the variants it can show? People have been writing fleet command control stuff with ingame scripts, for goodness sakes. I think you're seriously underestimating what you can do.



https://steamcommunity.com/sharedfiles/filedetails/?id=1162841676&searchtext=rdav+fleet+control

https://steamcommunity.com/sharedfiles/filedetails/?id=822950976&searchtext=lcds+2


These are just ingame scripts, not mods.

 

Resurrecting this a little. Sorry. Can't log in to bug forum.

At least if it requires experimental mode and in-game scripts for it to work properly, at least put up a prompt when players press edit or recompile telling them they have to enable those options.

 

As far as I understand you cannot press edit or compile when the PB function is not enabled. The functionality of the block is completely disabled in non-experimental mode

 

Of course. I am asking for a prompt when someone presses a disabled option telling them WHY it was disabled. Especially on a programmable block, whose purpose is to have a program.

 

It feels like PB should work just fine so long as they all have a limited window to operate. Say every 5 sec your PB can run once. Even sooner depending on voxel altering operation. If I know I want my automated shipping freighter to travel 10km in one direction, all it takes is one command to a PB which in turn activates a "burn" for a few seconds, followed by an idle timer for a few minutes, then activate landing.

With dozens of grids operating like that, it would not require many constant calculations. Maybe 45 PBs firing off every minute.

EDIT: firing off ONCE every minute

 

The PB does work fine if you know what you're doing. The problem is when you don't - or if you're deliberately being destructive. Then it doesn't matter how rarely it runs, because only a single run is required for the damage to apply. One run is all I need, and I'm bringing your SE server instance (or local game if you're playing solo) to a grinding halt. And there is no simple solution to the problem.

 

There is but we just have to hope Keen don't go there to "solve" people abusing programming blocks the way they "solved" damage from player made weapons.