Logic: not working, bad way, improvements

Discussion in 'Suggestions' started by LukeStrike, Sep 3, 2017.

  1. LukeStrike

    LukeStrike Ensign

    Joined:
    Dec 19, 2016
    Messages:
    10
    Likes Received:
    7
    Sorry guys but your "logic" system is ... <no comment> :p

    Any device that support logic MUST be able to accept input AND output. The way you did that (you have to choos between input/output) is just absurd. Some examples:

    1) a switch and a door: ok. You switch on, the door opens. Ok. But what if you close your door manualy ? The switch will not follow the door state, that is off, just because the switch can only be in output, and the door in input, and not the reverse. The real thing is that the switch AND the door should follow themselves. That means accept input AND output. The door follows the switch, and the switch follows the door, that's it.

    2) you cannot propagate signals, witch is a master fault in logic. Why if for example I open a door, that will propagate the signal to another door, why this 2th door cannot propagate it to a 3th one ??? That stupid no ? just because the 2th can ONLY receive OR send ... Not both. Yeah ...

    3) same for a lot of things, look at for example, my proposal of having an "Automatic" option for the shutters, doors, etc ...

    LKS
     
    #1
  2. Gawain

    Gawain Commander

    Joined:
    Aug 13, 2017
    Messages:
    177
    Likes Received:
    99
    The only issue with this is logic loops.

    Example if door A opens than close door B, If door A is closed than open door B, if door B is open than close door A.... Endless Loop.

    There are already more complicated ways to make endless loops but they need a method to brake loops before they can introduce better logic.
     
    #2
    geostar1024 likes this.
  3. Frigidman

    Frigidman Rear Admiral

    Joined:
    Mar 19, 2016
    Messages:
    4,675
    Likes Received:
    6,590
    Its a "Signal" system. You have triggers and receivers. Its not really a full blown wired CPU-driven logic system like that.

    As for doors and shutters to be or not to be automatic........... sooooooo many people want a checkbox for that behavior, trust me ;)
     
    #3
    Exacute and Gawain like this.
  4. Hummel-o-War

    Hummel-o-War Administrator
    Staff Member Community Manager

    Joined:
    Jun 15, 2015
    Messages:
    4,273
    Likes Received:
    5,721
    This.
     
    #4
    Fractalite and Exacute like this.
  5. LukeStrike

    LukeStrike Ensign

    Joined:
    Dec 19, 2016
    Messages:
    10
    Likes Received:
    7
    Yeah I know about the "endless loop problem". But trying to resolve it by "cutting circuits" this way (having only the input or output option) is not the good choice, sorry. You must think in term of "instant signal" (or "pulse"). That means that any device that has been involved in a signal propagation at the time T will be idle until the signal stop to be propagated (has reach the end of the "tree").

    So if the door A activate the door B, even if the door B is set to activate the door A, because door A was alreeady part of this "pulse", she will not react within the same cycle. Only after the resolution of this pulse, another event for example on the door B can propagate to the door A.

    There is also other ways to resolve the problem (for example limiting the actions counts to break any endless loop) but this one is not the worst ;) (except if you allow players to play ping-pong just for fun :eek:)

    LKS
     
    #5
  6. geostar1024

    geostar1024 Rear Admiral

    Joined:
    Jan 24, 2016
    Messages:
    1,410
    Likes Received:
    1,751
    And what if you insert delays and split signals repeatedly? It will start to be prohibitively complicated to track these pulses.
     
    #6
  7. Hummel-o-War

    Hummel-o-War Administrator
    Staff Member Community Manager

    Joined:
    Jun 15, 2015
    Messages:
    4,273
    Likes Received:
    5,721
    Yes, not allowing to "feed back" the singal from the receiver directly to the sender is of course a no-brainer..but as all signals are "instant", you just need to insert a different receiver..like geostar pointed out...and you run in the same problem as this still will create an endless loop.
     
    #7
  8. Nogitsune

    Nogitsune Commander

    Joined:
    Jul 16, 2017
    Messages:
    178
    Likes Received:
    140
    Include a bitfield in signal that flips to 1 a marker for each logic rule instance on the list that it has 'touched', and terminate a branch that tries to touch an already marked circuit. I don't know what the limit is for number of circuits you can add to the list, but assuming it's no more than say 256, you'd just need four 64-bit values for tracking a signal.

    If repeated splitting of signals causes problems in itself, that's a separate issue - and maybe in that case there should be some limit to this. A counter that is increased each time signal is split, and terminates a branch if it gets too high.

    Another possibility would be to include a plain counter that limits how many circuits the signal can pass through regardless of if they are loops or not. For example after signal has passed through 128 circuits it will terminate. Split signals inherit the counter from their root.

    This would still require that signal that activates a device (e.g. door) will continue as same signal if the device activation triggers something. So f.ex. for the door, if signal opens the door, and opening the door will trigger another 'event', it'll be treated as if the same signal had passed through the door and continued on. And again if the opening triggered multiple 'new' signals, they would each inherit the values from the signal that opened the door.
     
    #8
  9. geostar1024

    geostar1024 Rear Admiral

    Joined:
    Jan 24, 2016
    Messages:
    1,410
    Likes Received:
    1,751
    This ought to work; the key part is the inheriting of the counter. Even still, you could make quite a fork bomb, though at least it'd terminate at some point. Though, since all of the effects would take place on the local ship, it might not have any performance implications for MP (besides possibly generating lag for that player).
     
    #9
  10. Nogitsune

    Nogitsune Commander

    Joined:
    Jul 16, 2017
    Messages:
    178
    Likes Received:
    140
    Shouldn't be difficult. Use shared counter instead of inherited, so each time the signal passes through logic circuit on any of the split threads it created it'll increase the counter. If you fork 50 threads, the counter goes up by 50 when each of the threads has passed through just one circuit. The fork bomb would be snipped in the bud.
     
    #10
    geostar1024 likes this.
  11. Dinkelsen

    Dinkelsen Captain

    Joined:
    Aug 2, 2016
    Messages:
    533
    Likes Received:
    756
    FYI it IS possible to feedback signals to create an Oszillator.

    Sort of...

    You need 2 gravity generators, 2 motion sensors and a player entity. Then the player can fall from one gravity generator to the other triggering the motion sensors which alternately switch the gravity generators on and off.

    The player entity is the expensive part here. Too bad it does not work with HVs.
     
    #11
    Mortlath likes this.
  12. geostar1024

    geostar1024 Rear Admiral

    Joined:
    Jan 24, 2016
    Messages:
    1,410
    Likes Received:
    1,751
    Any idea if the lightbeam sensor is triggered by entities other than the player and ships? If so, then one could make a clock out of dropped objects or spawned mobs.
     
    #12
  13. Dinkelsen

    Dinkelsen Captain

    Joined:
    Aug 2, 2016
    Messages:
    533
    Likes Received:
    756
    I think they don't. I cannot recall mobs triggereing motion sensors (and turning on lights) in my POIs. Another problem is the delay gate that I think acts a little random. It does trigger, but the time for the delay has not much to do with what you put in the text box.
     
    #13
  14. LukeStrike

    LukeStrike Ensign

    Joined:
    Dec 19, 2016
    Messages:
    10
    Likes Received:
    7
    Not pretty sure about what you said guys, but I will "up" my question/suggestion ...

    All is a matter of "ticks" and most of games that include logic system handle that +/- well, so why not EGS ? So for example:

    Tick 1: door open => light on => airvent on ... nothing else
    if airvent is switched off, it is another thick so:
    Tick 2: airvent off => light off => door closed
    if any of those devices are connected, you can also imagine:
    Tick 3: light on (again) => airvent on => door open

    I don't see where there is a risk of "endless loop". If you have:
    Door A when opened will close Door B, when closed will open Door B, and Door B will do the same with Door A (typical example of an air tight) , where is the problem ? There will be no loop because all is treated in one tick (or "pulse" if you prefer). So if I change the state of the Door A open<=>closed it will impact the state of the Door B only ONCE. The effective change of the Door B will NOT impact the state of the Door A that will again impact the state of the Door B that will ... etc (a loop). Just because all actions are treated in one tick, that means that once one device has been affected (state modified) it will NEVER REACT to any new signal within the same tick (a kinda of "idle state/job done").

    I dont see the same way any "delay" problem ... because delay is a separete tick, in the future. So:
    Door A open => Delay X
    X ticks after:
    Delay X => Door A closed

    But I'm not pretty sure about the implemented input system. For me, a door should be able to receive a "open" signal, and on anothe "slot" a "close" signal. It will be more easy to design systems that allows for example to have an air tight that will respond to the example I gave, except that you can also decide to implement a "master switch" that will close all the doors, for example in combat situation (no air tight allowed :p)

    LKS
     
    #14
  15. geostar1024

    geostar1024 Rear Admiral

    Joined:
    Jan 24, 2016
    Messages:
    1,410
    Likes Received:
    1,751
    It's a lot simpler if you just allow limited loops (signals carry a counter with them and are terminated after going through some number of circuits and splits), in the manner of @Nogitsune's suggestion; you don't need any complicated rules to prevent feedback.
     
    #15
  16. LukeStrike

    LukeStrike Ensign

    Joined:
    Dec 19, 2016
    Messages:
    10
    Likes Received:
    7
    As I told you there is no risk of infinite loop if you handle the tick/idle concept.

    LKS
     
    #16

Share This Page