Wireless transmission and Step-limit exploits

arakira · 2014-02-18 13:51:36

MMaster wrote:

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 :-)

The problem is, there would still be a magic number (this very number N), which is not natural at all.

I have a solution: if, at some turn, the electronics get un-resolved after 32 sub-steps (constantly changing, without any loop detection), then the system heats, the house burns, and game over

jere · 2014-02-18 13:58:24

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.

While this would mean a bit of waiting around, wouldn't it make things a lot more intuitive? The fact that we needed a mod to show substeps is worrying. Especially because it all is a little arbitrary and based on these magic numbers.

arakira · 2014-02-18 14:02:15

jasonrohrer wrote:

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.

I wouldn't consider sub-step 1 as a fall back state, but the start of loop detection. If a loop is detected or the step count is exceeded, then electronics would settle down to their lowest seen state (as it is implemented right now, if I'm not mistaken). The only difference is, sub-step 0 would never be "visited".

EDIT : I think this would be equivalent to your purge system, with a purge counter set to 1. In other words, why would we want to set it to 8 or 16, wouldn't simply 1 do the job?

Last edited by arakira (2014-02-18 14:23:25)

redxaxder · 2014-02-18 14:05:05

arakira wrote:

The problem is, there would still be a magic number (this very number N), which is not natural at all.

It's very natural! Gate delay is a real thing! (Although the real life version is less predictable.) There's a flash game that was designed to be a straightforward electronics simulator (KOHCTPYKTOP) that behaves exactly like TCD electronics until you add in the strange loop detection.

The only weirdness that would be left in a fixed-number-of-cycles model like this would be the ability of rapidly oscillating current to affect the robber just like solid current can. That could be fixed by making interactive components (doors, traps, grates) require a minimum amount of power each turn to be live for that turn. Or by making them require some number of consecutive ON cycles to be ON for the robber (whether or not they were ON for the purposes of other electronics).

Last edited by redxaxder (2014-02-18 14:07:01)

sebastian · 2014-02-18 14:06:30

Jason: No. I suppose that the things not receiving Power the second step, would simply be reset at calculation 0.
That would simply push the first caculation to substep 1.

So there would not be any weirdness unless you did Circuits with larger Clock steps than 32. If we do as you say, we simply "freeze" the Circuit after 32 steps instead of "settling" the Circuit.

This could also be fixed: Add code that simply checks, Before calculating Electronics for the first loop run, that checks if anything that did receive Power last turn, does no longer receive Power. Change state of this.

Then Circuits would behave exact same each turn.
Only way to change this would be with bit storage.

arakira · 2014-02-18 14:06:55

jere wrote:

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.
While this would mean a bit of waiting around, wouldn't it make things a lot more intuitive? The fact that we needed a mod to show substeps is worrying. Especially because it all is a little arbitrary and based on these magic numbers.

I also love the idea of one robber step (or tool use) = one electronic step. There would not be hidden substeps anymore. It would change a lot electronics design, but would simplify the whole thing, and probably would still allow complex and interesting use of electronics.

MMaster · 2014-02-18 14:17:27

arakira wrote:

jere wrote:
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.
While this would mean a bit of waiting around, wouldn't it make things a lot more intuitive? The fact that we needed a mod to show substeps is worrying. Especially because it all is a little arbitrary and based on these magic numbers.
I also love the idea of one robber step (or tool use) = one electronic step. There would not be hidden substeps anymore. It would change a lot electronics design, but would simplify the whole thing, and probably would still allow complex and interesting use of electronics.

In that case I was thinking about adding mid-state to the circuits - single pulse. So it would be either powered, unpowered or single pulse. I think it can be used to at least partially emulate paradox circuits even in world where 1 step = 1 substep.

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

Yeah, that is a solution!

"The electronics overheated and you died in the fire."

So... a home owner wouldn't do this on purpose, because they would lose everything if it was ever triggered (even if they skipped tripping it themselves, a robber could trip it and burn their house down). Any chance of someone doing it by accident, though?

Also, I think the whole "sub step" thing is at the heart of what makes electronics so hard to understand. Iceman's mod turns the system down to 1 sub step for a reason.

