[Not a bug] Counter bug?

[Chaos Awakes]

I have a puzzle in my dungeon where the floor is covered in pressure pads, each of which increments the same counter. When the counter reaches 22, IE, the player has walked 22 spaces, the counter activates a movable wall which was previously invisible. Result, the player walks 22 spaces and a wall appears.

However, the wall happens to be in the same room as the pressure pads, and one of the pressure pads is on the same square as the wall. If the player happens to be standing on the same square as the wall when the counter reaches 22, the wall doesn't appear. Obviously, I wouldn't expect it to appear when the user was standing on it, but if it has been toggled into it's "visible" state them it should appear as soon as the player steps off onto an adjacent square.

[Chaos Awakes]

I've just tried doing it with a teleporter instead. I changed the wall for a teleporter and a blue haze. Initially, they are both off. When the counter reaches 22 the teleporter and blue haze are activated. I figured that if the player was standing on the square at the time they would be teleported off.

This time, something even odder happens. The teleporter doesn't even stay there. The next time the player steps on a pressure pad, incrementing the counter to 23, the teleporter dissapears. Why? The logic is supposed to be "when the counter reaches 22, do something" isn't it - not "when it stops being 22, take it back!".

[George Gilbert]

Depending on exactly how you've set up your counter, I expect that this isn't a bug and is working precisely as it should. Instead, I suspect you're misunderstanding how counters work.

***********

How they actually work is that the COUNT=(xxx) value in the dungeon.txt file is the *STARTING* value. Each time you activate the counter it decrements in value / each time you deactivate it, it increments.

When a counter changes its value (as a result of an increment or decrement) if the new value is equal to 0 then the counter does what you told it to do. If the new value is not equal to 0 then it does the opposite.

***********

Therefore, what I think is happening in your dungeon is that for each of the 21 initial times you step on a trigger, the counter slowly makes its way down from 22 to 1; on each occasion the counter makes the wall invisible. When you land on the 22nd trigger, then the counter reaches zero and the wall becomes visible. So far, so good and all in line with your expectations.

The difference however is on your 23rd step. Now what happens is that the counter changes its value to -1. This is non-zero and so the counter makes the wall invisible again.

This is exactly what it is meant to do, but I suspect not what you were expecting it to do - is that right?

If you want the wall to be permanently there for every step after the 22nd then you need to make sure that the counter (as well as making the wall visible) also destroys itself. That way any further walking about won't lead to the wall changing state.

[Chaos Awakes]

Ok.

So are you saying that the following won't work, because I've got this all over my dungeon and I'm pretty sure it's working:

A door gets opened by putting 4 coins in a coin slot. Every time a coin is inserted, a counter is activated. When the counter reaches 4 (or 0 since they count down), the door opens - but a relay is also activated which decrements the counter back to zero so that the player can insert more coins next time he wants to open the door.
According to what you've just said, this should open the door and then close it again instantly when the relay decrements the counter, yes?

How would I solve that?

[Chaos Awakes]

Yep, I've just playtested my dungeon and the door/coins thing is working which seems to contradict what you just said, so I'm confused.

If the counter opens the door and then immediately fires a relay which sets the counter back to it's initial value, shouldn't the door close immediately?

[George Gilbert]

How are you re-setting the counter? I ask as I'm confused by the statements "decrements the counter back to zero" and "sets the counter back to it's initial value" (which are two completely different things, but I you're using them interchangably). If you're doing this by setting the counter to zero then I would expect nothing to happen (as the counter will already be at zero) which is what you're seeing happen.

Can you send me a tiny test dungeon with just the coin slot, relays, counter and a door exactly as your using them and I can have a look at what's going on under the covers!

[Chaos Awakes]

Sorry George, yep I'm using the terminology interchangably lol. It is quite confusing to me that you talk about counters counting down when you set a value in the editor for the counter which logic would state is a value to count up to.

Anyway, what happens is that when a coin is inserted, it activates a counter which starts off with a count of 4. When the counter reaches zero, it does two things:

1) It opens a door
2) It activates a relay

