Possible Logic Bug

[Vitulus]

This is probably a bug in logic. If no ones knows how to fix Ill upload to bug tracker. If this is a bug I really want a work around!

Ok so let me explain.

This glitch happens when you deactivate a block and activate it again on the same logic tick.
Video:
(If you can't see it - I'm still uploading)

I did this by connecting an activator to a not gate, when it is off the lamp should turn on (because the not gate turns it on) when it is on it should also be on (because it directly powers the lamp). The small contraption may seem insignificant (why would I need to constantly power something like that) but it was from a bigger glitch where I just simplified it down to what is happening.

So is there anyway to fix this. Starmade needs to fix the logic where it deactivates everything first then activates everything.

EDIT: On further look it turns out it doesn't have to be in one tick. If two activation modules are powering a lamp, when one turns off the lamp turns off. :/

EDIT 2: Read comment #6

 

[GnomeKing]

Maybe This:

in a 'digital system' a signal is only passed with the 'On' signal > 'Off' is not a signal. To make something power down a 'Not-On' (rather than an 'Off') signal needs to be passed.

In fact there is no 'On' signal emitted from the activator - just a binary state-change, only one of which passes a signal. Thus the light keeps changing state because it is receiving a 'Change State' signal every time an activator is turned on, and receives no concurrent 'Change State' signal from the other activator.

The light block is designed to light up only while it is receiving a change of state signal - connected to a single activator, this is only only sent when the activator is in the 'on' state. Thus the light simply turns off when that single signal stops (i.e. when the activator is in the 'off' state). Your setup has a cycle of 'Change State' signals alternating from each activator (there is no 'off' signal), thus the light keeps switching on. ...