And Minecraft redstone is easier to understand because you can "see it happening" as various plungers move to and fro, step by step.

So... maybe a paradox circuit SHOULD blink on and off as a robber walks around.

Maybe each robber step should only have one power propagation step.

This seems like a huge change to the game. Then again, it would only affect people who are doing complex electronics. And some things would make a bit more sense (like entering a combination on some buttons but having to wait a step for the internal voltage-triggered switches to transition and finally open the door a step later).

Also... I really wish this came up before the game was released and reviewed...

jasonrohrer · 2014-02-18 14:22:09

Sorry... a bunch of people posted the exact same thought as I wrote that.

(Also... feeling somewhat sad saying goodbye to the deep esoteric mysteries of electronics in this game...)

MMaster · 2014-02-18 14:28:31

jasonrohrer wrote:

Yeah, that is a solution!
"The electronics overheated and you died in the fire."
So... a home owner wouldn't do this on purpose, because they would lose everything if it was ever triggered (even if they skipped tripping it themselves, a robber could trip it and burn their house down). Any chance of someone doing it by accident, though?

Accidents happen even in real world ;-) I think the chance is really small as nobody has come up with something like this until now. If it happens to anyone by accident - bad luck :-)

arakira · 2014-02-18 14:28:52

redxaxder wrote:

arakira wrote:
The problem is, there would still be a magic number (this very number N), which is not natural at all.
It's very natural! Gate delay is a real thing!

These are 2 different numbers. The gate delay is the time required for a circuit to settle down. It already has a meaning in TCD: the number of sub-steps required before the circuit settles down. This new magic number N is another input data, which would arbitrarily put a cap on how long we allow the circuit to fluctuate before freezing it.

MMaster · 2014-02-18 14:50:59

Another possible solution is to find out how many substeps are needed for the worst case scenario on the available house space and test if setting limit to that value is going to be problem for the performance.

arakira · 2014-02-18 14:56:53

MMaster wrote:

Another possible solution is to find out how many substeps are needed for the worst case scenario on the available house space and test if setting limit to that value is going to be problem for the performance.

This worst case is at least millions, maybe trillions (just put in oscillators with with various prime numbers periods)

colorfusion · 2014-02-18 15:00:47

arakira wrote:

MMaster wrote:
Another possible solution is to find out how many substeps are needed for the worst case scenario on the available house space and test if setting limit to that value is going to be problem for the performance.
This worst case is at least millions, maybe trillions (just put in oscillators with with various prime numbers periods)

This, and from this thread we can see that waiting for the server simulation will now start to get too laggy after about 160 substeps.

jasonrohrer · 2014-02-18 15:04:13

Yeah... it's possible to build a circuit (like a 16-bit counter or something) that takes tens of thousands of steps to finally loop. Yes, it's a problem for performance. Josh designed a house back in the day that took 96 minutes to compute a single step:

http://castledraft.com/editor/GtDVc0

As a robber, if you step on that switch, you're in for a 96 minute nap.

Clearly, a step limit was needed to prevent this. Even if we ignore the issue of clogging people's PCs, the server-side simulator needs to chug through all that as well.

But, if there was one electronics step per robber step, that house would be perfectly viable. However, you'd then be in a position where you might force a robber to walk back and forth for 65K steps before finally being able to walk through. Though something like that is already possible with the existing counters. I think this would make it easier though.

Okay... time to retire for the day and keep thinking about this. I look forward to some great thoughts here when I come back tomorrow!

MMaster · 2014-02-18 15:05:38

arakira wrote:

MMaster wrote:
Another possible solution is to find out how many substeps are needed for the worst case scenario on the available house space and test if setting limit to that value is going to be problem for the performance.
This worst case is at least millions, maybe trillions (just put in oscillators with with various prime numbers periods)

Oh right. Silly me :-) So I guess the only real solution is to have just single step. The electronics will change a lot with this e.g. clocks will be much easier to make. Alternating power will be question of just 1 paradox circuit. No more pulses through electric floors to protect your walls or trigger trap through seemingly unpowered button, etc etc it makes me sad.

