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.
how do I vote? This definitely needs to happen!
how do I vote? This definitely needs to happen!
I agree fully
I agree fully
i have a suggestion somewhere that would have facilitated this, it amounted to a central computer that can store the programs themselves and then a controller block then wires up those programs to particular blocks on the grid (but the centrla computer can also store test files and stuff so you could do like crew logs)
i have a suggestion somewhere that would have facilitated this, it amounted to a central computer that can store the programs themselves and then a controller block then wires up those programs to particular blocks on the grid (but the centrla computer can also store test files and stuff so you could do like crew logs)
My take is to have 'Program Modules' that function like a generator's power cells. The Event controler has a removable unit that is a named program. You can 'produce' or 'Duplicate' new Program Modules in any Event Controler and plug-and-play them into other Event Controlers.
Meaning if you want a sufficiently complex action like automated docking or VTOL managment, you might need 3-5 event controlers, but if the same grid then needs to operate as an automated mining craft, you could swap out the Program Modules and store them in crates/lockers for ease of organization. It would require some manual work but the tradeoff would be saving overall space from having 12-18 event controlers installed for a complex grid programming.
My take is to have 'Program Modules' that function like a generator's power cells. The Event controler has a removable unit that is a named program. You can 'produce' or 'Duplicate' new Program Modules in any Event Controler and plug-and-play them into other Event Controlers.
Meaning if you want a sufficiently complex action like automated docking or VTOL managment, you might need 3-5 event controlers, but if the same grid then needs to operate as an automated mining craft, you could swap out the Program Modules and store them in crates/lockers for ease of organization. It would require some manual work but the tradeoff would be saving overall space from having 12-18 event controlers installed for a complex grid programming.
Replies have been locked on this page!