I recently had a request for a tutorial on how to set up the logic circuitry in my TFD-138 KAYUT ship, which can be found on the Steam Workshop. I'm going to try my best to break everything down as best as possible, though I can't promise it'll make perfect sense or be easy to follow along with. There is also a section near the end where I use an Inverter and Set/Reset Latch circuit to perform a couple functions that I honestly had to guess at, so while my explanation may be a bit off here, it somehow worked out nicely. There may be a better way to perform these functions, so please feel leave me some comments on how I can make this logic circuitry more efficient, and more importantly, fool-proof. Basically, this tutorial with outline how you can go about creating circuitry to simulate a Red Alert condition on a ship. It's not difficult, but I've gone to great lengths to break everything down to explain it as clearly as possible, so make sure you've set aside some time to properly read through this tutorial. The first, and probably the most important tip I can leave here, is to MAKE SURE YOU PAY ATTENTION TO HOW YOU NAME YOUR CIRCUITS, SIGNALS, AND ALL DEVICES that you plan to have controlled by any custom circuitry. The more complicated your build gets, the more components you will have to account for, which can make things very confusing if not organized in a way that you can easily trace. I recommend planning your circuits out on paper so you have a nice reference to work with. If only to write down the names of each item you're working with, this will help A LOT. Also, try to come up with a way to consistently name different components. While not done all that well in KAYUT, I've recently started using a system to name things, which basically involves literally putting "SIG/SEN/LEV" in the device name, to make it easier to find and use later on. That device's Signal Logic Name (Tx Signal in-game) also shares the same name to keep things simple and organized. Before you continue on, please note that THIS TUTORIAL CORRESPONDS WITH THIS DEMO BUILD. If you try to follow along while looking at the actual KAYUT ship, you'll get lost. All of the component/signal names are a bit different; I made the demo build so that I could rename everything to make a bit more sense, and make it easier to follow along. This ties in to my tip above; as I was writing this tutorial, I realized that while I knew my way around KAYUT's circuitry, the naming convention I used was very confusing.
THIS TUTORIAL CORRESPONDS WITH THIS DEMO BUILD. DOWNLOAD IT NOW IF YOU HAVEN'T, OR YOU WON'T BE ABLE TO FOLLOW ALONG! Device Definitions There are definitely a lot more devices used on KAYUT than in the demo blueprint, but I've decided to cut most of these out and replace them with a simple light to show you that they are functioning. Here's a complete list of every device used in the demo blueprint, and what their primary purpose is (or rather, what they represent on the actual KAYUT ship): - FakeSpotlight (represents the spotlights) - FakeMissileDoor (represents the ramp shutters used to protect missile launchers; light ON represents door open) - FakeHullLight (represents all exterior lights, with the exception of the 2 thruster accent lights) - FakeThruster (represents all thrusters, RCS, and the 2 accent lights) - CabinLight (represents the white light inside rear cabin) - CabinLightRED (represents the Red Alert light inside rear cabin) - EntryLightRED (represents the red light inside entryway) - SpotlightLEV (actually a Custom Signal in KAYUT; toggles spotlights) - HullLightLEV (actually a Custom Signal in KAYUT; toggles exterior light blue hull lights) - BattleLEV (a physical Lever in KAYUT; toggles Red Alert Mode) - ThrusterLEV (actually a Custom Signal in KAYUT; toggles thrusters, RCS, 2 accent lights) - MissileLEV (actually a Custom Signal in KAYUT; toggles missile ramp shutters) - CabinLightSEN (toggles white light inside rear cabin) - EntrySEN (toggles the red light in the entryway, as well as the overhead hatch) - EntryHatch (literally the overhead hatch to the top of KAYUT) 2x OR Logic Circuit Definitions There are 5 primary components in the 2x OR circuit list, identified by the name given in the RIGHT-HAND box of each circuit: - ENTRY LIGHT (turns EntryLightRED on/off, also opens EntryHatch) - ENTRY HATCH (opens EntryHatch, but also tied in with an Inverter, explained in next section) - HULL LIGHTS (turns FakeHullLight on/off) - MISSILE DOOR (turns FakeMissileDoor on/off) - THRUSTERS (turns FakeThruster on/off) These act sort of like "overrides", which I will try to explain first (as they are the most simple concept). Basically, if ANY of the circuits above are toggled ON, their functions will be activated. BattleLEV will actually activate ALL items at once through the use of the 2x OR circuits. To set this up, we need to follow a simple formula to control any of these physical items: A or B = C. - A is the first signal that you want to use to control a specific device/function (can be a Lever, Motion Sensor, Custom Signal, etc) - B is the second signal that you'd like to be able to use to control a specific device/function. In this case, B is always going to be BattleLEV - C is the combined result of either A or B being toggled ON, and this is the signal that we are actually going to use on the devices themselves for them to "Follow" Let's take the FakeHullLight as our working example here. I've set up a Lever called HullLightLEV, which would obviously toggle the outer hull lights ON or OFF. In the actual KAYUT ship, this (along with the other 3 adjacent switches) are set up as Custom Signals in the control panel; I chose this method primarily due to lack of space inside the ship itself to put multiple physical Levers. HullLightLEV (A), along with BattleLEV (B) (which could be a Custom Signal or a physical Lever, as used in this case. It could also be both, but would require an additional 2x OR circuit here) are both tied together by a 2x OR logic circuit called HULL LIGHTS. That means that A (HullLightLEV) or B (BattleLEV) will act as together C (HULL LIGHTS). The actual devices themselves (all of the exterior hull lights on KAYUT) are set to follow HULL LIGHTS. Therefore, when A or B is switched ON, C is switched ON. Three conditions can be set using the 2x OR circuit: - If A or B is ON, C is ON - If both A and B are OFF, C is OFF - If A and B are both ON, C is ON Using this knowledge, we can set up the remaining 2x OR circuits this way. On KAYUT, I've set up the Thrusters, RCS, and 2 deep blue accent lights (FakeThruster) to be controlled by the logic circuit called THRUSTERS. ENTRY LIGHT and ENTRY HATCH control EntryLightRED and EntryHatch respectively, and MISSILE DOOR controls the missile doors (FakeMissileDoor). Pretty simple so far, right? WRONG. Let's move to the inside of the rear cabin. In here, we have CabinLight, along with CabinLightRED that only turns on when BattleLEV is ON. Why isn't this simple? If you tinker around with the ship enough, you'll notice that whenever you walk into the cabin, CabinLight will turn on, while leaving this room will shut the light off. Switching the BattleLEV ON, CabinLightRED turns on in the cabin, but... NO MORE WHITE LIGHT! And wait, what's this, you say? EntryHatch no longer opens, and EntryLightRED is also turned on? RED ALERT STATUS, YO. This is where things start to get a bit more complicated (along with my aforementioned guesswork), so my apologies if this section doesn't read well. Inverter, Set/Reset Latch, and 2x AND Logic Circuit Definitions There are 3 additional logic components needed to make all this work, identified by the name given in the RIGHT-HAND box of each circuit. They are used to arbitrarily modify the state of the 2x OR circuits listed above: - HATCH RESET Inverter (reverses the function of EntryHatch AFTER it passes through its logic gates, which is then inverted AGAIN on the hatch itself (so that it functions correctly when standing within its linked Motion Sensor range). This allows me to basically "disable" the Motion Sensor EntrySEN for the hatch while in Red Alert Mode) - LIGHT RIG Set/Reset Latch (basically disables the entryway light Motion Sensor when BattleLEV is on. This is why we need the Inverter) - CABIN LIGHT 2x AND (allows EntryLightRED to be affected by both the Motion Sensor AND the Set/Reset Latch) Let's just get this one out of the way first: CabinLightRED is ONLY controlled by BattleLEV. The only time it needs to be ON, is when BattleLEV is ON. Let's get that Red Alert condition to work, shall we? Next is where things got a bit complicated for me, and I had to do a little bit of guesswork/research on which Logic Circuits needed to be used to produce the desired effects and functions. In short, I wanted CabinLight, EntryLightRED, and EntryHatch to function normally when the BattleLEV is in its OFF position, which means the Motion Sensor EntrySEN will control EntryLightRED and EntryHatch, while CabinLightSEN controls CabinLight. When BattleLEV is ON, EntryLightRED should remain on at all times, EntryHatch functions in its default manual operation mode (I originally wanted this to be locked, but locking doesn't quite work properly in Empyrion right now), and CabinLight will be disabled, instead replaced by CabinLightRED. As mentioned previously, BattleLEV will also turn ON all thrusters (FakeThruster), hull lights (FakeHullLight), and will open the missile doors (FakeMissileDoor) on KAYUT. To me, this seemed like the most realistic way to represent a "Red Alert" condition in a ship. If you wanted to skip this section and just keep things simplified, you could simply link EntryHatch to EntrySEN (along with EntryLightRED), and that works just fine. Unfortunately, you lose the ability to "lock/unlock" this hatch (basically, it just makes it manually operated rather than being triggered by the Motion Sensor). The same could be said with CabinLight, in which this light will still turn on during Red Alert conditions when you walk into the rear cabin. I didn't want this to happen, because during a Red Alert condition, the ship should only have RED lights on throughout, and any exterior doors should lock, effectively creating a "lockdown" atmosphere. To accomplish the hatch lockdown, we need to essentially "shut off" the Motion Sensor EntrySEN that controls it. We can do this by passing it through an Inverter BEFORE we actually pass it through its open/close logic gate. Now we can use HATCH RESET and BattleLEV to control the hatch itself. When BattleLEV isn't used, EntrySEN functions normally for EntryHatch. For the cabin lights, we need a way to RESET the state of CabinLight to OFF whenever BattleLEV is ON. We can do this with a Set/Reset Latch logic circuit called LIGHT RIG, which works like this: you SET the state of the light originally using a Motion Sensor. In RESETTING this with LIGHT RIG, CabinLight returns to its default state, which is OFF. When BattleLEV is set to OFF, the Motion Sensor CabinLightSEN functions normally, and the white light CabinLight should turn on and off as normal. Again, CabinLightRED is controlled directly by BattleLEV, so there's no need for additional logic here. I've then used a 2x AND logic circuit to couple these circuits together, giving multiple ways to control these lights. We need to use the 2x AND logic circuit for CABIN LIGHT, rather than a 2x OR, because we need to be able to retrieve the state of the light AND account for the state of BattleLEV at the same time, to force this condition. Final Notes Technically speaking, I think you could use either technique (HATCH RESET Inverter or Set/Reset Latch) to accomplish both the hatch lockdown AND the cabin lights, but it works perfectly this way, so I haven't bothered with trying to experiment too much further... yet. I do know that the majority of other possible configurations either don't work exactly as I want them, or the circuitry becomes awfully convoluted (much like this tutorial at this point), and that was something I wanted to avoid. One of these methods involves using NOR logic circuits to determine the state of the devices you're trying to control, but again, I felt that going this route involved quite a bit more work (although it is very possible; experiment!). Anyway, the idea here was to try and create a proper Red Alert condition using as few circuits as possible to keep in streamlined, yet functional and expandable. Using these guidelines, one would be easily able to chain more and more rooms, doors, lights, and whatever other devices you want into the same ship, and still have everything work perfectly. That said, I have an upcoming Cargo SV, one that's a whopping CLASS 18 (so far; it's only 75% finished!) that showcases these exact techniques and MANY more, which I will hopefully be releasing by the end of this month. Again, I really apologize if any of this was difficult to follow along with. I spent a lot of time not only writing (and formatting!) this entire tutorial, as well as building the demo blueprint, so please try not to be too harsh in your comments. What I would really appreciate is help on a better way to explain the last section about 2x AND, Inverter, and Set/Reset Latch functions, as I feel I didn't explain it very clearly. I'd also appreciate any help on improving both the readability of this tutorial, and the actual circuitry on the demo blueprint itself, if you think you have better ways of accomplishing any of it! Thanks for taking the time to read through all this I wrote this tutorial and built the accompanying demo blueprint in a few short hours. I'm sure that there are many mistakes, along with some of it probably not making any sense. I'm very sorry for that, I did the best I could to break everything down as best as possible so that you can not only recreate the exact same circuitry used in KAYUT, but so that you can also expand on these concepts and hopefully create your own logic systems. Please feel free to ask questions or make comments on how to improve the tutorial and actual build! Thanks
Nice work! I've done something similar to what you did and the logic was a nightmare! https://steamcommunity.com/sharedfiles/filedetails/?id=1255761185 I will echo what you say about developing a naming convention. Yes, renaming stuff takes time, but you'll regain that time through being able to find and trace your logic later during troubleshooting and testing. By the time I was finished my build I think it was up to 3 pages of logic operations, and if you try understanding that many circuits without a logical obvious naming convention your head *will* explode. Another suggestion would be to actually physically write down the basics of your intended logic chain. When I did the above ship my first attempt actually failed because I couldn't keep all the needed logic in my head and kept having to add steps earlier up the chain which then required re-wiring the earlier txSignals, which in turn made the naming logic confusing. In the end I ripped it all out and wrote it down. After that it was a lot simpler to hook up, although, it still took me well over 3 hours to set up the logic then link all the devices in.
Really good tutorial mate, I have set up a few flashing lights and screens in some builds but is a real shame we can't make them flash indefinitely Also a shame we can't have different stuff showing in the same screen depending on conditions yet We still need a script/code block for that
Glad you guys liked the tutorial and hopefully found it useful. @Kaeser Yes, it is a shame that we can't create blinking lights. I was only able to go as far as chaining a couple of delays and set/reset latches together to try and make it blink, but I can only get it to turn on and turn back off after a couple seconds. I can't figure out a way to loop it so it turns back on again, although I'm stubborn enough to keep trying. I feel like we have the necessary logic circuits available to us to make it happen...
I believe Logic can't be linked into itself on purpose; so the trolls of the internet can't set up lag inducing systems using it. Makes me sad since that makes flashing lights practically impossible. No fancy landing pads for us :/ The only way to blink that I can think of would be a chain of timers, with a few extra variables: waitingToActivate, Activated. Then the main activation sensor can set Activated to ON IF waitToActivate is OFF. Activated can trigger the first timer, set Activated to OFF and set waitToActivate to ON. The last timer would set waitToActivate to OFF. In theory this should make a single ON tick enter the timer and prevent secondary ticks entering until the blink cycle is complete. If you happened to be standing in the sensor zone this should act as the loop portion. Another method could be to use a SR Latch for the isolation part; First timer sets it, then make another timer that combines the total blink time and have that disable it.
Hah, I just spotted something of interest: " You can now set Hotkeys for console commands. Having SI turned to off, godmode on, teleport and more can be activated at the same time with a simple hotkey click! Automated doors now have an override priority for Sensors: if you add a sensor/signal to a door, the door-integrated auto-opening will not be triggered. Devices with Sensor Input and Output fields can now send and receive signals. Before, SEND did not work as long as the device was set to listen/receive signals at the same time. Note: you cannot create blink-lights this way, because of an integrated Loop-Protection. But we will add a proper "blink lights" feature in the course of the 8.x development!"
Why don't the developers just add a flashing light to the game with a flash on and flash off time parameters as well as color and intensity? I would use them as hanger runway lights flashing sequentially instead of all the bs it takes to rig it now.
If the intention is to never allow circuits (/game logic) to run anew, this def. seem like the best path to take, yes.
Nice work, lovely looking ship. I'll spawn this later and check it out. Is there any group available to develop on the signals/switches use? I did post in the forum but it has had limited responses. Be good to get a few people together to see what nice configs we can up with.
@Virtualburn thank you for the compliments. If you use Discord and are looking for an active, creative, and very knowledgeable group to join, I would suggest jumping in Zero-G's Discord (ran by the wonderful @Jenniphurr ).