EDIT: How about disabling the component that triggered the event where more than 32 substeps are needed? If that would happen at the beginning the house would be refused to be self-tested. If that would happen during robbery, you can cache electronics components that changed state during last turn and as soon as you find out that > 32 substeps are needed just reset those electronic components back to state where they were before and stuck them at that state and do the computations again.
This would stop clocks working after trying to trigger the breaker but there are much easier ways to do that. Maybe you would be able to make unpressable button, but the doors that are supposed to be closed would be closed unless connected to the circuit somehow.

Last edited by MMaster (2014-02-18 15:43:13)

iceman · 2014-02-18 16:58:10

I don't think "freezing" the state of electronics after n steps is a good solution. If you do that, a simple paradox circuit could function as a clock - one of the biggest drawbacks to using clocks is how much space they take up.

Similarly, 1 step = 1 clock step suffers from the same problem. In that case, the most basic paradox circuit IS a period 1 clock (this is something that takes up 5 squares, not the 20 or so the new compact, 1 period clocks take up. Also, it takes away lots of the interesting designs that actually have the potential to trick a robber. Robbers will KNOW that, if something isn't already cycling, nothing will change without a button being pressed (unlike now, when cutting that wire in front of you could kill you immediately). Another problem is caused by the delay in switches - without using clocks (which repeat), you could make buttons have ridiculously long delays before actually causing something to happen. I really don't like the idea of that.

Having NO memory between steps has been discussed before, and I like with the decision made then. Although it would get rid of a lot of funkiness, it also removes a really interesting part of the game. I think it's been shown already that clocks are actually pretty balanced right now, and they provide a nice variety of houses. Maybe you could have a tile, like a capacitor, that is the only item capable of "electric memory", but I'm not sure if they wouldn't put us right back where we are.

I think we should consider exactly what makes this development game breaking. It has NEVER been an issue before we decided to use the 32 step limit in order to transmit information wireless (and animal-lessly, Blip ). So, the biggest issue with the 32 step limit is that it affects everything globally. I think that the solution that was mentioned near the beginning, to check electronic loops locally, is the cleanest one. It takes away the main purpose to abuse the electronic system, and it fixes most of the "directly connected to power but unpowered" problem.

So, where would this leave us?

99.9% of houses would be *exactly the same*. The *only* way that you could abuse the 32 step limit would be to make something like this, where the pit is unpowered until you press the button (assuming the jumble of electronics is actually a > 32 period circuit). However, there isn't much advantage to doing that - you can actually open the pit by cutting the wall, it can be done MUCH more simply and effectively with normal electronics. All that's different is the presentation.

Also, Jason, do you have the ability to move all of these posts to a new thread? We haven't been talking about multiplexers in a while, so I think it'll be much better both ways if you split the electronics discussion into a separate thread.

Last edited by iceman (2014-02-18 16:59:07)

colorfusion · 2014-02-18 17:25:39

1 step -> 1 substep would also have a lot of visually inconsistencies, even on simple circuits, as voltage triggered switches wouldn't trigger for another step. Adds the potential also for huge delays and guessing games as said before.

Not sure if house-on-fire is a serious suggestion, but it could easily be abused by newbie houses to have random buttons, or even a clock, be an instant kill to robbers; seems a bit extreme.

What if the components turned to a broken/burnt-out state and permanently stopped conducting if they took over 32 turns to settle? It'd only need to be for voltage triggered switches.

iceman wrote:

Also, Jason, do you have the ability to move all of these posts to a new thread? We haven't been talking about multiplexers in a while, so I think it'll be much better both ways if you split the electronics discussion into a separate thread.

"Wirin' Thread 2: Electric Boogaloo"

Last edited by colorfusion (2014-02-18 17:36:44)

MMaster · 2014-02-18 17:33:56

iceman wrote:

I think that the solution that was mentioned near the beginning, to check electronic loops locally, is the cleanest one. It takes away the main purpose to abuse the electronic system, and it fixes most of the "directly connected to power but unpowered" problem.

What happens with circuit that hit 32 substeps? And what happens when that circuit is connected to otherwise disconnected section of house by pressing a button? Cannot it still be somehow abused?

Last edited by MMaster (2014-02-18 18:14:46)

redxaxder · 2014-02-18 17:45:58

arakira wrote:

redxaxder wrote:
arakira wrote:
The problem is, there would still be a magic number (this very number N), which is not natural at all.
It's very natural! Gate delay is a real thing!
These are 2 different numbers. The gate delay is the time required for a circuit to settle down. It already has a meaning in TCD: the number of sub-steps required before the circuit settles down. This new magic number N is another input data, which would arbitrarily put a cap on how long we allow the circuit to fluctuate before freezing it.

Sure. N is arbitrary, to an extent. It's a meaningful number, though, and eliminating substeps entirely is just another way of choosing an N. Here are some things to consider regarding the choice.

N=1:
Propagation delay is a full robber turn. Electronics move in slow motion; this means that all logic now has a noticeable warm up period before taking effect. Timing-based traps become super easy to construct. Hit this button and 4 turns later that trapdoor closes for exactly one turn and never opens again. Pretty much all existing circuits no longer work; to be replaced by the new paradigm. Circuits are now super easy to debug; just hook up indicator lights everywhere.

N is small (say.. 4 to 8):
Most circuits appear to update instantly. Realistic. Delay based traps are accessible, but have a noticeable space cost. Clocks that measure robber turns are accessible, but larger than in the current build. The behavior of most existing circuits is preserved; exceptions include: things that relied on the loop detection state collapse (pulse generator), and oscillators with a period relatively prime to N. If N is even, the "paradox circuit" cut detection trick works the same way it did before.

N is large (32 or so):
Most circuits appear to update instantly. Delay based traps are huge. Only a few people will bother with them. A clock that measures a robber turn takes up 4 rows of your house. The behavior of most existing circuits is preserved (with the same exceptions).

joshwithguitar · 2014-02-18 17:52:12

I think I agree with iceman here that single cycle steps would be too much of a change and quite possibly effect the game negatively. The ability to create tiny clocks with large cycle lengths would make the game a nightmare for new players and pretty much make stepping on electric floor without first cutting it far too dangerous. Timing puzzles would just become silly. Also, I think overall it would make the electronics more confusing for new players - they'd wonder why voltage inverted switches take a turn to kick in. Also, if you did this you would probably have to add sirens to self test if you want to preserve the idea that all houses are solvable - it would be quite easy to create a house that takes over 20 mins of button pressing to solve without tools (though this is probably already possible).

That's not to say it wouldn't be extremely interesting to play with, I'd welcome it from that side of things. I don't think we've exhausted the interesting possibilities with the current set-up though. I also like traps that kill you as soon as you cut something .

My suggested solution would be:
1. Increase the cycle limit to as high as is reasonable. Make sure the code for electronics is as optimised as possible.
2. Purge to the (max cycle number)/2.
3. Localise electronics so that
a) electronics topping out won't effect disconnected electronics.
b) If one part of the electronics is unresolved not all other parts of the house need to be checked, hopefully reducing lag.

