Advanced Signal Logic or "Beyond the Basics"

Discussion in 'Knowledge & Info' started by JayStrider, Aug 11, 2020.

  1. JayStrider

    JayStrider Lieutenant

    Joined:
    Jul 15, 2020
    Messages:
    10
    Likes Received:
    42
    Hello!

    I've spent a decent bit of time working logic/control puzzles in EGS. It's sort of a meta-game I've been enjoying a lot. I really haven't seen signal logic discussed to this degree anywhere else at this point, so I wanted to share some "beyond the basics" logic I've incorporated into my main vessel.

    My main vessel is a modified version of Jeff Randall's MCRN Pioneer -- which is an amazing ship, and I'm a huge fan of all his Empyrion work, generally. According to one of his YouTube videos, Jeff likes using the hard switch devices to turn functions on/off for immersion reasons. Ironically, I avoid using hard switches and prefer to use the P menu switches also for immersion reasons :). So, all the logic I used in this vessel was to maximize the use of the 8 signal switches on the P menu.

    At first I just started to tinkering with it to do different functions sporadically as I thought of them. As the things I thought of became more complex I had to get more methodical. I really had to get organized.

    In order to do this, I first made a list of all the switch functions I'd like to have in the P menu. Right off the bat there are a couple of really obvious choices. I knew I'd want a "low power" mode for when I log out or just need to park somewhere and step away. Conversely, I knew I'd want some kind of a "battle station" or "red alert" mode that would ensure the shield, turrets, and thrusters were all in a max power state when engaged with hostiles.

    From there, I began exploring what logic I'd need. While doing so, it quickly occurred to me that I also needed to know all the things that power on and off. I also needed to cross reference that with my 8 modes. By design, one mode might turn something off and a different mode might turn it on. Furthermore, different modes would have to have different priorities. For example, I wanted low power mode to turn off thrusters whether a thruster mode was on or not; and I wanted Battle Stations to turn them ON regardless of what any other mode was doing. I didn't want to have to switch a bunch of stuff on/off every time I left the ship/game or in the heat of the moment when a hostile pops up on the radar.

    So, I made a grid of what turned off/on for every mode, then a list of priorities -- i.e. what mode would override the other. When looking at this grid and list, it was becoming fairly complex with the logic.

    List of P-menu Signal switches (Final, prioritized)
    1. Battle Stations
    2. Min Power
    3. Park / Defensive Dwell
    4. Mine Ore
    5. Cruise
    6. Shield
    7. Thrusters Std
    8. Hvy Thrust
    Note: I didn't want a shield switch since there's already a built-in one. I had to add it for reasons I'll explain at the end.

    P_menu_200810.JPG

    List of devices/functions I might want to switch on/off with different modes:
    1. Grav generator
    2. Shield
    3. Weapons
    4. Thrusters (Partial)
    5. Thrusters (boost)
    6. Drill Turret
    7. Warp Drive
    8. Repair station
    9. Constructors (including food proc)
    10. Growing Lights
    The Grid:
    Logic Grid.JPG
    (Legend: O - should turn OFF with the mode on left, X - should turn ON with the mode on Left, blank means it’s independent of the mode on the left.)

    Note: I killed a couple devices/functions from the list, like grow lights, because the effort wasn't worth the result.

    To aid in figuring out what I needed to do with the logic, I found a couple cool websites that simulate gate logic and created a few generic scenarios. As I refined them, I learned that, while the scenarios could get complex, I only need a few variations of the same type to do 90% of what I wanted. The other 10% either required more signal switches on the menu (like 1-2 more) or simply were not possible -- e.g. being able to trigger another trigger or conditionally being able to switch between the signal types (follow/on/off/etc).

    Anyway, in the end, I was pretty happy with what I came up with, so I figured I'd share...

    A few Disclaimers:
    1. The following examples may not be bug free. Some more complex interactions may not work 100% as expected/intended.
    2. The effects of the logic depend on whether it's followed/on/off/latching. I try to describe what's desirable per scenario, but I might have omitted some info.
    3. I don't presume that this is a guide -- I'm not a good teacher. I'm hoping it will be more of a discussion/exchange -- learning how to do cool stuff in EGS.
    4. I made the logic on the circuitverse website at work. So, on the circuitverse circuits I linked, the wording/descriptions are generic to keep me out of trouble. Sorry.
    5. This post assumes you already have some basic working knowledge of how to use signals and circuits. There are many great posts and videos available on the topic created by folks a lot more talented than me if you don't.

    In the following examples, the links to circuitverse are interactive. The left side represent switches that can be on or off (typically representing the P-menu signal switches). The right side is the final output which the device(s) will either follow/on/off. In either case, zero is off, 1 is on. If you press the input "switch" (SW) on the left, you can see how it affects the output on the right.

    Note 1: circuitverse doesn't have greater than 2x gates (such as a 4x OR), so I had to create them by using multiple 2x ones. If I did so, I put a box around it and labelled it by its equivalent gate: e.g. "4X [something]". That is, everything within the box is the equivalent of that one gate.

    Don't get bogged down in the symbols. The descriptions and labels are what matter.

    Note 2: I couldn't rename the saved circuits without also remaking them from scratch. I was too lazy to do that, so ignore the titles. They made sense when I named them, but they are pretty meaningless in hindsight...

    Example Function 1 (Ref 03):
    A simpler one to get our feet wet. "Output B is ON unless inhibited by SW A."
    REF 03.JPG
    Go here to interact with it: https://circuitverse.org/users/30668/projects/normally-on-with-inhibitor

    B is normally on, and A is normally off. If SW A is turned on, B will turn off.

    Ex: if B is a thrusters signal sw and A is low power mode SW, when low power is turned on, the thrusters will turn off.

    If you choose to FOLLOW the B signal on thrusters, then they would also turn ON when you turned Low Power SW OFF.

    If you choose to use OFF for the B signal, turning the Low Power SW ON would turn the thrusters off and leave them off when you turn low power mode back OFF.

    This simple function requires no "circuit" in game. You can just tell the device or group to FOLLOW the switch with the "I" box checked OR to turn OFF instead without the invert box checked.

    Full disclosure: I don't use this anywhere. It's just a good starting point for discussion/investigation.

    Example Function 2 (Ref 02):
    "SW ON/OFF with inhibitor SW and Override ON"
    REF 02.JPG
    https://circuitverse.org/users/30668/projects/follow-on-inhibitor-emergency-override-on

    This one follows a scenario where I have a “Thrusters ON” SW, a “Low Power” SW, and a “Battle Stations” SW. Some thrusters will be set to follow the output to the right.
    1. Normally, the Thrusters will follow the "Follow SW". ("Thruster ON" SW)
    2. Regardless of the state of the Follow SW, if you hit the Inhibitor SW ("Low Power" SW), the thrusters will be forced off.
    3. Regardless of the state of the other two, if I hit the "emergency override" SW ("Battle Stations"), the thrusters will turn ON.
    Note: if you're thinking: "but I already have a built-in 'thrusters' SW, why have another?" ... Think partial thruster use. But...it's just an example anyway. It could be any number of things. Which leads to the next example...

    Example Function 3 (Ref 02XP):
    This is an expanded version of the previous one. It uses multiple inputs for ON, multiple inputs of inhibiting, and a single override.
    REF 02XP.JPG
    https://circuitverse.org/users/30668/projects/rx-1-with-override

    Same as previous, but now, if you have a "Cruise" mode, a "Thrusters" mode, and a "mining" mode; you have a "low power" mode and "park" mode; and finally you have a "battle station" mode again. Any one of the first three will turn the thrusters on. Either of the two inhibitors will override those to turn them off. As before, the Battle Stations override will make them turn on no matter what.

    Example Function 4 (Ref 01):
    Single function SW ON/OFF with multiple OFF overrides.
    REF 01.JPG
    https://circuitverse.org/users/30668/projects/follow-on-override-off

    This is actually a similar but simpler version of the one above. The difference is that the "emergency override" does the same thing as the other inhibitors. Instead of overriding to turn it back ON, it also wants to turn it back off. So, the only time it's on is when the one switch is on, but it's off for several other reasons.

    Here's a use-case to explain it...
    I have a Drill/Mine switch. When I turn on the switch, it will activate the mining turret (along with some other things, which go with different logic such as thruster logic above). When I hit "battle stations" or "park" etc, the turret will deactivate even if the mining SW is still on. If the mining SW is still on when I turn off the overrides, then the turret pops back out. If the mining SW is off when I switch them off the turret stays off.

    That's about as complicated as it got. Some individual functions require more explanation, but from there, the other scenarios are easier (surprisingly so). Here are a couple of easy ones:
    1. I want to switch the repair station and constructors off when in low power or battle stations. I just need one multiple OR.
    These devices can be set to OFF or FOLLOW depending on preference. For example, if I'm building something, then hit battle stations, then switch it off again: OFF mode will leave constructors OFF until you turn them back on manually; Follow mode would make them (ALL of them) turn on. Because I usually don't want them ALL to come on just because I turned Low power mode off, I use OFF mode.

    2. I want weapon turrets to definitely turn on and stay on when I'm parked, cruising, in battle stations, or low power mode. So all I need is a multiple OR signal ON (as opposed to Follow, off, etc) for the weapons. I can turn them back off manually with the built-in switch if I want.

    I wanted to use the built-in switch for the shield, but I wanted the low power switch to turn it OFF (and stay off) and for it to FOLLOW the Battle Stations SW. There's only two ways I can think of to do this:
    1. Have a conditional signal that sometimes uses the follow mode and sometimes uses the off mode. (This is not possible.)
    2. Just turn it on and off by following battle station. Doable, but clunky -- won't get into all the reasons why.
    3. Do it like Ref 02 (Function 2), but without any signal switch for Shield. The "Follow SW" in Ref 02 must be signal. It can't be the built-in SW.
    I finally concluded that, in order to do this function, I have to allocate Shield to a signal switch even though it's already a built-in switch. This is the only reason I have a Shield signal switch.

    This seemed like it would be the easiest of all the use cases. I spent more time trying to solve this problem than any of the others. This was mostly due to stubbornness -- I was pretty sure I was just not seeing the right solution. Heck, it's entirely possible I'm still overlooking a more elegant solution.

    As I mentioned before, I enjoy working these little logic exercises. This wasn't intended to be a guide, but just sharing what I did for my current favorite vessel. I'd be more than happy to discuss any of it, and I'd love to hear what y'all are doing -- if there's better ways to do these things or if you know of some cool tricks to share.

    --

    Additional References:

    Here's my mod'd version of Jeff Randall's Pioneer if you want to see the logic/signals:
    https://steamcommunity.com/sharedfiles/filedetails/?id=2193876135

    Here's a logic HV I made to illustrate these signals (and what I used in the videos below):
    https://steamcommunity.com/sharedfiles/filedetails/?id=2193876959

    Here are a couple videos I recorded really quick to walk through this stuff:
    Part 1:

    Part 2:
     
    #1
  2. Twinsen

    Twinsen Ensign

    Joined:
    Sep 15, 2022
    Messages:
    2
    Likes Received:
    1
    I know this post is a little old but I just wanted to thank you for the videos, example vessel, and the ship. I'm working on my first CV and the information you took the time to share is invaluable. Thank you SO much!
     
    #2
    JayStrider likes this.
  3. Twinsen

    Twinsen Ensign

    Joined:
    Sep 15, 2022
    Messages:
    2
    Likes Received:
    1
    Hi Jay,
    Not sure if you even look at these old posts of your anymore. I'm new to this stuff and this is probably a stupid question but I have a question about the logic you did on your mod'd version of Jeff Randall's Pioneer. There is a XOR circuit I don't understand. It has "Low P OR S1" and "Low P OR S2" going into it and the output is "Always 0 S1". I've gone over every device and circuit multiple times but I don't see anything triggered by "Always 0 S1". Can you tell me what this circuit does? I'm sure I've missed something. Like I said I'm new to logic circuits but I'm trying to learn.
     
    #3
  4. JayStrider

    JayStrider Lieutenant

    Joined:
    Jul 15, 2020
    Messages:
    10
    Likes Received:
    42
    Hey Twinsen,

    I honestly haven't played in probably over a year or two, so I had to reinstall and remember everything I had done with this. It took me a while to even remember how to spawn the CV.

    I looked through it for a while, and it appears that you are not missing anything. It may have been an unused section that I neglected to remove before posting it. Perhaps I had intended to do something with it then found a simpler way. If it ever had a purpose, I've long forgotten what it was.

    In principle, I do understand what it is. It is an "always off" signal. No matter how you flip the inputs, the output will always be off. With logic, something like this might be used where the output can be directly manipulated. By assigning a bit of logic that can never be true, you ensure that even if the output was directly accessed, it still can't be turned on -- because the logic would keep it set to "off".
    Here's a circuit I threw together that mirrors what's in there...
    https://circuitverse.org/users/30668/projects/always-0-s1

    Either with the benefit of hindsight or due to the misfortune of a poor memory, it appears to me now as completely unnecessary logic in EGS. So, that's a really good catch on your part! Oh, and I appreciate the kind words above. Glad you're getting something out of it!

    Hope that helps!
    Jay
     
    #4

Share This Page