Choices for a proc: What should i use?

ID:158987
 
Jun 1 2009, 1:16 pm
I am making a respawn proc, and right now i have 2 options, which one should i do? (and if possible, can you give me part of the code to do it?)

Option 1:
When a thing dies, it gets moved to a random place in a special z plane, then after x seconds it returns to it's origanal place with it's hp restored.

Option 2:
Thing is killed, and it's x y and z points are saved into variables. After x seconds, a new monster is made at that point.
Jun 1 2009, 1:41 pm
I'd say that option 1 seems to be the better option in terms of efficiency. This way would avoid the resources it takes to reallocate the same data over and over. Just be sure to refill their HP and remove status effects, upon respawn. Also, when they're dead you'll want to turn off their AI. Dead things don't need to think!
Jun 1 2009, 1:43 pm
In response to Vermolius
Thank you very much.
Jun 1 2009, 2:16 pm
Neos300 wrote:
When a thing dies, it gets moved to a random place in a special z plane

You shouldn't bother with that; a both better and easier approach is to just move the mob off the map (also known by various names such as The Void, Blackness, or Black Screen). This is done by setting a movable's loc to null. Though doing it more robustly would look more like this: 
atom/movable/proc/Move_off_map()
   if(src.loc) //if it's actually on the map currently...
      src.loc.Exited(src) //let the location know the movable left it
      var/area/A = src.Get_Area() //proc not included
      A.Exited(src) //also let the area know - since we're moving entirely off-map, we're definitely leaving the area
   src.loc = null //actually do the relocation

(That would make sure that when a movable is relocated to null, if it's on a location with Exited() overrides, those are processed instead of ignored, which could've led to issues in such cases)

Also, Option 2™ is really not necessarily the worse method. Recreating the mob has advantages, like:
  • Restarting from fresh can avoid potential problems/issues.
    • Creating a new mob means it's guaranteed to be a completely fresh one and so it will never accidentally have any leftover properties (of any form) from the previous one.
    • Deleting the previous mob means the game is guaranteed to recognize that it is essentially gone; if you delete an object, all references to it are automatically nulled out, so nothing references it anymore. However, if you keep the same object and just keep it off the map for a certain time, various stuff in your game could potentially still be referencing it (as it's the same object), if you didn't make sure you take precautions against this everywhere.
      For example, with Option 1™, a homing missile that is targeted at the mob would not naturally recognize that this mob is deleted (as it's not), and would still reference it in its target var. After the poor mob returns from its vacation off-map, the missile could suddenly hit it out of nowhere, sending it back for vacation again! But this mob was theoretically just born, and nobody even fired anything at that mob, and the only player around is in the other side of the map... how unfair! =P
  • If you don't keep the entire mob around while it's just sitting uselessly at nowhere doing nothing, you're saving resources. Instead of having the whole mob in existence and memory, all you have are like 4 numbers, the coordinates and the type.

And, maybe more, but I don't feel like pondering at the moment. Seemingly, a discussion like this belongs at Design Philosophy, as that's what it pretty much is.
Jun 1 2009, 3:40 pm
In response to Kaioken
Kaioken wrote:

You shouldn't bother with that; a both better and easier approach is to just move the mob off the map (also known by various names such as The Void, Blackness, or Black Screen). This is done by setting a movable's loc to null.

Right, I failed to mention something about his special z-level. Also, you have to realize that by sending a mob to null you also have a chance of deleting it accidentally, since you're removing a reference to the mob. If somehow by sending it to the void removes the last reference the garbage collector will gobble it up.

Also, Option 2™ is really not necessarily the worse method. Recreating the mob has advantages, like:

  • Deleting the previous mob means the game is guaranteed to recognize that it is essentially gone; [...]

    However, and I'm only taking the opposite side to consider the possibilities, you'll have to worry about null references if you manage to delete a mob that is still in use. You'd just have to be especially careful to validate that you still have the mob.

    For example, with Option 1™, a homing missile that is targeted at the mob would not naturally recognize that this mob is deleted (as it's not), and would still reference it in its target var. After the poor mob returns from its vacation off-map, the missile could suddenly hit it out of nowhere, sending it back for vacation again! But this mob was theoretically just born, and nobody even fired anything at that mob, and the only player around is in the other side of the map... how unfair! =P

    Which is where you'd check if the mob has a location, amongst your homing attacks and any other such procs, and cancel out if they don't.
Jun 1 2009, 5:09 pm
In response to Vermolius
Vermolius wrote:
Also, you have to realize that by sending a mob to null you also have a chance of deleting it accidentally, since you're removing a reference to the mob.

I've already realized, but you have to realize that if you have code spawned to relocate the mob, it of course has a reference to that mob, which will prevent it from being deleted. ;P

you'll have to worry about null references if you manage to delete a mob that is still in use. [...]

Yes, that's how it is in DM programming, and it doesn't really change considerably by whether you delete defeated mobs or not. Whenever there's possibility of an object you're using having been deleted (or even modified, in some potential cases), you need to (or should) re-validate in any case.

Which is where you'd check if the mob has a location, amongst your homing attacks and any other such procs, and cancel out if they don't.

Sure, but that's unimportant, that was just a particular example. :P You could come up with hundreds.