Some thoughts on the shape of programmable blocks for SE2
It would be nifty to move programmable block execution to its own thread (or perhaps multiple threads) and decouple execution from the simulator tick unless the script explicitly opts to sleep until a specific tick. This would allow scripts that want to do a lot of work to keep running and not need to bother with splitting work between multiple ticks without impacting performance, as well as scripts that need to do something every tick.
Any script that waits for the next tick gets to run first, followed by the still-running scripts. Your grid's processor budget is proportional to the number of program/programmable blocks.
I want a program block (in addition to a programmable block) with a fixed program automatically created for all subscribed in-game scripts (for a dedicated server, this would be explicitly allowed and/or not expressly denied scripts). The idea is that you develop your script in a programmable block, but when you share it with others, it appears as a pre-packaged block.
Instead of storing configuration in "Program Data," a declarative configuration could extend the terminal UI when a program block is installed on a grid.
Edit: Perhaps use WASM/WASI to sandbox the scripts or a thread for each grid running scripts so you can easily pause/resume the script on demand.
I like this feedback
Possibly they could use c#7 rather than 6 as c#7 offers many things that 6 does not
Possibly they could use c#7 rather than 6 as c#7 offers many things that 6 does not
Possibly they could use c#7 rather than 6 as c#7 offers many things that 6 does not
Possibly they could use c#7 rather than 6 as c#7 offers many things that 6 does not
Yeah, that's probably the only way to avoid the headache that programmable blocks cause on servers.
Yeah, that's probably the only way to avoid the headache that programmable blocks cause on servers.
just make it python. im too lazy
just make it python. im too lazy
In addition to this, have events that scripts can subscribe to during the course of the script.
public Program() { // ... // Subscribe when button is pushed button_panel.OnButtonPushed += Program_OnButtonPushed; // Subscribe to grid event GridTerminalSystem.OnPowerToggled += Program_OnPowerToggled; // ... } public void Program_OnButtonPushed(object caller, ButtonPushedEventArgs args) { IButtonPannel pannel = caller as IButtonPannel; string output = args.IndexPushed switch { 0 => $"The first button was pushed! The args are {pannel.Buttons[0].Args}.", 1 => $"The second button was pushed! The args are {pannel.Buttons[1].Args}.", 2 => $"The third button was pushed! The args are {pannel.Buttons[2].Args}.", 3 => $"The fourth button was pushed! The args are {pannel.Buttons[3].Args}.", _ => $"Another button was pushed! The args are {pannel.Buttons[args.IndexPushed].Args}." } // ... } public void Program_OnPowerToggled(object caller, PowerToggledEventArgs args) { IGridTerminalSystem grid = caller as IGridTerminalSystem; string output = $"The power on grid {grid.Name} is {(args.IsOn ? "on!" : "off.")}"; // ... }Which would save a lot of time having to poll the grid every tick or even have multiple functions run without needing a programming block middleman. Additionally this would be very nice for inventory sorting scrips to save on lag.
public Program() { // Initialize inventories // Subscribe to all foreach (ICargoInventoryBlock inventory in managedInventories) { inventory.OnItemAdded += Program_OnItemAdded; inventory.OnItemRemoved += Program_OnItemRemoved; } } public void Program_OnItemAdded(object sender, ItemAddedEventArgs args) { ICargoBlock cargo = sender as ICargoBlock; if (/* Check if itemstack is not in the correct container */) { ICargoBlock correctCargo = null; // find correct cargo block cargo.TransferTo(args.ItemStack, args.ItemStack.Count, correctCargo); } return; }In addition to this, have events that scripts can subscribe to during the course of the script.
public Program() { // ... // Subscribe when button is pushed button_panel.OnButtonPushed += Program_OnButtonPushed; // Subscribe to grid event GridTerminalSystem.OnPowerToggled += Program_OnPowerToggled; // ... } public void Program_OnButtonPushed(object caller, ButtonPushedEventArgs args) { IButtonPannel pannel = caller as IButtonPannel; string output = args.IndexPushed switch { 0 => $"The first button was pushed! The args are {pannel.Buttons[0].Args}.", 1 => $"The second button was pushed! The args are {pannel.Buttons[1].Args}.", 2 => $"The third button was pushed! The args are {pannel.Buttons[2].Args}.", 3 => $"The fourth button was pushed! The args are {pannel.Buttons[3].Args}.", _ => $"Another button was pushed! The args are {pannel.Buttons[args.IndexPushed].Args}." } // ... } public void Program_OnPowerToggled(object caller, PowerToggledEventArgs args) { IGridTerminalSystem grid = caller as IGridTerminalSystem; string output = $"The power on grid {grid.Name} is {(args.IsOn ? "on!" : "off.")}"; // ... }Which would save a lot of time having to poll the grid every tick or even have multiple functions run without needing a programming block middleman. Additionally this would be very nice for inventory sorting scrips to save on lag.
public Program() { // Initialize inventories // Subscribe to all foreach (ICargoInventoryBlock inventory in managedInventories) { inventory.OnItemAdded += Program_OnItemAdded; inventory.OnItemRemoved += Program_OnItemRemoved; } } public void Program_OnItemAdded(object sender, ItemAddedEventArgs args) { ICargoBlock cargo = sender as ICargoBlock; if (/* Check if itemstack is not in the correct container */) { ICargoBlock correctCargo = null; // find correct cargo block cargo.TransferTo(args.ItemStack, args.ItemStack.Count, correctCargo); } return; }Hello everyone,
I am a programmer, admin, and devops, and I wanted to share some thoughts on the Programmable Block in Space Engineers. While the current implementation is functional, I believe there are several enhancements that could greatly improve the experience for developers like myself.
Firstly, let’s be realistic: executing code from the Programmable Block in a separate thread is quite challenging due to the need for synchronization with the main tick cycle. With numerous blocks in the game, it raises the question of whether to run them all in one thread or each in their own. While it’s certainly possible to implement a special synchronization mechanism, it would be a considerable task. However, I would be interested in tackling this challenge!
As a programmer, I would find the following changes to the Programmable Block very beneficial:
Remove the Code Size Limitation: The current limit on code size can be quite restrictive. I’ve even had to create an obfuscator that reduces code by removing insignificant characters and comments, and by shortening variable names. The performance of the code depends on its quality, not its size.
Support for Reading Code from Disk: It would be extremely convenient to read code directly from a file. Since the code ultimately ends up in the block through copy-pasting from a development environment, why not simplify life for programmers? A feature that allows for easy updating and compiling of code directly from the disk would be a great addition.
Project Support: Following from the previous point, it would be useful to have project support. Even simple code can benefit from being split into multiple files based on certain criteria. For instance, a project could be defined using a json, ini, or yaml file that lists the files to be read sequentially, merged into a single text, and then compiled.
Additionally, it would be great to have two modes for the Programmable Block: a large text editor for direct in-game code editing and an option to select a project file from the computer.
We could take this even further by introducing a one-slot inventory in the Programmable Block interface, allowing players to insert a tablet or a "diskette." The tablet would be used for in-game code editing, while the diskette could serve as a pointer to a project file on the computer. If we also allow for tablet copying, players could share code with each other in-game, leading to the creation of code libraries. This could make use of all those decorative items with their own small inventories.
Hello everyone,
I am a programmer, admin, and devops, and I wanted to share some thoughts on the Programmable Block in Space Engineers. While the current implementation is functional, I believe there are several enhancements that could greatly improve the experience for developers like myself.
Firstly, let’s be realistic: executing code from the Programmable Block in a separate thread is quite challenging due to the need for synchronization with the main tick cycle. With numerous blocks in the game, it raises the question of whether to run them all in one thread or each in their own. While it’s certainly possible to implement a special synchronization mechanism, it would be a considerable task. However, I would be interested in tackling this challenge!
As a programmer, I would find the following changes to the Programmable Block very beneficial:
Remove the Code Size Limitation: The current limit on code size can be quite restrictive. I’ve even had to create an obfuscator that reduces code by removing insignificant characters and comments, and by shortening variable names. The performance of the code depends on its quality, not its size.
Support for Reading Code from Disk: It would be extremely convenient to read code directly from a file. Since the code ultimately ends up in the block through copy-pasting from a development environment, why not simplify life for programmers? A feature that allows for easy updating and compiling of code directly from the disk would be a great addition.
Project Support: Following from the previous point, it would be useful to have project support. Even simple code can benefit from being split into multiple files based on certain criteria. For instance, a project could be defined using a json, ini, or yaml file that lists the files to be read sequentially, merged into a single text, and then compiled.
Additionally, it would be great to have two modes for the Programmable Block: a large text editor for direct in-game code editing and an option to select a project file from the computer.
We could take this even further by introducing a one-slot inventory in the Programmable Block interface, allowing players to insert a tablet or a "diskette." The tablet would be used for in-game code editing, while the diskette could serve as a pointer to a project file on the computer. If we also allow for tablet copying, players could share code with each other in-game, leading to the creation of code libraries. This could make use of all those decorative items with their own small inventories.
What I am missing now, is the possibility to share code between programmable blocks. It makes it hard to maintain common code.
What I am missing now, is the possibility to share code between programmable blocks. It makes it hard to maintain common code.
As far a threading is concerned; For stability, it should be a backend feature, that is automatically used, to optimize all used PBs (even then, that might be difficult, in regards to race conditions). as far as, code we could write; the best we could hope for is "waits". With that in mind, there isn't much need for our scripts to have dedicated threading; unless you intend to overload the server and lag it out.
Event scripts, would be a nice feature though.
As far a threading is concerned; For stability, it should be a backend feature, that is automatically used, to optimize all used PBs (even then, that might be difficult, in regards to race conditions). as far as, code we could write; the best we could hope for is "waits". With that in mind, there isn't much need for our scripts to have dedicated threading; unless you intend to overload the server and lag it out.
Event scripts, would be a nice feature though.
Disclaimer: these are comments on an unfinished and unpublished part of the game any and everything may change when and if user generated scripts/programable blocks become available.
In game scripts seem to be already inplemented at the engine level, they are run in task pool in parallel, csharp version currently is 11, the engine can build multiple scripts in a single in-memory dotnet assembly, but the engine currently builds an assembly per script ("file"), multiple types (shapes?) of script are technically suported but ony one type is currently implemented as OldScriptSignature, it requires a constructor with an argument of type Keen.VRage.DCS.Components.Entity and an Update method with no arguments.
The scripts may have some constraints in length, instruction count, stack size, memory allocation amount, runtime limit among others.
There seems to be a maximun execution time of 16ms per update loop, which if reached abandonds the current iteration, and a timeout of 100ms, which if reached seems to remove the script from the task pool
Disclaimer: these are comments on an unfinished and unpublished part of the game any and everything may change when and if user generated scripts/programable blocks become available.
In game scripts seem to be already inplemented at the engine level, they are run in task pool in parallel, csharp version currently is 11, the engine can build multiple scripts in a single in-memory dotnet assembly, but the engine currently builds an assembly per script ("file"), multiple types (shapes?) of script are technically suported but ony one type is currently implemented as OldScriptSignature, it requires a constructor with an argument of type Keen.VRage.DCS.Components.Entity and an Update method with no arguments.
The scripts may have some constraints in length, instruction count, stack size, memory allocation amount, runtime limit among others.
There seems to be a maximun execution time of 16ms per update loop, which if reached abandonds the current iteration, and a timeout of 100ms, which if reached seems to remove the script from the task pool
Replies have been locked on this page!