Wireless transmission and Step-limit exploits

colorfusion · 2014-02-18 08:10:46

With the electronics breakers, it seems that they just prevent power from spreading: http://www.youtube.com/watch?v=aBUzXpPGnsg
(The toggle wire goes up to the device)

It doesn't immediately stop all power. It prevents new things from being powered while still allowing things to become unpowered and keeping previously powered things powered. You don't seem to be able to turn off something that is still receiving power, but you can keep something off if it wasn't powered in the previous step.

This new branch of TCD wiring abusing the substep limit is pretty amazing, even though it's somewhat gamebreaking.

Last edited by colorfusion (2014-02-18 09:21:41)

largestherb · 2014-02-18 09:07:29

this is absolutely an exploit

jasonrohrer · 2014-02-18 10:12:14

Amazing!

So, there are clearly some bugs at play here.

As I understand the "loop settling" algorithm, it should lower things to their lowest seen state during the loop. Things that were always powered on during the loop (like things with direct connections to power boxes) shouldn't be settled down to their "off" state like we're seeing here.

I've been able to reproduce the "prevents power from spreading" bug that Colorfusion demonstrates in that Youtube video, but I STILL have not been able to reproduce the "kill all power, even direct power" that Hippasus is showing.

Hippasus: please email me! jasonrohrer@fastmail.fm

Oh... wait, Hipp... I think it's just something that has to happen in the very first step, before the robber makes a move, right? Like, if the very first propagation (with no robber input) hits the 32-step limit, then all power is off in the house.

Found it:

.
if( transitionCount > transitionLimit ) {
            // hit transition limit without seeing a real loop
            
            // return to start state before running the loop again in this
            // case, because we're going to look for lowest-seen-states
            // within this transition limit instead of a full loop
            memcpy( inMapStates, startStates, numCells * sizeof( int ) );
            }

In general, this entire "wireless transmission" thing hinges on that line.

Hmm...

colorfusion · 2014-02-18 10:15:43

jasonrohrer wrote:

Amazing!
So, there are clearly some bugs at play here.
As I understand the "loop settling" algorithm, it should lower things to their lowest seen state during the loop. Things that were always powered on during the loop (like things with direct connections to power boxes) shouldn't be settled down to their "off" state like we're seeing here.
I've been able to reproduce the "prevents power from spreading" bug that Colorfusion demonstrates in that Youtube video, but I STILL have not been able to reproduce the "kill all power, even direct power" that Hippasus is showing.
Hippasus: please email me! jasonrohrer@fastmail.fm

Oh... wait, Hipp... I think it's just something that has to happen in the very first step, before the robber makes a move, right? Like, if the very first propagation (with no robber input) hits the 32-step limit, then all power is off in the house.
Found it:
.
if( transitionCount > transitionLimit ) {
            // hit transition limit without seeing a real loop
            
            // return to start state before running the loop again in this
            // case, because we're going to look for lowest-seen-states
            // within this transition limit instead of a full loop
            memcpy( inMapStates, startStates, numCells * sizeof( int ) );
            }
In general, this entire "wireless transmission" thing hinges on that line.
Hmm...

You're right about the direct power thing if Hipp is using the same thing I am, it can't cut off direct power; but it can stop direct power from turning things on if the electrobreaker is turned on at the start.

arakira · 2014-02-18 11:11:04

Really fun stuff, and great discovery! Too bad it is game breaking... As some people proposed already, I think dealing with each electronic connected component independently seems to be the way to fix it. Let's enjoy wireless transmission before v33 is released!

jasonrohrer · 2014-02-18 11:14:04

Here's a proposed fix:

Instead of starting the loop detection up right from the beginning, run several "purging" power transitions beforehand to get us away from the starting state and into the "middle" of any simpler loops.

Then, at that point, remember THIS as the start state, and run the normal loop detection (or step limit detection) as normal.

This prevents us from EVER returning to the true start state after loop detection (fixing the electrobreaker issue).

It also makes wireless transmission harder, because the receiver can no longer be a simple looper. It will need to "weather" the purging power transitions before it starts "on" looping (it would need to have at least one "off" step AFTER the purging power transitions are over).

Explained another way, whatever states are reached during the purging transitions would NOT be considered as possible "lowest seen states" when settling a looping or over-limit circuit.

colorfusion · 2014-02-18 11:21:54

So this would fix directly powered things not getting power from the start, but keep the ability to stop power spreading after that?

redxaxder · 2014-02-18 11:39:36

colorfusion wrote:

So this would fix directly powered things not getting power from the start, but keep the ability to stop power spreading after that?

