Extend Event Controller with Code Edit and Value Storage Block

TL;DR

The new Event Controller (EC) in SE2 is a fantastic addition and already enables much more interesting automation thanks to much bigger selection of event sources. However, it currently scales poorly because each EC can only contain a single and simple rule, forcing players to build large numbers of ECs for even moderately complex automation.

Instead of having a fully-fledged Programmable Block as alternative to EC, I suggest extending the existing EC system with:

• Editing automation rules in code using simple syntax instead of fully fledged programming language
• Saving automation rule code to Datapad
• Adding Value Storage block that allow multiple ECs to exchange data
• Continuous value mapping (not only event → action)

Motivation

One of the biggest complaints since the introduction of the new EC is the sheer number of ECs required for even simple automation setups.

There are already multiple feedback topics requesting:

• smaller EC blocks,
• multiple rules per EC,

I actually like the idea that automation occupies physical space, like it always was in the game.

Having dedicated automation rooms filled with Event Controllers and timers is immersive and gives engineering another meaningful purpose.

However...

There is a difference between meaningful engineering and excessive block spam.

Currently, many ECs exist only because the system lacks expressive power, and you often need lots of boring repetitive rules to achieve simple automation goals. To many ECs could also be a potential performance bottleneck.

I think there is a much better middle ground.

The Goal

Do not replace Event Controllers.

Do not bring back a full C# Programmable Block.

Instead, extend the existing Event Controller system so that both beginners and advanced players can use exactly the same blocks.

Think of it as: Event Controller = new Programmable Block ...except fully integrated into the current automation philosophy.

Using of Datapads

Automation rules should be exportable onto Datapads placed into EC inventory.

A datapad would simply contain the automation rule as text (code).

This immediately gives several benefits for all kinds of players:

• save/load automation rule
• duplicate automation quickly
• share automation rule
• allow for interesting RP or scenarios
• new players will have a clear path to transition between simple UI driven automation and more advanced code based approach
• use EC UI to quickly grab necessary blocks references and then continue in code

Visual UI / Code

The current Event Controller UI is already very beginner-friendly.

Keep it.

But add a possibility to edit the rule in code.

Once you have changed the code, the rule becomes "custom" and you will lose the possibility to edit it with UI, but you can potentially still have a UI for finding and changing block references and to see the "state" of the rule or any additional data for debugging. If the rule after editing can be parsed as a standard EC rule (that you can make with UI), you will still see the traditional automation UI after closing the editor. This way, you can quickly see how the rule is implemented in code or even make some changes to it without losing the UI representation. It can be faster/easier to make changes in code for standard rules or be an opportunity to learn the code syntax for beginners.

Oh, and the integrated code editor should do a syntax/error highlight and validation (you cannot save invalid rule code).

Shared Value Storage Block

One addition could dramatically increase automation possibilities: Value Storage

A very simple functional block that can store one value.

At any point in the automation rule, you can save a value to the value storage block or use it in your automation logic. It is a kind of "physical" variable in a block if you wish :)

This allows shared state between multiple ECs.

Instead of trying to cram everything into one huge automation rule, different ECs can now focus on executing simpler automation rules. Composing those rules will now be possible like never before without creating hard references between them or even turning them on and off.

The value storage can hold any string or number. LCD can use them as text source to easily show values without adding yet additional EC.

Continuous Value Mapping Rule

The current EC mostly works as: Event => Action, which is good for simple on/off scenarios

Instead, it should also support: Value → Value

Instead of making dozens of rules trying to cover a wide range of values and therefore having dozens of individual event controller blocks yet still dealing with discrete thresholds, there has to be a way to do Value =>Value automation rule. For example, you should be able to listen to cargo fill and change a light intensity/color or to store a string with N amount of characters, all within a single EC rule. Then ofc, you can have an LCD displaying the stored value, basically custom gauges.

Practical Example (VTOL)

Imagine building a VTOL ship. Instead of several disconnected Event Controllers:EC #1 Listen to rotor/hinge angle (without any threshold but as soon as it is changed)

Calculates:

• Forward thrust coefficient
• Vertical thrust coefficient

Stores both values (in 2 separate Value Storage Blocks)

EC #2 Listens for Forward input.

Applies thrusters override:

Forward Input × Forward Coefficient

Applies thrusters override:

Up Input × Vertical Coefficient

Updates additional thrust override coefficient to be used in EC 2 and 3

Or you can manually increase/decrease this additional coefficient from a cockpit action slots if you want to.

The result is a fully adaptive VTOL that works at any angle and automatically compensates for cargo mass without requiring an infinite amount of ECs or very similar duplicated rules. And you can add more QoL features to it at any time without ever creating hard references between rules but just sharing the same variables via Value Storage Block.

Why Not C#?

The old Programmable Block was incredibly powerful.

But it also had drawbacks:

• difficult for most players
• security concerns
• server performance
• impossible to safely allow unrestricted scripting everywhere

Instead, SE2 could introduce a purpose-built automation syntax, which is by design made safe and limited but still perfectly allows for pretty complex automation scenarios with much less individual EC blocks. It is server-friendly, easy to validate, easy to share and learn.

The C# and a powerful mod API will still be available for everything left behind the scope of EC. Ideally, in single player, you should be able to author and test simple C# mods within the game (in Programmable Block) and then share them as cockpit apps or some other way via Workshop.

Conclusions

I think the proposed approach combines two worlds, classical EC automations and a subset of PB automations, in a neat way.

Most importantly, it expands the system without replacing it.

Players who never want to touch code can continue using the current UI exactly as they do today.

Players who enjoy automation gain a much deeper engineering system that remains focused on gameplay rather than general-purpose programming.

To me, this feels much more in line with the philosophy of Space Engineers: giving players better engineering tools while still encouraging them to build clever systems out of blocks, rather than solving everything by writing a few lines of C#.

Thx for reading. Share your thoughts below.