First as you might know I have been working on a link tool update that will streamline your logic circuit by making multi-gate pointless, all gate smaller (basically 1x1) and the overall link experience more robust. Unfortunately it might break some stuff around - for now old circuits are still working - but as the code is way too different at one point I will have to "unplug" the legacy code and embrace the new one.
Sorry for the pain it might cause some of you who spent time working on some logic, but as the game is in pre-alpha these moments are somewhat inevitable.
I realized that now could be the perfect time to do some needed improvements on the logic side: now the code allows to do certains things, but also as importantly as you guys will have to redo your logic system to some extent why not bundle up the two changes in one, so I dont force you to refresh your logic wired two time (sorry for that btw)!
First lets tackle what I dont like in the current system:
- The fuzzy aspect is confusing to new players and it dont bring much value. I did it originally so that we can control rotor and sliders, but I feel it is not at the right abstraction level - as I dont see any use to actually manipulate values inside the 0-1 range, we should bring that at the end of the circuit (I think people end up doing that 100% of the time I guess)
- It is pulse based instead of being "current based" (sorry for the crappy explanation). It means that there is really no active/inactive state, you just propagate a given value during a frame and then each following node do something with it. It is somehow linked to the way things are implemented in code but it seems unnatural, people expects a more physical On/Off state.
- Make it binary, with an ON/OFF state. Switch would toggle between On/Off, button would either produce a On signal for a short amount of time, or produce a signal as they are hold by the player. (tbd)
- tight coupling between the gates. That mean that a gate state is directly synced to its predecessor. If you want several link in the same input, then you need to use a Logic gate and select the behaviour: AND, OR, XOR ect. I think it make it more straightforward and reduce the risk of network desync.
- To control rotor and slider I would introduce the Controler brick. This would replace the constant and mix gate. It would connect to a rotor or slider, and would execute a sequence when active. You could add any number of value:
1 value: the system would go to the specified value all the time (equivalent to the constant gate),
2 values (equivalent to the mix gate). In Off state the system would go to value A, when active it would go to value B. Once deactivated it would go back to A.
3 or more value: system would then go in sequence: A when off, then when activated go to B first then C. Then it would ping pong back to C -> B -> A when deactivated. - Each rotor / slider would come with a built-in controller so you dont have to place a brick for simple system.
- Controller would override themselves, that mean the system would execute the controller which was last activated. I would do this so you can make elevators easily for example, but it is in contradiction with the tight coupling rule - I dont see a better option, do you?
- Controller can be linked to several systems. It would then be easy to have several systems working in sync, like to open a landing gear trap first, then the landing gear itself. This is inspired by Scrap Mechanic if you played that game.
- Callback function is built-in in the system itself: link the system to something and it will propagate its value change after it stopped moving.
- Sliders would act at a constant controller, but could be only connected to system (not to gate)
Also what other games are doing? Sorry it feel a bit rushed but I will most likely commit to that in the coming days as I would like to bundle the two update (logic + link tool)