It would not keep that ability. Because the initial power transfer would happen during the purge. You'd need a build a delay circuit that outlasts the purge to have any wireless interaction (which will be attainable once we know the number of purge transitions).

jasonrohrer · 2014-02-18 11:49:21

Redxaxder:

How does 32 sound?

:-)

Also, I'm glad that we're now using the phrase "the purge" in this conversation. I just saw that movie last night.

colorfusion · 2014-02-18 11:58:28

redxaxder wrote:

colorfusion wrote:
So this would fix directly powered things not getting power from the start, but keep the ability to stop power spreading after that?
It would not keep that ability. Because the initial power transfer would happen during the purge. You'd need a build a delay circuit that outlasts the purge to have any wireless interaction (which will be attainable once we know the number of purge transitions).

That's what I meant, I think. You'd still be able to just use a toggle switch after the purge or stop power spreading though?

Also clocks should still work as normal and not get a whole bunch of pulses during the purge, unless I'm misunderstanding this, because the pulsers I've seen rely on being settled into their lowest state at the end of the full step in order to give out their next pulse.

Last edited by colorfusion (2014-02-18 12:08:01)

redxaxder · 2014-02-18 12:10:54

jasonrohrer wrote:

Redxaxder:
How does 32 sound?

32 sounds like it will make the receiver very fat. I'm not sure exactly how big I'd need to make something to make it wait out 32 cycles. Probably too big to be practical.

Also, while I have your attention... What's the deal with the single orientation map tiles? (voltage triggered switch, voltage triggered inverted switch) They make all the electronics huge. Was that the idea?

Last edited by redxaxder (2014-02-18 12:15:15)

Blip · 2014-02-18 12:12:52

arakira wrote:

Really fun stuff, and great discovery! Too bad it is game breaking... As some people proposed already, I think dealing with each electronic connected component independently seems to be the way to fix it. Let's enjoy wireless transmission before v33 is released!

I think that would be the best solution, because any other way, people would find workarounds. Also, I think game-breaking is too strong of a term. You can't have any normally functional pieces of simple electronics in your house, even a doggy commit gate, let alone other complex things like clocks. It seems like there might be a way to use this system as a clock somehow and have a resolved, lack-of-power state re-loop around and then cut a looping circuit, allowing that to go back on again. But anyways, how is this wireless transmission any better than just this? It's just as wireless, and uses less space to boot! Plus no weird side effects.

colorfusion · 2014-02-18 12:18:39

Blip wrote:

arakira wrote:
Really fun stuff, and great discovery! Too bad it is game breaking... As some people proposed already, I think dealing with each electronic connected component independently seems to be the way to fix it. Let's enjoy wireless transmission before v33 is released!
I think that would be the best solution, because any other way, people would find workarounds. Also, I think game-breaking is too strong of a term. You can't have any normally functional pieces of simple electronics in your house, even a doggy commit gate, let alone other complex things like clocks. It seems like there might be a way to use this system as a clock somehow and have a resolved, lack-of-power state re-loop around and then cut a looping circuit, allowing that to go back on again. But anyways, how is this wireless transmission any better than just this? It's just as wireless, and uses less space to boot! Plus no weird side effects.

I think the worst use of the current system is something like this:
http://castledraft.com/editor/BNZi7r

Then using the space above for an electrobreaker and a clock/magic dance. That way you've got a house with pretty much no weak spots. This should be fixed with the purging though.

Last edited by colorfusion (2014-02-18 12:20:38)

redxaxder · 2014-02-18 12:24:41

colorfusion wrote:

orst use of the current system is something like this:
http://castledraft.com/editor/BNZi7r
Then using the space above for an electrobreaker and a clock/magic dance. That way you've got a house with pretty much no weak spots. This should be fixed with the purging though.

Yes! I want to build it before the bug expires!

*edit: Ok. I have a draft. It's really expensive due to all the pits. I'm going to see how much of it I can build before the patch.

Last edited by redxaxder (2014-02-18 12:37:06)

jasonrohrer · 2014-02-18 12:46:24

The purge would happen at the beginning of each robber step.

It would "run" the electronics for several propagation steps and transitions to get them to "shake out" a bit.

So, anything directly connected to power would become powered on.

Then, it would treat this "post-shake-out" state as the starting state, and run standard loop detection (or step limit detection) from there.

Remember, at the end of this process, if the electronics are "looping", then they are settled into the lowest state number that they each achieved during the loop. If a light was on for the whole loop, it will settle into its "on" state.

