How to: Create a shop

[TyGuy6]

Yeah, Paul's right; who cares about the older version. But I'm glad to know that it didn't work because of the addition of global variable access.

So, I'm working on a way now to allow the selling of consumables. Problem is, the shop can't say, "you break it, you buy it," because what if they don't have the money? So the shop has to only allow people to pick up food if they have the money to buy it. An alcove that is only open if you have the credit to take, say, the drumstick it it?

So I wrote a DSA (I call it Shop Credit Checker or some such.) that works with the shop Lost and Found DSA to decide if the player has a certain amount of credit. and uses an extra global variable (15) to store the shop's original value. Whenever the Lost and Found does a Check Payment, its output should be routed also to the Credit Checker. Thus, whenever the Lost and Found (L&F) is triggered, the Checker will output S0 or C0 depending on whether the credit is equal to or greater than the value in Parameter 1.

As a test I made it tell the customer at the door if he owed the shop money. The only problem with this is that the customer will be told this every time I trigger the L&F. Instead I think I may make the exit pad trigger the Credit Checker directly, but it will have to be after the L&F has done its work. Is 1/6 second enough time? (In other words, does the L&F do its work all in one moment of time?) Could I even make the pad trigger in the same moment that the L&F is triggered? Understand that the L&F has to send messages in a loop through other DSAs back to itself before it is done. If I can do everything in the same moment, I might just trigger the Credit Checker directly in every case.

[beowuuf]

I believe DSAs trigger in real time not DM time, so finish their calculations in the 1/6 game tick

If they didn't they couldn't be effective filter interrupts

[Paul Stevens]

Messages sent with delay of zero will be completely
processed in the same 1/6 second tick. You need
to be aware that messages to be processed in the
same 1/6 second tick will NOT be processed in any
particular order! The the queue of messages is
not a linear list. All the messages to be processed
at a particular time are put into a bucket and
when the time arrives they are drawn out without
regard for the order that they were added.

[TyGuy6]

Hmm. So you are saying that two pads in a certain "physical" order on the same square are not guaranteed to trigger in the same order every time? I ask that specifically because I think I have relied on that sort of same-source ordering in the past.

I am guessing that you will say: it works now, but you don't guarantee that future versions will preserve the trigger order. If so, is there a way you can start giving a guarantee? Because I think it is rather essential sometimes to be able to order the 1-tick happenings.

[TyGuy6]

Aah! I've hit a snag. How do I make an alcove trigger something whenever a specific item is removed? I can only get it to detect when the last item is removed. Would it be very complicated to make it trigger on any removal?

I'm finding it very hard to put multiple consumables in my shop, even if I stick to one type, like apples. There just isn't a way to prevent the picking up and eating of more than you can afford. I may have to just have an apple shooter with refunds. Very unbusinesslike.

[TyGuy6]

Aha, I solved it! I just trigger a "shop check" every tick that you stand in front of the alcove. There must be a lot of overhead, calculating the shop every tick, but then you step off and the AND/OR feedback loop I created is stopped. It works great, and it will even let me have multiple types of edibles.

[beowuuf]

Floor switches:
That's how normal mechanics work I'm afraid - there are consistent ways to make quick tick signals if I recall correctly. For example, having a signal when target leaves signal on the previous square should trigger a second before the second trigger. Simply put, never have simulataneous actions happening that will target the same square. 1/6 of a second should be long enough to have something happen before something else and not have it be bad to the player.

I have created many pulsing switch mechanics that haven't broken with a 1/6 delay.


Alcove:

By normal DM mechanics, no

By super-duper DSA mechanics, yes - while the character is standing on the pad infront of the alcove, have a floor pad trigger DSA. Have a second floor pad infront of the alcove that sends a different message (say close instead of open) when the player leaves.

The DSA should run a check of all items on the alcove square, and set one of it's parameters if it detects the item. It should then check to see if that item is present on the alcove square (I knowm this first time around that sounds stupid). If the item is not, but the item flag was set, it should jump to your code. It should then send a message back to itself with a tick delay.

The C0 DSA line should swap the DSA to a new state temporarily so that the DSA self-targetted message lands on a null square. The DSA should then reset the 'object there' flag and restore it's own state.


A big long winded, but that's how to make that work.

Edit: Just realised you got this already - NM

[TyGuy6]

Floor Switches:

For example, having a signal when target leaves signal on the previous square should trigger a second before the second trigger.

Mind if I nominate this for the "most obfuscated sentence" award? I think I sort of understand, but I'm glad you put it simply in the next sentence.

Simply put, never have simulataneous actions happening that will target the same square.

At first I was doubtful of this, but with a little testing I began to believe. I will follow your advice. Thanks for clearing that up.


Alcove:

Hmm. Thanks for your DSA discussion. I think I could figure out how to do it if I had to. (I found I could get the job done with a couple of AND/ORs.) The hardest part of creating the DSA you described would be the interfacing with the alcove, but I understand there are explainations for all that stuff. For now, I'm glad I don't need it.

