Dungeon Master Forum

On an AND/OR gate, what is edge detection and how do I use it?

Edge detection means the activation etc happens on the transition between states only, not in the state itself

Example.....

An And Gate that starts at value zero and sends a message
when it is value one.

Begin game. Set bit zero. Now the value is one so it sends
a message. Set bit zero again. Now the value is one so
it sends a message. Set bit zero again. Now the value is
one so it sends a message. Etc.

If you choose Edge Detection on the resulting value then
it only send a message when the value changes from 'not-one' to
one. And in the example, only the first message will be sent
because the later actions did not change the value (it was
already one).

'Edge Detection' comes from the electronic lingo. If you look at
a signal on an oscilloscope the change from zero to one looks
like the edge of a clift.

A good candidate for a tutorial. With diagram, perhaps. Anybocy
want to write one?

So for example, if I have edge detection set to Bit Set, the and/or logic will only process it's action when it receives a Set message from another actuator?

It will only process it's action if it receives a set message from another actuator, and it is currently unset itself

(For example, a self triggering system like the librasulus strream of fireballs won't work with edge detection, because after the initial unset- set transistion, it will not respond again unless the system is unset)

Gotcha, that makes sense. Thanks for the help guys.

Beo, do you know of any good examples of existing dungeons that utilise the edge detection? I'd like to pull it apart to see how it works in practice.

the original dm actuators, to my knowledge, didn't use edge detection, every set signal would reinforce the set of an actuator only

or, in other words, only somehting like conflux using paul's expanded DSAs and and/or gates would show this

OK, that's what I suspected having had a look through DM quickly.

Also, I just want to get things completely straight regarding the And/Or editor window in CSBuild.

There are two values top left: initial and target. I am assuming that the initial value increases/decreases as it receives set/clear messages from other actuators. Is that correct?

Also, the Is Equal/Not Equal windows relate to whether the initial value matches the target value, correct?

Also, I'm a little confused about the order of objects in the edit windows. For example, if adding items to a wall by clicking New, they are numbered from 1 at the top of the list, to say 4 at the bottom. But in game they are displayed/processed in the opposite order (?). Obviously this is important for 'rotate' actions and the like. Which way round do rotated objects need to be created?

Also, when releasing an item from the wall using the Swap Object type, does it matter where in the list of items it appears?

Have you read the technical documentation for the
And/Or Actuator?

dmweb.free.fr
technical documentation
Actuators
And/Or Actuator

It is not complete but it is a start. Maybe it can have
a FAQ appended to it or something.

Ah, fascinating stuff. I think I'm slowly understanding it.

Now we have four bits of memory that can be independently initialized when the dungeon is designed and that can be independently Set or Cleared during gameplay by Timer messages. Now we will add the 'Target' values. These are four bits that are specified at design time and which cannot be changed during gameplay. So let us name the 'Memory' bits M0, M1, M2, and M3. And let us name the 'Target' bits T0, T1, T2, and T3. The And/Or actuator tests whether (M0 equals T0) AND (M1 equals T1) AND (M2 equals T2) AND (M3 equals T3). Hence the 'AND' part of its name.

This is the bit that I didn't know. But it confuses me even more now! How do I 'independently initialize' these four memory bits? There's only one initial value and one target value in the and/or gate edit dialogue. How do I define a value here that relates to the four memory bits?

Finally, which of these four memory bits relate to which direction?

Gah, I'm not very good at all this logic stuff!

You weren't good at riding a bicycle when you first tried it either.
Just a bit of practice is required then you have a powerful tool
at your disposal.

I'll let someone else tutor you. I am rather confused myself
with the 64-level problem.

I edited my post -- made some connections that voided a previous query, but I've now added two different questions.

you need to put the binary values representing the four memory values and convert it to decimal

So if you want a 'set to all faces' state required for activation, then that's 1111, so 15
If the initial starting condition is all faces except north are set, i believe it's 1110 (north = least significant bit, i'll leave zyx, paul etc to confirm). It goes clockwise for east, south and then west

Counting RTL or LTR? I assume from your comment about north, that it's RTL. Therefore:

1111 = W,S,E,N and 1010 = W,E

Is that correct?

For permanently firing actuators, initial and target set to the same? Seems to work OK in the simple examples I've tried.

As fiddly as this is, it's much much simpler than DMute and Hex Editing! I love that CSBuild exposes *everything* in a more intuitive manner. I just need to learn a bit more about the specifics!

Had a quick look at DSAa.... *shiver* *twitch* *gloonk* *brain boils*

lol, the trouble is i haven't used csbuild for a normal and/or gate, so not sure.

ok, just got over my laziness and tried my supposition - the answer is yes, it is right to left

hadn't noticed all the edge detection entries, some actually puzzle me to their exact meaning, so might play around with that (the imput, output, input no output')

For permanently firing actuators, and also thigns liek the wall => toggle of things like the riddle room in DM, you can have both set to the same, of have the triggering face unset initially - either work fine : )

And yes, this is much easier, then again DMute was never designed to interact with actuators, so the fact there was a mechanism to do as much as you could is remarkable!

Still, you can do in two easy numbers soemthing i can't fully do in DMute, so CSBuild is winning : ) That's before the expanded edge detection and actuator react stuff comes into play : )

The more I delve into this, the more respect I have for FTL. The engine is incredibly clever, and seems to have almost unlimited possibilities in the scope of a dungeon game.

I'm also playing EOB abd Black Crypt again at the moment. Obviously, I don't know anything about their internal mechanics, but they don't seem to be half as clever as DM. Indeed, EOB levels are very boring and there is actually very little of interest in the design.

Way to go FTL (and Paul too for making this stuff understandable!)!!!