The "electrobreaker" stuff depends on the fact that after a switch is hit to turn a light on, the "start" state for that light is actually off, so it's lowest seen state is "off". (The light had no power last robber step, so at the start of this robber step, with the switch on now, the light starts off until the power flowing through the switch turns it on.)

During normal looping, the loop happens after the starting state. But during loops that exceed the step count, no true loop has been found (instead, we have electronics that are changing states without ever repeating a global state). In that case, the current code considers all states, including the starting state, when trying to "settle" the looping components.

Thus, if the starting state had a light off, it will settle to off in that case.

But if we let electronics "shake out" first before even picking the state we consider the "start," we won't have this problem.

Currently, if electronics surpass 32 steps, we consider steps 0, 1, 2, ..., 31, 32 when looking for the lowest seen state for a component.

With this proposed change, we'd run something like 8 + 32 steps, and then consider steps 8, 9, 10, 11, ..., 39, 40 when looking for lowest-seen states (ignoring whatever states were seen in steps [0..7]) when settling components.

The electrobreaker examples have components that are on by step 1 and stay on after that.

This would change nothing for components that are actually looping in fewer than 32 steps (clocks and stuff).

This would change the behavior of global circuits that take more than 32 steps without settling or looping.

STILL.... hmmm....

There's something very unsatisfying about any of this stuff. The step limit really is the point where the game "breaks" and everything stops making any kind of sense.

The behavior of paradox circuits, on the other hand, have a kind of logic to them. But the step limit is like a magic number.

It would be ideal to forbid houses that hit the step limit, but there's no way to actually do this (even if we check for it in self test, the owner could just avoid turning that part of the circuit on during the test, but design a house where the robber would likely stumble their way into the broken behavior).

Even isolating "separate" circuits, which would prevent wireless transmission, would not fix other esoteric uses of the step limit in connected circuits.

It seems like the settling behavior should be almost identical for "true loops" and "step limit" circuits. Picking the lowest seen state seems rather brittle, because a single visit to one low state out of 32 high states can "override" all the high states.

What about majority vote? Each component settles to whatever state it was in MOST during the loop. So if a light was on for two steps and off for one step in a 3-step loop, it would settle to being on.

Argg... but I think this would still allow wireless transmission... a receiver could stay off for 17 steps and then settle into "on" after that. The transmitter could take more than 32 steps to resolve after being turned on, in which case the receiver would be off 17 steps and on 15 steps, making it suddenly settle to "off"

Maybe "recentness" of the states needs to be accounted for? Here we have a receiver in the "on" state for the last 15 steps, but we're ignoring that when we settle it.

colorfusion · 2014-02-18 13:11:07

Ah, I was getting confused thinking you meant that the purging was only going to happen when the house first loads, which would just fix initial direct power.

Last edited by colorfusion (2014-02-18 13:11:30)

redxaxder · 2014-02-18 13:12:35

There's something very unsatisfying about any of this stuff. The step limit really is the point where the game "breaks" and everything stops making any kind of sense.

The electronics model within each turn makes perfect sense. It gets weird when you try to run the electronics "forever" before advancing the turn. As a way to not have any delay for switch (de)activation?

But the switches do have a delay. Just like real switches. And that lets us build real circuits out of them, which is pretty awesome. But waiting for a loop at all is an unnatural mechanic that makes the behavior diverge from real circuits.

If there was no loop detection and everything was simulated for N steps per turn (and took on the final state), then all the electronics would make perfect sense and wireless magic would be impossible.

Last edited by redxaxder (2014-02-18 13:25:32)

arakira · 2014-02-18 13:19:07

jasonrohrer wrote:

But the step limit is like a magic number.

The problem with such magic numbers are that they don't look natural in-game, and they are arbitrary. So with this purge system, if we want to understand electronics, we will now have to deal with the 32 step limit counter, PLUS an 8 (or whatever) "purge limit counter", and understand the purge. To me that doesn't look like solving the problem, but increasing the overall complexity of the rules... If it goes on, soon we will have to read the source code to understand how electronics works
Wouldn't it be simple to use the first electronic step (instead of the zero-nd one) as a reference for looping states? Things that are directly plugged to a power source would be powered in any case.
EDIT: By the way, in real life this 0-nd step should never occur, whether someone is in the house or not...

Last edited by arakira (2014-02-18 13:24:41)

Archonn · 2014-02-18 13:20:16

Whatever change Jason does, im sure one of you will find a way to break it.

Electricity...which TRAVELS THROUGH TIME

MMaster · 2014-02-18 13:25:28

redxaxder wrote:

If there was no loop detection and everything was simulated for N steps per turn (and took on the final state), then all the electronics would make perfect sense and wireless magic would be impossible.

