Wireless transmission and Step-limit exploits

redxaxder · 2014-02-19 11:27:32

LiteS wrote:

I really only have two questions about a fix.
Will it break this trap, in which if the robber cuts the wall, it will activate the floor?
Will it break the current implementation of clocks?

Purging: No and No

Fixed number of steps per turn (N > 1, N even): No and Yes (but other clock implementations will be possible if N is small enough)

1 step per turn: Yes and Yes (but other clock implementations will be possible)

jasonrohrer · 2014-02-19 12:30:21

Yes! Great stuff here.

I split the thread as requested.

Thinking about one electronics propagation per robber step last night, I couldn't come up with a way to make it visually consistent. Assuming that "electricity flows instantly" but it's just the "springs" in the voltage-triggered switches that take time to move, it just becomes weird to make the whole thing turn-based. You're either staring at a switch that looks like it should pass power, but is not actually passing power (because it's "about" to spring open when you take a step) OR you're staring at a switch that looks like it should be blocking power, but things beyond it are still powered OR you're staring at a switch that looks like it should be sprung (because its spring is clearly powered) but it isn't sprung.

The last option is the best one, but it's somewhat incompatible with the way an electronics step is currently resolved (propagate power from power sources, then trigger any power or no-power based transitions---this could result in a light turning on AND the switch feeding that light springing open).

This issue exists for any fixed number of sub-steps where we freeze the state at the end of those steps.

And, any fixed number of substeps will provide us with easy flip-flops (on-off clocks) because you just need to make a circuit with a loop count that isn't a divisor of the fixed number of substeps. It will flip on and off each step. We can thwart that with a fixed number of substeps that is the multiple of a bunch of divisors (like 6*7*8*9), but that number gets huge quickly.

As an example, if you're doing 8 substeps and then freezing the state, a circuit that loops every 3 substeps will turn on and off as the robber moves.

This is VERY different from real clocks, because real clocks don't depend on some arbitrary number (like 8 or 32) to work. They work the same way regardless of the cut-off.

Obviously, some number of purge steps is necessary to at least prevent the power-flow blocking bug that Jere is using there. That will be a first step to "buy time" while we continue to ponder the bigger picture here.

This will only affect houses that currently reach the 32-substep limit, so a full world reset won't be necessary. Yes, a few houses' self tests will be made invalid by the change, but that's no big deal. Some v32 robbery tapes will be weird when watched in v33, but again, only if your house currently is hitting the 32-substep limit.

jere · 2014-02-19 12:55:14

Yes, a few houses' self tests will be made invalid by the change, but that's no big deal.

Hmmmmmmmmmm. Any idea when 33 is going to drop then?

jasonrohrer · 2014-02-19 14:26:40

Coding it up now... eta tomorrow.

So.. looking at the code, I had a realization here, but I need more heads to check it.

The way the current system works, if electronics loop globally (return to some state that we've already seen) before 32 substeps, then we march through that loop again, look for the lowest-seen-state of each component during the loop (from this state until we return back to this state), and then set each component to its lowest-seen-state. In this case, we never return directly-powered things to an unpowered state, because thought they were unpowered at the start (before power reached them), by the time the loop is underway, they are powered, and only the in-loop states are considered when settling components. In other words, yes this light was off at some point, but it was on 100% of the time through the global loop, so we leave it on.

If electronics go 33 steps without settling themselves OR ever repeating a global state, then we stop the simulation. At that point, we roll back to the starting state, run 32 more steps from there, and look for the lowest-seen-state for each component. Since we don't have a real loop to work with (because we hit the limit before we saw a loop), we consider all 32 steps along the way as "the loop," and look for lowest-seen-states from that entire span of steps.

Of course, this leads to weird electro-breaker behavior, along with wireless communication. The problem is that we treat looping circuits differently than overrun circuits when we go to settle them. For the looping circuits, we effectively only consider "recent" step history (from the loop itself, and nothing before that). For overrun circuits, we consider the entire step history.

Removing "step 0" from consideration for overrun circuits prevents electrobreaker behavior, but it doesn't really address the fundamental problem of differential treatment of these two cases. What we really want to do is treat the overruns exactly like we treat loops.

But, for the overruns, we have no "full loop" of states to look at. So, we need to pick an arbitrary one. The current arbitrary pick is "the 32 global states that occur from the start state forward". But any other arbitrary pick is just as good.

What about "the next 32 states from where we cut off, forward"?

In other words, don't roll back to the start state. Just roll forward from where we stopped. This is what we actually do for loops (because we know we'll return to this point again if we roll forward from here, because a loop guarantees that). For overruns, we have no guarantee, but we might as well just run for another 32 steps and see what happens.

