A dangerous game with procs

ID:162815
 
Nov 23 2007, 2:04 pm
When a proc spawns off a child proc, is there a way for the parent to reference this new proc and kill it prematurely?

What I'm having in mind is a missile proc, which I may want to kill before it reaches it's final destination under certain conditions.

But it would be nice to have references to spawned procs in general, for other curious things.
Nov 23 2007, 2:11 pm
Spawn a while loop for the missile, checking if a certain variable("disabled?"), and if it's disabled, break it.
Nov 23 2007, 2:20 pm
In response to Kaiochao2536
Kaiochao2536 wrote:
Spawn a while loop for the missile, checking if a certain variable("disabled?"), and if it's disabled, break it.

missile() is a proc that comes with byond. I can't break it like that.
Nov 23 2007, 2:25 pm
In response to Obs
You said a missile proc, not the missile() proc.

And no, you can't do anything to interfere with the missile() proc.
Nov 23 2007, 2:28 pm
In response to Kaiochao2536
How about any spawned proc?
Nov 23 2007, 2:32 pm
In response to Obs
Yes, inside the spawned proc.
Nov 23 2007, 2:39 pm
In response to Kaiochao2536
Kaiochao2536 wrote:
Yes, inside the spawned proc.

I was asking how to do it externally. What if a proc spawns and decides it's going to live forever? It has to be killed.
Nov 23 2007, 2:44 pm
In response to Obs
Then don't make while() statements without a variable argument.
Nov 23 2007, 2:54 pm
In response to Kaiochao2536
That is not always the case. Actually never.
Nov 23 2007, 2:58 pm
In response to Obs
Making while() statements with a variable argument allows it to stop when the variable is false. You can set the variable to false at any time.
Nov 24 2007, 7:29 am
In response to Kaiochao2536
The problem is I have a series of procs that simply stop working when another proc tries to hog most of the processing time. One proc constantly works on refreshing the player's client objects, the other is a recursive expanding algorithim. Both function just fine on their own.

But when you are trying to do both at once, the client object algorithim (which is set to be in the background) apparently stops working when the CPU goes under heavy load, and then it never starts back up again (the screen never refreshes for the player). It is also set to be a background proc.

I wanted to know just what the hell was really wrong with them.

Even calling for a hard reset, to clear the client screen of objects, doesn't work. It's like the proc just goes dead and freezes there.

But I still see the CPU load go up to typical levels in times when that client proc is supposed to be running, which leads me to believe that the frozen proc is an older instance of the client proc that is overshadowing the actual working version of the proc.
Nov 24 2007, 11:55 pm (Edited on Nov 25 2007, 12:01 am)
you could always have a conditional delete

stone
   parent_type=/obj
   proc
      is_airborn()
         for(var/atom/a in src.oview(1))
            if(a.density==1 && get_dist(a,src)<=1)
               return 0//super lazy collission detection
               //this wouldn't let you throw a stone length-wise next to a wall o.O
         return 1
      throwstone(mob/m as mob)
         if(!m) return
         missler(src,m,1/*speed*/)//psuedo code
         spawn while(src)
            world << "I am in the air!"
            sleep(10)

...

mystone.throwstone(m)
spawn while(m && mystone)
   if(!mystone.is_airborn())
      del mystone
      break //this will not continue the code under this line, its already executing
world << "IM FLYING!"


deleting the object will break whatever its doing procedure-wise

another thing you can do is put "stops" into the code that will make it break. you obviously can't do this with byond procedures because we cannot re-declare what they do. but you can write your own missle function, for example, and include a "break" within it

myfunction(var/y)
   if(!y)
      return 0 //this is where we "break"
   world << "blah!"
   return 1

...

var/yeah=1
while(1)
   if(!myfunction(yeah))
      break
   if(something_goes_wrong==1)
      yeah=0