Allow Event Controllers to store more than 1 program
Problem: Event controllers take up decent space, and with the expanded functionality of them we can program some pretty complex logic, however doing so requires an entire data center's worth of Event Controllers to be placed onto the ship, adding tremendous bulk! (My VTOL logic needs 5 event controllers, and that's just one subsystem) This caps how much programming can be done on smaller grids before the grid itself just becomes a flying event controller.
Solution: Allow multiple programmable parameters to be setup on one event controller. Still cap it if you need to but even being able to just have one controller store 5-10 commands would not only make programming these blocks easier, but allow for more complex programming on smaller grids.
I just don't see a realistic reason why we need multiple blocks the size of a gaming rig to run simple logic commands. I want to make smart, complex grids but this is a significant bottleneck which is compounded significantly as the grid gets smaller.
I like this feedback
Here is my VTOL video for reference. I expand on this in the feedback chapter at the end at 16:03: https://www.youtube.com/watch?v=yC1ajxsJng4
Here is my VTOL video for reference. I expand on this in the feedback chapter at the end at 16:03: https://www.youtube.com/watch?v=yC1ajxsJng4
The one gotchya at the moment would be the fact that event controllers can trigger based on other event controllers and if you aggregate them it would be tricky to select the sub-program, but, I do agree these things should be the size of a detail cube, IRL with today's tech it would be the size of a coin.
If this block is truly meant to be the poor man's PB, it shouldn't cost a data center as you say to get equivalent (basic) functionality. It's like having C# knowledge is pay to win in a sense at the moment. I always expected their "visual scripting" tech to make it into the event controller, but I guess not.
The one gotchya at the moment would be the fact that event controllers can trigger based on other event controllers and if you aggregate them it would be tricky to select the sub-program, but, I do agree these things should be the size of a detail cube, IRL with today's tech it would be the size of a coin.
If this block is truly meant to be the poor man's PB, it shouldn't cost a data center as you say to get equivalent (basic) functionality. It's like having C# knowledge is pay to win in a sense at the moment. I always expected their "visual scripting" tech to make it into the event controller, but I guess not.
This way, you can easily group automation rules together in a single block, turn them all on and off in a single slot (without using groups) and have a more predictable outcome when EC gets damaged/destroyed.
The hard limit of how many automation rules can be defined in a single EC block might be unlimited or at least very high. You will still prefer to split related automation in more EC blocks for better organization and locality.
This way, you can easily group automation rules together in a single block, turn them all on and off in a single slot (without using groups) and have a more predictable outcome when EC gets damaged/destroyed.
The hard limit of how many automation rules can be defined in a single EC block might be unlimited or at least very high. You will still prefer to split related automation in more EC blocks for better organization and locality.
it might be worth having event controllers locked to things like mechanical changes vs player interactivity vs enemy/npc activity. or the like... grouping them in this way could change how the events need to be managed.
it might be worth having event controllers locked to things like mechanical changes vs player interactivity vs enemy/npc activity. or the like... grouping them in this way could change how the events need to be managed.
Replies have been locked on this page!