I think these things combined would make utilising time-outs entirely impractical.

Blip · 2014-02-18 18:20:26

joshwithguitar wrote:

I don't think we've exhausted the interesting possibilities with the current set-up though. I also like traps that kill you as soon as you cut something .
My suggested solution would be:
1. Increase the cycle limit to as high as is reasonable. Make sure the code for electronics is as optimised as possible.
2. Purge to the (max cycle number)/2.
3. Localise electronics so that
a) electronics topping out won't effect disconnected electronics.
b) If one part of the electronics is unresolved not all other parts of the house need to be checked, hopefully reducing lag.
I think these things combined would make utilising time-outs entirely impractical.

Firstly, I love traps that kill you when you cut something, and would hate to see them go. It's the only real way to kill a brute-forcer.

This solution might work; the key, I think, is 3; it prevents crazy circuits from breaking the rest of the house, without arbitrarily destroying all electronic devices created up to this point (excluding wireless stuff and electro-breakers), along with a nice solution to reduce lag.

arakira · 2014-02-18 18:41:48

MMaster wrote:

iceman wrote:
I think that the solution that was mentioned near the beginning, to check electronic loops locally, is the cleanest one. It takes away the main purpose to abuse the electronic system, and it fixes most of the "directly connected to power but unpowered" problem.
What happens with circuit that hit 32 substeps?

