ID:138410
 

Deadron is right. Enter() is not truly appropriate for generating side-effects, because it is actually defined as a question, not an event. It answers the question, "can this object enter?", and does not necessarily mean the object will enter.

Practically, you can often depend on the entry if you are going to return a true response, but that makes for an awkward situation if the side-effect requires the object to have already entered the new location.

There are a couple ways to deal with this situation. As usual, one is a hack, one is the right way, and one is to change the language.

The hack is to go ahead and force the movement of the object inside Enter(). Example:

mob/Enter(obj/O)
   . = ..()
   if(.)           //it is ok to enter
      O.loc = src  //force movement
      //do side-effects here



That is the hack. As implemented, it has the dissadvantage of bypassing the call to Exit(), but you could call that manually before setting the loc. The built-in Move() procedure is smart enough to notice that you already moved the object and will just return without doing anything.


The right way is along the lines Spuzzum suggested. You can define an Entered() procedure and call it in your own soft-code Move() procedure. As Deadron noted, this doesn't work when you need to bypass Move(). However, I am surprised that a vocal OOP proponent would be setting an object variable directly like that!

Of course you need to have a proc (say) ForceMove() which calls the events Exited() and Entered() but which does not bother to ask permission Enter() and Exit().

That brings us to the final solution which is to modify the language. Movement, after all is a fairly basic aspect of the whole system and it helps in the re-use of code and in the dialogue between programmers if the foundation is standardized.

I anticipated this potential problem but was hoping (for simplicity) that people would be happy to use Enter() and Exit() for the dual purpose of query and event. That requires a certain willingness to use them in a restricted fashion, which I am afraid the valiant OOP proponents will frown upon (and rightly so).

So, you can expect to see Enter() and Exit() showing up in the future in the past tense (if that makes any sense).

As a slight punch back at the OOP proponents for complicating matters, this will encourage people to continue to set 'loc' directly, since I will ensure that the events (but not the queries) still get called in this case. I guess that will make one (suspect) OOP proponent happy!

--Dan
First off, thanks!

My current game happens to be tripping over the need for an Entered() all over, which means that I'm doing my own code for it in several different places for different classes, which offends my inner OOP proponent.


On 9/1/00 8:50 am Dan wrote:
I anticipated this potential problem but was hoping (for simplicity) that people would be happy to use Enter() and Exit() for the dual purpose of query and event. That requires a certain willingness to use them in a restricted fashion, which I am afraid the valiant OOP proponents will frown upon (and rightly so).


For informational purposes only (I've already got working code in place for these cases), here are the areas where I'm running into Enter() not being sufficient in itself:

- The container example explained previously: the mob needs to know that something has entered its contents so it can then move it into the appropriate container. In this case there is no way to rely on the default Enter() assumptions, because you can get in a tug of war that way, with an object being moved multiple times unintentionally, ending up such that the game has "lost" the object.

- Side effects from entering a turf. Mobs in my game can drop objects for strategic reasons. So say they drop a bobby pin to stick the bad person following them. The bobby pin needs to know when something has entered the turf so it can stick that mob. So the turf needs to broadcast the fact that someone has entered -- which it can't do in a guaranteed manner using Enter().

I do want to mention that I'm quite pleased that, Enter() workaround and all, it took me maybe an hour last night to implement in perfect working fashion the first time the Enter() workaround, the turf event broadcasting, the droppable items that effect things that come onto their turf, and a "droppable" stat panel in which you click on an item to drop it while you are running.

I consider this to be a pretty incredible rate of productivity, especially given that this was all very unique behavior and not stuff that would even by possible in the more restricted "rpg makers".


As a slight punch back at the OOP proponents for complicating matters, this will encourage people to continue to set 'loc' directly, since I will ensure that the events (but not the queries) still get called in this case. I guess that will make one (suspect) OOP proponent happy!

Since obviously there is a disconnect in expected use of Move()/loc and at least how I'm using it, I'll start a new thread showing how I'm using it in my current game. It will at least be educational to figure out why the universe is inside out on our roles in this issue.