ID:264619
 
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.
Infinite loops that do not sleep will tend to do that. You need a sleep() statement (probably a bunch, between each step) in there.
In response to Garthor (#1)
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.
In response to Gr1m d4 r34p3r (#2)
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.
In response to Kaioken (#3)
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?
In response to Gr1m d4 r34p3r (#4)
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>
In response to Kaioken (#5)
Alright thanks.