This certainly fixes the electrobreaker bug.

But I think it also deals with the wireless issue.

That issue depends on receiver circuits that effectively "settle" into an ON state before the 32 steps are up. By definition, these are ON ON ON ON for steps 33 to 64, which means that their lowest-seen-state will be ON if the global state suddenly switches to overrun mode.

Imagine a huge, hairy receiver that takes 31 steps to settle to ON. Now switch on a global overrun circuit. The receiver stays ON, because only steps 33 - 64 are considered when settling it.

Imagine a receiver that takes 34 steps to settle to ON. Then it overruns by itself, and has one OFF state during steps 33 - 64, so it settles to OFF. Another global overrun circuit switching on won't change that.

I'm pretty sure this would work.

One strange side-effect of this is that overrun circuits would settle differently than they currently do. They would ignore their starting state and first 32 substeps when settling, which might mean they would settle into a kind of "half way on" state. Like if this is an 8-bit counter that takes 256 steps to loop, steps 33-64 might involve some bits being stuck on the whole time, which means that they would settle to ON, which would look weirder than them settling to their start state.

colorfusion · 2014-02-19 14:38:51

jasonrohrer wrote:

<Snip>

This seems like a pretty good solution. I like how wireless transmissions are solved by the fact having a receiver would constantly act as an electro-breaker. It's also pretty easy to explain that, whether it loops in 32 turns or not, the lowest state is picked from the next 32 turns.

Last edited by colorfusion (2014-02-19 14:39:08)

jasonrohrer · 2014-02-19 14:54:41

Yes, you could explain it that way. I mean, if it's looping before we hit 32 substeps, it would indeed be still looping through those same states during substeps 33-64 if we did happen to simulate it that far. Same if it self-settles before we hit 32 substeps (it would still be settled in substeps 33-64).

Of course, we catch shorter loops and settled circuits earlier than that for efficiency (no need to run the full 64 substeps, if we have full knowledge about the circuit's possibilities after 4 substeps).

But, essentially, it's like treating all circuits equally in the way that they are settled. We run 'em all for 64 substeps and settle them to their lowest-seen states in the last 32 substeps of those 64 substeps.

The wireless transmission thing was exploiting the fact that some circuits are settled differently than others in v32.

MMaster · 2014-02-19 15:16:51

I think its perfect. Basically nothing will change for most of the people and weird stuff will be gone :-) (at least for now ;-) )

Last edited by MMaster (2014-02-19 15:17:15)

cbenny · 2014-02-19 15:30:29

Wow, I skip visiting the forum for a couple days and suddenly the laws of physics have changed.

jere · 2014-02-19 15:44:18

Wow, I skip visiting the forum for a couple days and suddenly the laws of physics have changed.

Yea it's quite strange how quickly this thing exploded.

Just realized a happy coincidence.

V33 Going beyond 32.... substeps

Blip · 2014-02-19 15:45:47

That seems to make sense and keep stuff consistent, which is key. With loops and overrun circuits settled the same way, not exploit can really take advantage of a difference there, and it also just makes it more understandable. To put it simply, if a circuit takes more than 32 sub-steps to loop, it is treated as if it loops at 32 steps. That makes much more sense than before!

cbenny · 2014-02-19 16:26:27

I'd like to dive in, learn how this works and find a way to exploit it, but something tells me its not going to last long enough for me to take advantage.

jere · 2014-02-19 16:32:13

Nah, just build this. http://castledraft.com/editor/xFNr6s

If you get it working, basically any other circuits stop functioning. You have about a day or so. If nothing else, it's fun to see the unexpected behavior.

Lord0fHam · 2014-02-19 16:51:56

With this wireless stuff, couldn't you build an almost impenatrable combo lock? or can you only have one transmission and not a lot? Also, is this stuff going to be patched?

redxaxder · 2014-02-19 17:27:24

Lord0fHam wrote:

With this wireless stuff, couldn't you build an almost impenatrable combo lock? or can you only have one transmission and not a lot? Also, is this stuff going to be patched?

Yes. Yes. Yes.

http://castledraft.com/editor/cK8JaI

iceman · 2014-02-19 17:35:05

Wow... that reminds me of a v9 map I saw when poking around the old news threads:
http://castlefortify.com/c/1a565ad

colorfusion · 2014-02-19 17:40:41

iceman wrote:

Wow... that reminds me of a v9 map I saw when poking around the old news threads:
http://castlefortify.com/c/1a565ad

I used to have a house similar to that, and Jason brute forced through it (end of post). They were pretty common and annoying houses.

