When() Proc?

ID:151551
 
May 7 2010, 1:53 pm
Is there any proc I could use that executes another specified proc if or when something happens.
Suppose I want a person to jump up to an elevated platform when they reach the clicked elevated object.
If DM supports no proc that does so, what is the best method of creating one?
May 7 2010, 3:01 pm
You can find some handy resources here:
http://www.byond.com/members/ DreamMakers?command=top_search&text=event&type=resources

Essentially, you'd need to keep calling a proc to check if the conditions are met.

proc/worldcheck()
   //...
   sleep(1)
   worldcheck()
May 7 2010, 3:17 pm
comefrom: when goto isn't quite terrible enough.

If you want X to happen when Y happens, then make Y call X. If you want something to happen when a player moves, put it in Move(). If you want something to happen when a player clicks, put it in Click().
May 7 2010, 3:18 pm
In response to EGUY
That is quite a fantastic way to overflow the stack, crash the procedure, and break the game, yes.
May 7 2010, 3:27 pm
In response to Garthor
How so? Isn't it normally done as a proc that calls itself (I meant to say that you only call it once, but it keeps calling itself)? I may have left out a spawn() or something.

Haven't run into any problems so far with this...
world/New()
   ..()
   spawn() EventCycle()

proc/EventCycle()
   //do some stuff
   spawn()
      sleep(1)
      EventCycle()


Unless 'stuff' is really intensive.
May 7 2010, 3:41 pm
It is a far better practice to do as Garthor said, and if you want something to happen after something else happens, call it in the proc.

I.E: Make a proc that is called when the player lands on the platform, and do what you want in that proc.

You would be wasting huge amounts of resources doing it other ways.
May 7 2010, 4:27 pm
In response to Garthor
Alright, just to be clear, in Y first you call x, then you do what you wanted to do with y.
Sound good because it will finish x first, then do y.
one question though.
How do I carry across the variables with arguments.
        usr.Up(var/up_z=(src.pixel_z-usr.pixel_z,var/per=src))
    else
        return
mob
    proc
        Up(up_z,per)

I tried it like that and the variables were said to be undefined.
May 7 2010, 6:36 pm
In response to Kokomo0020
Kokomo0020 wrote:
I tried it like that and the variables were said to be undefined.

When calling a proc, you don't need to associate it's arguments in the call, but determine what they are inside the proc.

Ex;
var/up_z = src.pixel_z - usr.pixel_z
usr.Up(up_z,src)


But, you'll really want to polish what you have or redo it. Because I can think of many bugs and glitches from what I can gather that you are trying to do.

EDIT:
By the way, do you not see what is wrong with this line:
(var/up_z=(src.pixel_z-usr.pixel_z,var/per=src))

Hint; You're technically only giving the Up() 1 argument to work with at run-time.
May 7 2010, 6:36 pm
In response to EGUY
In that case it's only a matter of being very, very poor style, rather than one that will actually cause it to fail. A while() loop is what you should be using, not recursion.
May 8 2010, 3:06 am (Edited on May 8 2010, 3:44 am)
In response to Dark Vendetta
Tell me if this seems about right...
        var/up_z = (src.pixel_z - usr.pixel_z)
        var/other_z = src.pixel_z
        var/src_x = src.x
        var/src_y = src.y
        var/src_z = src.z
        usr.Up(up_z,other_z,src_x,src_y,src_z)
    else
        return
mob
    proc
        Up(up_z,other_z,src_x,src_y,src_z)
            if(other_z > usr.pixel_z)
                usr.Go(src_x,src_y,src_z)
                usr.pixel_z += up_z
        Go(src_x,src_y,src_z)
            walk_to(usr,locate(src_x,src_y,src_z),2)


Now I've got just one more problem...
When someone is sitting, if they click to walk to another obj or turf, they leave the sitting object's overlays or underlays.
I would subtract them from the lays in the Click() proc, but there's no way to carry across the variables...
May 8 2010, 10:52 am
In response to Garthor
And I do use while() loops, but I thought that the proc-that-calls-itself was more proper around here. So I never really mentioned using them.
May 8 2010, 11:00 am
In response to EGUY
It's not. The only time recursion is proper for purposes of simple looping is if you're using a functional language like LISP or Haskell or something.
May 10 2010, 3:27 am
In response to EGUY
EGUY wrote:
And I do use while() loops, but I thought that the proc-that-calls-itself was more proper around here. So I never really mentioned using them.

It is with some people because many around here aren't experienced at programming outside of Byond, so make things up on their own and decide on a whim what is "proper." If enough people decide the same thing around here, or if someone higher up the pecking order decides something, then many others around here start to follow the leader (or the mob).

This is the same way things were for a while in the real world of computer science, especially in the very earliest days. The difference now is that computer science has been developing for decades and has stumbled onto many reasonable design patterns and weeded out stupid ones. There is still a lot of the same problems in computer science in general though; there are many software engineers that decide that something stupid is better in their eyes.

I'm not necessarily saying that using spawn to avoid stack overflows for infinite recursion is stupid, but there is certainly no reason to prefer it. At best, depending on how it is implemented in Byond's code, it is slightly less efficient. Normally you don't care about a microsecond here and a microsecond there though, so that consideration is usually not worth thinking about.

Still, recursion just doesn't seem to be the logical choice for this, at least not to me for a situation like this. Where recursion is favored is generally those places where it is simpler and more readable/maintainable to do recursion. However, I have found that situation to seldom occur. In fact, I prefer to fit the entire loop structure inside the test part of a while loop and give it no body whatsoever, and I have found more situations where that is appropriate than I have found situations where recursion is necessary.
May 10 2010, 3:33 am
In response to Garthor
That's basically what setjmp()/longjmp() in C do.
May 10 2010, 3:39 am
I am not understanding from your reply here [link] what you're trying to do, but I will make a suggestion about your original post.

First, you usually want to call some action in the place where it is appropriate. When you're jumping, just do the "get onto the platform" stuff when you reach the platform height.

Sometimes it is not this simple. If your situation is not, you can build your own trigger system. Here is an article at Wikipedia about a proper design pattern that might suit your needs. http://en.wikipedia.org/wiki/Observer_pattern