Gr1m d4 r34p3r's Site

ID:264619

Jan 15 2010, 10:59 am

Code:

proc/Quite_On_Fire(mob/Man)
    Man.Health -= 1
    Man.quiteonfire = 1
    while(Man.quiteonfire)
        step(Man,NORTH)
        step(Man,EAST)
        step(Man,SOUTH)
        step(Man,WEST)
    sleep(60)
    Man.quiteonfire = 1

Problem description:
I tried creating a proc that mimics a frenzied man running in circle while being on fire. I'm not an expert at using the while() but I think we can do it this way?Anyway whenever my projectile call this proc using Quite_on_Fire(M)(with m as the mob) it lags or crashes the server severely.

#1 Jan 15 2010, 11:20 am
Garthor	Infinite loops that do not sleep will tend to do that. You need a sleep() statement (probably a bunch, between each step) in there.

#2 Jan 15 2010, 11:40 am

In response to Garthor (#1)

Gr1m d4 r34p3r

Oh.....Ohhhhhhhhhhhhhhhh.Alright well, I fixed that problem but now I have another problem

Bump(atom/movable/M)
            if(ismob(M))
                if(istype(M,/mob/player))
                    viewers(M) << "[M] has been hit by a Cannonball!"
                    viewers(M) << "<b>[M] <font color = blue>yells: ARGHHHHH! IT BURNS!"
                    Quite_On_Fire(M)
                    del src

This object keeps repeatedly bumping into M.

#3 Jan 15 2010, 11:52 am

In response to Gr1m d4 r34p3r (#2)

Kaioken

That would be because the object is not being deleted and you obviously have something that makes it continuously step forward, causing it to repeatedly bump.

When your Bump() override is processed, it calls Quite_On_Fire() before it deletes the object, and naturally, it waits until Quite_On_Fire() finishes (returns), at which point the caller proc (Bump()) continues. Because Quite_On_Fire() sleeps, it takes a noticeably long time (or forever, if the loop ends up being infinite) until it returns and the object is deleted.

Two of the possible solutions here would be to either put the body of the proc that takes a long time to finish in a new thread (spawn()ing off the proc body) so the caller doesn't need to wait for it, or to schedule the object to be deleted in a new thread before you call the taking-forever proc (again using spawn()). If you take the second approach, then you should also put the call to the proc in a new thread so Bump() can actually return.

#4 Jan 15 2010, 12:19 pm

In response to Kaioken (#3)

Gr1m d4 r34p3r

Okay I decided to take the first alternative so thanks. By the way, I got this from your projectile lib and in the lib you would override Bump()

Bump(atom/movable/M)
  if(ismob(M))

But I can't call on mob vars and often I need to use : to override it. Is there another way?What situations are : use for?

#5 Jan 15 2010, 2:00 pm (Edited on Jan 15 2010, 4:59 pm)

In response to Gr1m d4 r34p3r (#4)

Kaioken

Gr1m d4 r34p3r wrote:

Okay I decided to take the first alternative so thanks. By the way, I got this from your projectile lib

(It's a demo)

But I can't call on mob vars and often I need to use : to override it.

Since the var containing the mob isn't defined as of /mob type, but as of a more general type (/atom/movable), Dream Maker thinks the object in the var doesn't have mob vars and so prevents you from using them (the : operator skips most of this error checking). To circumvent this, you can declare a new var that's defined as the correct type, and copy over the reference to the object from the old var to the correctly-typed var. This is referred to as typecasting.

Bump(something)
   if(ismob(something))
      var/mob/X = something
      world << X.name //...

Is there another way?

You can also simply define the initial var as of the specific type. It does no harm as vars' defined type only matters for this error-checking and for specific built-in instructions that read it (such as for() and the shorthands of new(),locate()). It does not exist at run-time.
Of course, in cases where you need to use more than one distinct type, you'll need to typecast anyway.

What situations are : use for?

For when you absolutely can't use ., basically. Such as when whatever object you're accessing doesn't actually have a real type to use:

proc/MyProc()
   set desc = "Desc!"

mob/verb/read_proc_property()
   var/proc_ref = /proc/MyProc
   src << proc_ref:desc //outputs "Desc!"

mob/verb/view_overlay_info()
   for(var/x in src.overlays)
      src << x:icon

<hr>

...However, even in these cases, the . operator can be used with workarounds of varying quality:

mob/verb/read_proc_property()
   var/obj/proc_ref = /proc/MyProc
   src << proc_ref.desc //outputs "Desc!"

Since objs have a var named "desc", this compiles. This is essentially tricking the compiler, though, and is only a little better than using the : operator. You can perfect the technique, so that you retain the full potential of the error-checking you get with the . operator:

procedure
    var
        name
        desc
        category
        //hidden
        //popup_menu
        invisibility
        //src
        //background

mob/verb/read_proc_property()
   var/procedure/proc_ref = /proc/MyProc
   src << proc_ref.desc //outputs "Desc!"

Here a dummy object prototype is used that has the same properties as the inaccessible type you're representing with it, so if you try to use any property that the dummy type doesn't have (and the real inaccessible type, by extension), you get an error.

This essentially means that if you're pedantic it leaves the : operator to never be used, or almost never, similarly to goto.
<small>edit: forgot to complete a sentence</small>

#6 Jan 15 2010, 2:25 pm In response to Kaioken (#5)
Gr1m d4 r34p3r	Alright thanks.