I just had exactly the same idea. If 1 step would be e.g. 8 substeps and the substeps state would be carried to the next step it would be perfect, but I'm not sure what kind of contraptions would appear after that :-)

Blip · 2014-02-18 13:26:53

redxaxder wrote:

There's something very unsatisfying about any of this stuff. The step limit really is the point where the game "breaks" and everything stops making any kind of sense.
The electronics model within each turn makes perfect sense. It gets weird up when you try to run the electronics "forever" before advancing the turn. As a way to not have any delay for switch (de)activation?
But the switches do have a delay. Just like real switches. And that lets us build real circuits out of them, which is pretty awesome. But waiting for a loop at all is an unnatural mechanic that makes the behavior diverge from real circuits.
If there was no loop detection and everything was simulated for N steps per turn (and took on the final state), then all the electronics would make perfect sense and wireless magic would be impossible.

That seems like a simple fix, as well. It would really just keep everything logical while also allowing for realistic circuit behavior. Personally, I find this wireless stuff hard to wrap my head around because it has no real world analog; in reality, you can't reach a "maximum amount" of steps and break all electronics in the universe simply with a big loop.

colorfusion wrote:

I think the worst use of the current system is something like this:
http://castledraft.com/editor/BNZi7r
Then using the space above for an electrobreaker and a clock/magic dance. That way you've got a house with pretty much no weak spots. This should be fixed with the purging though.

Wouldn't the electro-breaker break the clock itself? Unless you tried using the off-state from the breaker itself to force the clock to step, which may or may not be possible (not sure exactly what the crazy properties are yet), you would just end up with the clock unable to step after the breaker goes off.

MMaster · 2014-02-18 13:38:18

Blip wrote:

Wouldn't the electro-breaker break the clock itself? Unless you tried using the off-state from the breaker itself to force the clock to step, which may or may not be possible (not sure exactly what the crazy properties are yet), you would just end up with the clock unable to step after the breaker goes off.

I thought about clock that would trigger the breaker after certain time when I read it.

colorfusion · 2014-02-18 13:40:15

Blip wrote:

Wouldn't the electro-breaker break the clock itself? Unless you tried using the off-state from the breaker itself to force the clock to step, which may or may not be possible (not sure exactly what the crazy properties are yet), you would just end up with the clock unable to step after the breaker goes off.

Hmm, I guess you probably couldn't have a clock going while the electrobreaker is on, and once it's off once all of the trapdoors would permanently be receiving power. Some form of magic dance should still work, although it might make it weaker.

MMaster wrote:

Blip wrote:
Wouldn't the electro-breaker break the clock itself? Unless you tried using the off-state from the breaker itself to force the clock to step, which may or may not be possible (not sure exactly what the crazy properties are yet), you would just end up with the clock unable to step after the breaker goes off.
I thought about clock that would trigger the breaker after certain time when I read it.

I thought that initially, but the electrobreaker can't get rid of power to the trapdoors, so you have to have it on from the start.

Last edited by colorfusion (2014-02-18 13:44:05)

sebastian · 2014-02-18 13:48:41

I have a idea:
Remove all settling code and all such things, and just break calculation after 32 steps, and leave Everything in the states they become in the 32th step.

For this to work, a property needs to be added, like "oscillatorComponent", to the NC and NO relay.

What oscillatorComponent means, is that this is a Component that will cause Electronics to loop, and will advance loop calculation with 1 step.

Since any other Component NEVER can be put in a way that would cause Electronics to "loop", only Component that can be used for this is NC and NO relay, we could put a property that would tell the Engine that this is a item that would cause Electronics to be recalculated.

And change calcuation to be done in this way:
First, all Components that was powered in the previous turn (NOT STEP). Remember these Components.
Calculate Electronics given from the Power source, "follow" the Cables until it reach a Component. If its a conducting Component, continue following.
Mark all Component that would change state due to receiving/not receiving electricity. (Of cource not a visible mark, rather a "true/false" mark in the code, telling that this Component is going to change)
Check if any of the remembered Components does no longer receive Power. Mark them.

IF any Component that has the property "oscillatorComponent" is marked for state change then:

loop:
If STEP counter is less than 32:
Increate STEP counter.
Delete all marks on all Components, except for oscillatorComponent's.
Change state of all oscillatorComponents.
Delete all marks now.
Calculate Electronics given from the Power source, "follow" the Cables until it reach a Component. If its a conducting Component, continue following.
Mark all Component that would change state due to receiving/not receiving electricity. (Of cource not a visible mark, rather a "true/false" mark in the code, telling that this Component is going to change)
Check if any of the remembered Components does no longer receive Power. Mark them.