[Sophia]

From beowuuf, that's about a normal sentence.
Wait until he starts with the Thumb Polish!
(That is, the Polish language typed with one's thumbs, not nail polish only for use on thumbs)

[Paul Stevens]

there are consistent ways to make quick tick signals if I recall correctly. For example, having a signal when target leaves signal on the previous square should trigger a second before the second trigger

I don't know what you said. Perhaps it is chinese using english words.
Some of the documentation that comes with small appliances is
very much like your sentence.

But it is NEVER true that you can predict the order of arrival
of messages which will be delivered during the same tick
of the clock. For example, if leaving a sqaure causes a
message to be delivered with zero delay and entering the
adjacent square causes a message to be delivered with
zero delay, then nobody can predict which will arrive first.

two pads in a certain "physical" order on the same square are not guaranteed to trigger in the same order every time

That is correct. You cannot predict the order and, moreover,
it will not be consistent from one activation to the next.
Sorry. It has never been consistent and it is not now
consistent.

is there a way you can start giving a guarantee

Of course there is a way. We put a man on the moon. We
can also order the messages. It reminds me of the problem
of duplicate messages for a particular square being discarded.
That did not make good sense (to me). But it was easy to
fix without changing the data structures. Ordering the
messages would require a change in the data structures
and quite a bit of change to the code with all the messy
details of backward compatability.

Show me an example of where it is badly needed and
I might consider investing my time.

[beowuuf]

Sorry, was just back from work and typing as fast as I could with the threat of a phone call stopping my chance to finish any second!

For example, having a signal when target leaves signal on the previous square should trigger a second before the second trigger.

If you have a 'message when party leaves' pad on the previous square, this manages to sneak a message in to the previous tick. At least, whenever I tested mechanics using a boots of speed party, this way consistently ensured something happened when other activation methods happening on the square could be too slow.

For example, if leaving a sqaure causes a message to be delivered with zero delay and entering the adjacent square causes a message to be delivered with zero delay, then nobody can predict which will rrive first.

Hmm, this contradicts my findings, but makes me fear I was just lucky when I tested my mechanics This was also a while ago, so I cannot remember how many times I tested the mechanics. So messages from previous step and the next step are processed in the same tick? They are not two different function calls?


DSA alcove:
The interface would from pads that the party were standing before the alcove, not any pads in the alcove itself. Glad the shop DSA works well, it might be a fun experiment to try for yourself if you are learning DSAs.

Wait until he starts with the Thumb Polish!

Hah, I have a new gold standard of encryption now - not only is there my bad typing, not only is there thumb polish, but my laptop keyboard drops letters when I type since I 'fixed' it for something else!

[Paul Stevens]

So messages from previous step and the next step are processed

Moving from one square to the next is a single step.
Not previous step and next step. A single step.
If two messages are created by that step then
they arrive in random order.

[beowuuf]

That's a shame ... as I said, I guess I was lucky at the time testing. Wish I could remember if it was in an active dungeon or just for an idea

[zoom]

No shame about that beo..! When you think about how much in peril the first astronauts where (heat tilings and stuff)
you ar, respectively now - after getting to know this fact- in a far better position to create dungeons than before!

Never heeded about messages´arrival .
Adamo had this demo with 2 doors that opened and closed differently
according to multiple timer entries checkbox menu I think ?.
has probably nothing to do with this.

so if I stand on a pressure plate and move a single step to another pressure plate,
which each generate a message(set and clear e.g.), then these 2 messages
would "arrive" in random order (at the same target [and different targets?]), right?
to mind comes the riddle in dm, where there is a 3x3 squares of pressure plates and 2 doors.
aah. its 2 doors. not one. nevermind.

[TyGuy6]

Aha! That is a good idea for a test, zoom. Have we discovered a new way to get pseudo-randomness? An item is teleported from one pad to another, thus triggering both pads at once, which set/clear the same teleporter and thus randomly move or not move item2 onto some more pads.

Not that monster movement doesn't give us a perfectly good randomness generator already.

And thanks, Paul, for clearing things up in my mind. I don't see a need for these messages to be ordered anymore. (Pun not intended.)

[TyGuy6]

Ok, I tried it out. I made two pressure pads, pad1 and pad2, that were on adjacent squares. A teleporter was turned off when you stepped off of pad1, but the same teleporter was turned on when you stepped onto pad2. No matter how many times I tried stepping directly from pad1 to pad2, I couldn't get the teleporter to turn off. I tested each pad individually and they worked as expected. (I found I had to add a party member first, however.)

My conclusion: the order of arrival of messages from pads in the same step (at least if one is a 'step off' and one is a 'step on') CAN be predicted.

I'd really like to know if I can count on this in future versions, as some of my shop mechanics rely on it. I'm sure others have relied on this consistency in their dungeons as well.

[Paul Stevens]

the order of arrival of messages from pads in the same step (at least if one is a 'step off' and one is a 'step on') CAN be predicted.

How much are you willing to bet? We can send our wagers to an
agreed-upon and mutaully trusted and willing third
party for safe keeping. When the money has arrived, I will provide
a recording that demonstrates my contention that you cannot predict
the order of arrival. I will collect the wager. If I fail to provide
such a recording within three weeks you will win the wager. I am
willing to bet anything up to $3000 (What I have here in cash).
The third party holding the money will be the final arbiter of
who wins the wager in case there is some disagreement.


Now, before I take your money, I should let you know that the
order of arrival is certainly NOT random. If it were random,
we could not play back recordings. QED.

It dependes on exactly how many entries are in the timer
queue. If you repeat the same experiment over and over
with the same number of entries in the queue then it will
always work the same. A monster on another level might
add an entry to the queue and cause it to work differently.
I think (But have not really investigated the mathematics)
that it is most probable that the messages will be delivered
in the order they were created. But I am quite comfortable
betting that it is not always so.
====================================
The other topic: Will I fix it? Again, if you can demonstrate
a powerful need, then I might find time to make this
work as you want it to work. So far, I have not thought
of a case that cannot be solved relatively easily without
any changes to the engine.

I agree it would be nice. But when I weigh the
price/benefit, I come up with the price dominating.
I am wiling to be proven wrong.

[TyGuy6]

Ok, I get the point. I guess we'll just have to be careful when building dungeons, since any mechanic based on that might fail every 100th or 1000th time. It makes me nervous that we can have bugs that are so debug-proof, but if the dungeon designers are careful they can avoid them. No need to go changing the code. Thanks for explaining.

[Jan]

And I was hoping to be selected as the "agreed-upon and mutaully trusted and willing third
party for safe keeping", and to have therefore a beautiful holidays on a remote tropical island. *sigh*

[zoom]

@jan
you would probably have been intercepted at the airport already

so if I stand on a pressure plate and move a single step to another pressure plate,
which each generate a message(set and clear e.g.), then these 2 messages
would "arrive" in random order (at the same target [and different targets?]), right?

I should let you know that the
order of arrival is certainly NOT random. If it were random,
we could not play back recordings. QED.

I am sorry for mentioning the word random. would "arbitrary and consistent" order be more apt?

ermm. may I inquire to what "QED" stands for?

[beowuuf]

Quad Erat Demonstrandum, latin for something like 'that which was to be proven' - basically a way of going 'ta-da!'

[zoom]

aahh! thanks beo!

[Paul Stevens]

Quad Erat Demonstrandum

When I took Latin, it was 'Quod Erat Demonstrandum".
But that was 50 years ago and things can change.
I think 'Quad' generally meant four of something.
See:

http://en.wiktionary.org/wiki/quadrilateral

[Roquen]

I prefer the little square...just to further pollute the thread.

Maybe we could add that and a few other formal symbols to the smilies???

[zoom]

Well, it is off topic. S*.. Happens.
It is always good practice to double check on information. I would have found what it meant if I had googled it.
Lazy or mindless as I were I jsut asked bluntly..but then again, questioning is not bad, secretly looking up words is also not always very informing for others..
not that I want everyone to now what I don´t know! [/off topic on with the shoppe! thanks for clearing it up]

[Paul Stevens]

on with the shoppe

Shoppe? What shoppe?

[zoom]

I thought the whole point of this threat was the creation of an olde shoppe, non?

[Paul Stevens]

Ok! OK! You don't need to 'threaten' me!

I've been thinking.....hmmm....well pondering, at least.
Perhaps we can take advantage of that 99 chance in
a 100 of its working right (the messages delivered in
proper order). The messages are stored in a binary
tree. There might be a way to catch that 1-in-100
case rather efficiently with some clever recursive code
and fix it up. I agree that it would be more friendly. I'll
see what I can do. Modern machines are so much more
powerful than the old 8 MHz Atari that we can afford
a little extra overhead. And doing it this way introduces
no messy backward compatability issues.

The other thing that might interest you is is that
some messages are delivered out-of-order quite
intentionally. But I don't think they are messages
that you worry about. For example, messages
created by monster AI may all be delivered before
messages created by switches, pressure pads, etc.
There are dozens of message types and each type
has its priority among messages to be delivered
during a single tick of the clock.

[TyGuy6]

Threaten you? I know not of what you speak. Seriously, I don't expect you to rework the code. If you do, I will think you rather generous with your time. (Not that I wouldn't appreciate it.)

[zoom]

@TyGuy6: -->silly typo of mine. Has happend some time ago with cows around..let´s thread-shred-it!
@Paul Stevens: Omg. Did not intend to threaten you for sure! I should really avoid at least this particular mis-spelling, if anyhow possible !