This was when all of the V6-8 houses with heaps of money could suddenly be beaten with 9 tools as they'd been built to withstand just 8. It caused giant bubbles of money to pass around, people quickly built giant concrete defences and magic dances now that blueprints had gone, but there were enough tools to brute force through anything.

Then Jason went on holiday, and the economy collapsed from cheap tools, infinite backpacks and no chills; you could keep coming back to a house with a suicide life and do things like this.

Last edited by colorfusion (2014-02-19 17:56:29)

jere · 2014-02-19 17:44:30

^^Yea in retrospect, the early versions were so broken. You're looking at a magic dance 29 tiles away PLUS the trapdoor hallway has zero weaknesses.

Last edited by jere (2014-02-19 17:44:54)

joshwithguitar · 2014-02-19 17:56:23

Nice solution Jason! And I was all set to create the ultimate wireless network house that could put up with a large purge value...

I certainly can't think of anything useful/interesting or exploitative you could do with the top out limit once you've implemented the above changes.

Hippasus · 2014-02-19 18:12:21

I think that will do it nicely Jason. It is an elegant and effective solution.

And everything returned to normal in the neighbourhood, until...

iceman · 2014-02-19 18:21:56

Time to build a house with wireless communication, then go on a robbing spree when v33 comes out. Nobody will be able to rob me, and I'll be rich! Rich, I tell you!

Seriously, though, like jwg and hippo said (I'm starting to think they're the same person, not brothers...) that definitely seems like the cleanest solution. As much as I want wireless communication to stay, it's better for it to be gone. On the plus side, this whole episode of The Castle Doctrine has taught me more about sub-step electronics, and I was able to shrink the "control room" for my next house by about 1/3

MMaster · 2014-02-20 13:35:15

Great! V33 is coming right now

Leveller · 2014-02-20 13:36:27

Yeah had that message too.

jasonrohrer · 2014-02-20 14:40:52

Okay! It's live.

MMaster · 2014-02-20 15:11:40

jasonrohrer wrote:

Okay! It's live.

Thank you!

SmokestormX · 2014-02-20 15:40:15

Bah wireless transmission is all over

You didn't even give us enough time to wrap our heads around it.

Though my experiments still work in v33

Last edited by SmokestormX (2014-02-20 15:40:37)

The Castle Doctrine Forums

#101 2014-02-19 11:27:32

Re: Wireless transmission and Step-limit exploits

#102 2014-02-19 12:30:21

Re: Wireless transmission and Step-limit exploits

#103 2014-02-19 12:55:14

Re: Wireless transmission and Step-limit exploits

#104 2014-02-19 14:26:40

Re: Wireless transmission and Step-limit exploits

#105 2014-02-19 14:38:51

Re: Wireless transmission and Step-limit exploits

#106 2014-02-19 14:54:41

Re: Wireless transmission and Step-limit exploits

#107 2014-02-19 15:16:51

Re: Wireless transmission and Step-limit exploits

#108 2014-02-19 15:30:29

Re: Wireless transmission and Step-limit exploits

#109 2014-02-19 15:44:18

Re: Wireless transmission and Step-limit exploits

#110 2014-02-19 15:45:47

Re: Wireless transmission and Step-limit exploits

#111 2014-02-19 16:26:27

Re: Wireless transmission and Step-limit exploits

#112 2014-02-19 16:32:13

Re: Wireless transmission and Step-limit exploits

#113 2014-02-19 16:51:56

Re: Wireless transmission and Step-limit exploits

#114 2014-02-19 17:27:24

Re: Wireless transmission and Step-limit exploits

#115 2014-02-19 17:35:05

Re: Wireless transmission and Step-limit exploits

#116 2014-02-19 17:40:41

Re: Wireless transmission and Step-limit exploits

#117 2014-02-19 17:44:30

Re: Wireless transmission and Step-limit exploits

#118 2014-02-19 17:56:23

Re: Wireless transmission and Step-limit exploits

#119 2014-02-19 18:12:21

Re: Wireless transmission and Step-limit exploits

#120 2014-02-19 18:21:56

Re: Wireless transmission and Step-limit exploits

#121 2014-02-20 13:35:15

Re: Wireless transmission and Step-limit exploits

#122 2014-02-20 13:36:27

Re: Wireless transmission and Step-limit exploits

#123 2014-02-20 14:40:52

Re: Wireless transmission and Step-limit exploits

#124 2014-02-20 15:11:40

Re: Wireless transmission and Step-limit exploits

#125 2014-02-20 15:40:15

Re: Wireless transmission and Step-limit exploits

Board footer