(not a bug

 

[AndyP]

The system is completely event-driven.

So assuming the tree:

• Activator A -> NOT -> Activator B -> LAMP
• Activator A -> Activator B

Resulting logic actions:

Switching Activator A from Off to On

• Step 1:
  Activator A turns on
• Step 2 (Results from Activator A):
  NOT turns off
  Activator B turns on
• Step 3 (Result of NOT):
  Activator B turns off

Switching Activator A from On to Off

• Step 1:
  Activator A turns off
• Step 2 (Results from Activator A):
  NOT turns on
  Activator B turns off
• Step 3 (Result of NOT):
  Activator B turns on

So there are actual race conditions in this case.
Please note:
The logic gates AND, OR are meant to be used with multiple inputs they would if placed like Activator B fire a very short pulse (that can be read by flipflops or alike),

NOT, DELAY - act in the order they get their inputs, so usually straight forward, sending them multiple signals from different sources is usually harmless, but not recommended.

Activators, Buttons, Inner Ship Remotes and other player-triggered gates, are always synced immediately, and work strictly on the event order, they have no built in logic-functionality if the last arriving signal is a "true->false" they will be false.

So in your case, you would have to use an OR gate in place of activator B, this would keep the light on (it would physically turn off for a single logic cycle, but you will not notice..).

- Andy

 

[Vitulus]

thus the light keeps switching on. ...
(not a bug

But the light doesn't keep switching on.

The system is completely event-driven.

So assuming the tree:

• Activator A -> NOT -> Activator B -> LAMP
• Activator A -> Activator B

Resulting logic actions:

Switching Activator A from Off to On

• Step 1:
  Activator A turns on
• Step 2 (Results from Activator A):
  NOT turns off
  Activator B turns on
• Step 3 (Result of NOT):
  Activator B turns off

Switching Activator A from On to Off

• Step 1:
  Activator A turns off
• Step 2 (Results from Activator A):
  NOT turns on
  Activator B turns off
• Step 3 (Result of NOT):
  Activator B turns on

So there are actual race conditions in this case.
Please note:
The logic gates AND, OR are meant to be used with multiple inputs they would if placed like Activator B fire a very short pulse (that can be read by flipflops or alike),

NOT, DELAY - act in the order they get their inputs, so usually straight forward, sending them multiple signals from different sources is usually harmless, but not recommended.

Activators, Buttons, Inner Ship Remotes and other player-triggered gates, are always synced immediately, and work strictly on the event order, they have no built in logic-functionality if the last arriving signal is a "true->false" they will be false.

So in your case, you would have to use an OR gate in place of activator B, this would keep the light on (it would physically turn off for a single logic cycle, but you will not notice..).

- Andy

Well, the reason I brought this up was because I had a 7 segment display which has 10 activators for the numbers 0-9. There is a 4 bit table converter and when I switch been two values instantly the activators don't activate properly. There should be a rewrite for the system to avoid this because in real logic you have on and off. On overrides off. Same problem I had with Terraria.

"So in your case, you would have to use an OR gate in place of activator B, this would keep the light on (it would physically turn off for a single logic cycle, but you will not notice..)."
This doesn't solve the problem, the video above was to show what I meant, the actually problem is more complicated but the video shows the heart of it. I fixed the display for now by making it so when you change a bit it resets the display. Not the best way of doing it. OR gate won't work, I need something that won't screw up when you switch values at the same time. And can turn on both ways.

"NOT, DELAY - act in the order they get their inputs, so usually straight forward, sending them multiple signals from different sources is usually harmless, but not recommended."
If I was in that situation I would probably use a NAND or NOR gate

 

[Jaaskinal]

This is not a bug. This is intended behaviour. If you want this to work, use an or-gate.

 

[Vitulus]

This is not a bug. This is intended behaviour. If you want this to work, use an or-gate.

Ok so I took this into consideration.

So I used an OR (took me a long time to change all the displays). It worked well for a while but glitches started to happen again... I then wanted to find why this was happening so I did the same experiment as I did before but swapped out the OR gate. Like this:

Activator > OR gate > Lamp
Activator > NOT gate > OR gate > Lamp

(There is only 1 activator, 1 Not gate, 1 OR gate and a lamp)

But for some reason the Lamp is never powered . This shouldn't be so because at all times there is atleast one block powering the OR gate. OR gates are meant to handle multiple inputs so why doesn't this work. This is also happening on the same logic cycle. And to prove it is an issue with the same logic cycle I did another circuit.

Activator A > OR Gate > Lamp
Activator B > OR Gate > Lamp

(There is only one OR gate and Lamp but 2 activators)

This works perfectly fine. If I power any of the activators it works.

Unlike before this is probably a bug.

 

[AndyP]

It is partially a bug, but if you link the output of the OR to a flipflop you can see it does send short pulses.

So it is a race condition again causing it.
I see there is some odd behaviour, but that is a tribute to the very short pulses you create there. Will for sure check this problem in the near future, but never build a circuit like that (creating "off pulses" only) to control a light.

- Andy

 

[Vitulus]

Will for sure check this problem in the near future, but never build a circuit like that (creating "off pulses" only) to control a light.

- Andy

Yeah but unfortunately I am working with bytes and when they change (this happens instantly) this same effect happens leaving the OR gates in a bugged state. Right now my only fix is by connecting a button to all my OR gates and I can press it to update the OR gates and fix it

 

[GnomeKing]

phew - this logic is now way beyond me, good job others who know whats-whats have chimed in... > good luck with your project Vitulus !

 

[Groumpf]

It is partially a bug, but if you link the output of the OR to a flipflop you can see it does send short pulses.

So it is a race condition again causing it.
I see there is some odd behaviour, but that is a tribute to the very short pulses you create there. Will for sure check this problem in the near future, but never build a circuit like that (creating "off pulses" only) to control a light.

- Andy

Hi Andy, could this race condition be at the origin of the weird comportment of this circuit ? (it does the same thing without the AND, btw, I forgot to check) I can't use an OR gate as it's a matter of impulse, but to link each flipflop to a different button solves the problem.

Wireless stays activated while slaved to button

 

[Vitulus]

It is partially a bug, but if you link the output of the OR to a flipflop you can see it does send short pulses.

So it is a race condition again causing it.
I see there is some odd behaviour, but that is a tribute to the very short pulses you create there. Will for sure check this problem in the near future, but never build a circuit like that (creating "off pulses" only) to control a light.

- Andy

Wait so if it is race condition what happens if you have something that runs at the same like:
Activator A> Activator B> Lamp
Activator A> Not gate> Lamp

what happens then, after you power the activator?