IF any Component that has the property "oscillatorComponent" would change state then GOTO "loop".

If STEP counter is 32 or more, just exit this loop and leave Electronics in the way it is.
Proceed with calculation of Death of player and mobiles.

This means that if you do a paradox Circuit that gives 1/0/1/0 pulses, then it will be this:
1010101010101010101010101010101 = will stay in a on state when the Circuit "settles"
If you do a 1/0/0 pulser, then:
1001001001001001001001001001001 = will stay in a on state when the Circuit "settles".
If you do a 1/0/0/0/0 pulser:
1000010000100001000010000100001 = will stay in a on state when the Circuit "settles".
If you do a 1/0/0/0/0/0/0 pulser:
1000000100000010000001000000100 = will stay in a off state when the Circuit "settles".

It would be pretty hard to do a pulser that settles in the way you want even with a system that simply leaves the Circuit in the state it found when it reach 32 steps.

Eg once it trips the limit, just exit the Electronics calculation and leave Everything as it became the 32th step.

That would solve all problems with wireless and such.

jasonrohrer · 2014-02-18 13:49:52

So... if there were a fixed number of "electronics sub-steps" per step (like 8 or whatever) and NO loop detection at all... just propagate power and trigger transitions for 8 sub-steps and then "freeze" everything where it is at that point, paradox or not...

That would allow more complex electronics stuff to happen ACROSS robber steps. Like, right off the bat, there would be things that flip and flop between steps.

In fact, pushing this idea to 11 would mean just doing 1 electronics step per robber step. Then even the simplest paradox circuit would flip back and forth as the robber walked around.

And even with a fixed number of sub-steps like 8 or whatever, any paradox that loops for a number of steps that is not a divisor of 8 would flip-flop across robber steps, but anything that loops for a number of steps that is a divisor of 8 would appear to be stable. This would be weird.

I dunno... that would be a heck of a lot of blinking going on!

The option of holding sub-state-1 as the "fall back" state if anything loops or exceeds the step count would fix the electrobreaker thing BUT also totally break clocks and other more complicated electronics that depend on later looping.

Anyway, this thread is AMAZING and I sense that we're making progress here toward a solution.

The Castle Doctrine Forums

#26 2014-02-18 08:10:46

Re: Wireless transmission and Step-limit exploits

#27 2014-02-18 09:07:29

Re: Wireless transmission and Step-limit exploits

#28 2014-02-18 10:12:14

Re: Wireless transmission and Step-limit exploits

#29 2014-02-18 10:15:43

Re: Wireless transmission and Step-limit exploits

#30 2014-02-18 11:11:04

Re: Wireless transmission and Step-limit exploits

#31 2014-02-18 11:14:04

Re: Wireless transmission and Step-limit exploits

#32 2014-02-18 11:21:54

Re: Wireless transmission and Step-limit exploits

#33 2014-02-18 11:39:36

Re: Wireless transmission and Step-limit exploits

#34 2014-02-18 11:49:21

Re: Wireless transmission and Step-limit exploits

#35 2014-02-18 11:58:28

Re: Wireless transmission and Step-limit exploits

#36 2014-02-18 12:10:54

Re: Wireless transmission and Step-limit exploits

#37 2014-02-18 12:12:52

Re: Wireless transmission and Step-limit exploits

#38 2014-02-18 12:18:39

Re: Wireless transmission and Step-limit exploits

#39 2014-02-18 12:24:41

Re: Wireless transmission and Step-limit exploits

#40 2014-02-18 12:46:24

Re: Wireless transmission and Step-limit exploits

#41 2014-02-18 13:11:07

Re: Wireless transmission and Step-limit exploits

#42 2014-02-18 13:12:35

Re: Wireless transmission and Step-limit exploits

#43 2014-02-18 13:19:07

Re: Wireless transmission and Step-limit exploits

#44 2014-02-18 13:20:16

Re: Wireless transmission and Step-limit exploits

#45 2014-02-18 13:25:28

Re: Wireless transmission and Step-limit exploits

#46 2014-02-18 13:26:53

Re: Wireless transmission and Step-limit exploits

#47 2014-02-18 13:38:18

Re: Wireless transmission and Step-limit exploits

#48 2014-02-18 13:40:15

Re: Wireless transmission and Step-limit exploits

#49 2014-02-18 13:48:41

Re: Wireless transmission and Step-limit exploits

#50 2014-02-18 13:49:52

Re: Wireless transmission and Step-limit exploits

Board footer