There could still be electronic glitches at that point, but at least they would only happen locally, without magically affecting other parts of the house.

MMaster wrote:

And what happens when that circuit is connected to otherwise disconnected section of house by pressing a button? Cannot it still be somehow abused?

I guess if a button makes a link between two components A and B, A and B are connected (and thus behave as a single component) if and only if the button is pressed.

arakira · 2014-02-18 19:03:16

Blip wrote:

joshwithguitar wrote:
I don't think we've exhausted the interesting possibilities with the current set-up though. I also like traps that kill you as soon as you cut something .
My suggested solution would be:
1. Increase the cycle limit to as high as is reasonable. Make sure the code for electronics is as optimised as possible.
2. Purge to the (max cycle number)/2.
3. Localise electronics so that
a) electronics topping out won't effect disconnected electronics.
b) If one part of the electronics is unresolved not all other parts of the house need to be checked, hopefully reducing lag.
I think these things combined would make utilising time-outs entirely impractical.
Firstly, I love traps that kill you when you cut something, and would hate to see them go. It's the only real way to kill a brute-forcer.
This solution might work; the key, I think, is 3; it prevents crazy circuits from breaking the rest of the house, without arbitrarily destroying all electronic devices created up to this point (excluding wireless stuff and electro-breakers), along with a nice solution to reduce lag.

I do agree on all these points but one, what I don't understand is why we need some magic number for the purge. The only thing I see that needs to be purged is the sub-step 0, which shouldn't be considered. To me it looks like a useless "before electricity starts to flow" state.

Last edited by arakira (2014-02-18 19:07:17)

jere · 2014-02-18 19:45:43

I robbed an 11k house to make one of these exploit houses. I know it'll be patched soon, but I really want to see how confused someone gets.

By the way, people seem to be getting a lot better. I'm able to rob a lot fewer houses with starting tools than I used to.

The Castle Doctrine Forums

#51 2014-02-18 13:51:36

Re: Wireless transmission and Step-limit exploits

#52 2014-02-18 13:58:24

Re: Wireless transmission and Step-limit exploits

#53 2014-02-18 14:02:15

Re: Wireless transmission and Step-limit exploits

#54 2014-02-18 14:05:05

Re: Wireless transmission and Step-limit exploits

#55 2014-02-18 14:06:30

Re: Wireless transmission and Step-limit exploits

#56 2014-02-18 14:06:55

Re: Wireless transmission and Step-limit exploits

#57 2014-02-18 14:17:27

Re: Wireless transmission and Step-limit exploits

#58 2014-02-18 14:19:12

Re: Wireless transmission and Step-limit exploits

#59 2014-02-18 14:22:09

Re: Wireless transmission and Step-limit exploits

#60 2014-02-18 14:28:31

Re: Wireless transmission and Step-limit exploits

#61 2014-02-18 14:28:52

Re: Wireless transmission and Step-limit exploits

#62 2014-02-18 14:50:59

Re: Wireless transmission and Step-limit exploits

#63 2014-02-18 14:56:53

Re: Wireless transmission and Step-limit exploits

#64 2014-02-18 15:00:47

Re: Wireless transmission and Step-limit exploits

#65 2014-02-18 15:04:13

Re: Wireless transmission and Step-limit exploits

#66 2014-02-18 15:05:38

Re: Wireless transmission and Step-limit exploits

#67 2014-02-18 16:58:10

Re: Wireless transmission and Step-limit exploits

#68 2014-02-18 17:25:39

Re: Wireless transmission and Step-limit exploits

#69 2014-02-18 17:33:56

Re: Wireless transmission and Step-limit exploits

#70 2014-02-18 17:45:58

Re: Wireless transmission and Step-limit exploits

#71 2014-02-18 17:52:12

Re: Wireless transmission and Step-limit exploits

#72 2014-02-18 18:20:26

Re: Wireless transmission and Step-limit exploits

#73 2014-02-18 18:41:48

Re: Wireless transmission and Step-limit exploits

#74 2014-02-18 19:03:16

Re: Wireless transmission and Step-limit exploits

#75 2014-02-18 19:45:43

Re: Wireless transmission and Step-limit exploits

Board footer