The relay performs 4 "deactivates" on the counter, which should set it back to it's initial value 4, yes? But this doesn't close the door again. Which, of course, is what I want but not what you said should happen.

When the player leaves the area, a pressure pad closes the door so they have to pay again to open it later.

[Sophia]

It is quite confusing to me that you talk about counters counting down when you set a value in the editor for the counter which logic would state is a value to count up to.

Why? It's no less logical to state that the value specified is a *starting* value.

When the counter reaches zero, it does two things:

1) It opens a door
2) It activates a relay

This is not possible, because one of these requires an activate, the other a deactivate. What I suspect you're really doing is activating a relay that in turn deactivates the door. The opposite of this is a deactivate to the relay-- and deactivating a relay does nothing, which is why the door doesn't close.

Incidentally, the new version of my editing guide has a section all about counters and relays.

[George Gilbert]

when you set a value in the editor for the counter which logic would state is a value to count up to.

Not really - it's the value of the counter. I don't think anywhere does it say that it's the *target* value...

If you think about it, this way I only have to store 1 number for the counter (its current value). The way you thought it worked, I'd have to store 2 (its current value and its target value); so its more efficient my way (and it's the way most counters work in computing contexts).

On reflection though, I can see the source of confusion!

Anyway, what happens is that when a coin is inserted, it activates a counter which starts off with a count of 4. When the counter reaches zero, it does two things:

1) It opens a door
2) It activates a relay

The relay performs 4 "deactivates" on the counter, which should set it back to it's initial value 4, yes?

Yes.

But this doesn't close the door again. Which, of course, is what I want but not what you said should happen.

Yep, that's the bit that confuses me and I don't really understand what's going on (which is why I'd quite like to see what's happening in a debugger!).

Interestingly, what you describe is sort of similar to the two-lever "puzzle" in the middle of the screamer level in DM (just after the green button by the pressure pad and just before the bit where you have to put an item in the teleporter). There there is a counter that starts with a value of 2 and only when both levers are down (which sets the value to 0) does the door open. After that you can put a lever up and the door goes back down again. Specifically there, when the counter is no longer zero after having been zero, the door closes (as it should).

[George Gilbert]

Here's a thought - perhaps when the counter reaches zero it's targets actually mean that the counter set back to 4 all happens just before the door opens.

i.e. the order of the targets in your counter TARGET=() section (and/or any supporting relays) mean that it's actually doing step 2 then step 1.

Wouldn't that give you the behaviour you observe and mean everything is working as (at least I) expected.

[Sophia]

i.e. the order of the targets in your counter TARGET=() section (and/or any supporting relays) mean that it's actually doing step 2 then step 1.

I think what's really going wrong here is that the explanation was an oversimplication, because it's impossible to open a door and activate a relay from the same counter! (The door opening would require a deactivate-- and, as I said before, sending the action through a relay would make the door not close)

[Chaos Awakes]

Hi guys,

Yep, I think George is actually understanding what I'm saying. Perhaps I'm being a bit black and white, I knew George would get what I meant without having to explain in every little detail. You're right, Sophia, the relay activates another relay which closes the door, but I thought that was a bit obvious to write out everything in excruciating detail lol.

So the explanation Sophia gives above explains what is happening. I'm glad it's not a bad because I've got "pay to enter" doors everywhere on 20 levels of the dungeon!

As far as the "count up/count down" thing is concerned, I think the source of confusion is the difference between "programmer thinking" and "layman thinking". I cannot think of a single example in the real world of things that count down - except for countdowns(!) - the hours, seconds and minutes on my clock count up, my video display counts up, the playtime on my CD player counts up, when I count anything in my head I go "1,2,3". Counting down just doesn't occur to me, but I see why it would take less storage.

[Sophia]

I thought that was a bit obvious to write out everything in excruciating detail

First rule of bug reports: Write everything out in excruciating detail.

[beowuuf]

Real world counters - personally, I always think 'five minutes to go' not 'oh, 5.25...i can go at 5.30'. : )

[Chaos Awakes]

This is true