Default behavior in multiple files

ID:170039
 
Mar 28 2005, 2:52 pm
I have a couple different files in which I redefine the same proc several times. However, I want these definitions to work together; basically, I'm trying to be modular (something I normally don't like, but it suits my purpose here). To give you an example of the sort of thing I'm trying to do, here are some example code snippits:

/*This is in the file 'movment.dm'*/
atom
 var
  rough=0
turf
 grass
  rough=0
 tallgrass
  rough=1
mob
 Move(var/atom/where)
  if(..())
   if(where.rough)
    pixel_step_size=2 //Make it look like it's moving slower
   else
    pixel_step_size=0 //Set to default


/*This is in the file 'attack.dm'*/
mob
 var
  ap=5
  inBattleMode
 Move()
  if(inBattleMode)
   if(ap)
    ..()
    ap--
  else
   ..()


Now, these are just examples, and not actually the code or approach I am using, so I don't care if this is 'bad' code or if there is a better way of doing what was done above. What I need to know, is how the compiler handles this. Will only the last encountered version of mob.Move() be compiled, or will they be compiled such that they work together?

An example would be:
Because 'movment.dm' is compiled first, the ..() in that file refers to the built in movment procs provided by BYOND.
Because 'battle.dm' is compiled next, the ..() in that file refers to the last Move() proc defined, namely, the one in 'movment.dm'.
If there where another file, let's say 'spacetravel.dm', which defined Move() yet again, this file refers to the last Move proc defined before it, namely, the 'battle.dm' version of Move().

I'm guessing that this is not how it works, but I would like to know how it does work, and how to make multiple files work together modularly. Thanks.
Mar 28 2005, 5:05 pm (Edited on Mar 28 2005, 5:13 pm)
As I understand it ..() will go to the previous version of a proc (the last one compiled before the current one). With your example, given that DM includes files in alphabetical order, the first version would be the built-in one, then the second would be the one in attack.dm (a comes before m), and the one in movement.dm would be third (compiled last). Since the one in movement.dm was compiled last, it will override the others. If you call ..() in there, it will go to the one in attack.dm, etc.. If I had to guess about what actually happens within DM, I'd say it builds the proc when compiling.

Example:
// attack.dm
mob/Move()
  world << "I like pie!"

// movement.dm
mob/Move()
  world << "I like cake!"
  ..()


That would become this:
mob/Move()
  world << "I like cake!"
  world << "I like pie!" //..()


I'm having a hard time explaining this, so maybe testing it yourself would clear things up. Just put this in a couple of .dm files to see the order of execution.

mob/Move()
  world << __FILE__
  ..()


As a final note (yeah, I'm almost done =P), you can change the order in which .dm files are compiled. Look at the .dme file for your project. It has a list of #include statements, that's the order they are compiled in (top to bottom). If you want to change it, click the checkboxes beside the .dm files to un-include them. Then, inculde them in the .dme file yourself (outside of the comment blocks). =)