I like the idea of a locking system -- makes a lot more sense to me now after using Java threads, and I totally see it being applicable here.

A thought, however, is to allow locks on entities, and not just scripts. What happens when multiple scripts want to lock on an entity. Like, a player clicks, and while they are clicking, some time based event happens -- should the lock remain and finish the player movement, should the lock be tossed based on priority? I mean, what if the player is involved in the sequence and have to walk somewhere else -- the lock gets pretty messed up if they are still moving, right? I notice that you give the entities multiple scripts to lock on, but how does it make sense for more than one script to have a lock on an entity -- I suppose you could assume that once a script's personal lock is finished, that it should be able to continue its code -- but isn't the idea of the lock going to correlate to actions that should never be interrupted?

Again, the click and the timed sequence: I make a click, the script locks on the player entity, and then a timed sequence begins. Shit! Now the player is "moving" as well as involved in a timed sequence...

Pretty sure this is why Java uses one lock, and puts every other requesting lock in a wait queue and uses a notifyAll(). This way, the timed sequence, which requests a lock on the player object, is in a waiting queue until the walk is completed. Once the lock is released, a notification to all waiting scripts should be sent. Perhaps in some sort of queue.

I dunno...just some things to think about. I am sure you have an answer already.

Visage, good observation!

Yes I have considered this, it is a potentially sticky situation, currently we handle such things through scripts themselvs.

each entity has an array of 'script locks' each script lock, points to a script process (which is current in a yielded state), and the lock is keyed on a certain event. When an entity fires an event (such as onMoveDone) it attempts to release and script locks it has (that are waiting for onMoveDone), you are right in your thought that a script process can never be locked twice, this is because only a script has an ability to lock itself (through calling a function that causes a lock), and once it is locked, it can not call functions until it is unlocked.

The tricky problem is much like you mentioned, since we operate in a multi-process type environment it is possible that the user clicks somthing which spawns a script process and eventually creates a lock. during this waiting time it is possible some other engine infuence could also spawn off a script process and try to interfear with what is going on.

for this we use logical mutexes in scripts to insure things go right, here is a classic example.

Bad:

user clicks somthing
script runs
player interaction is turned off
player is moved to new spot
during move player comes in visual contact with an NPC
NPC run script with onPerception
onPerception guides the player over screwing up stuff.


the way to solve this is to make onEncounter check the playerLocked variable (which is commonly used) to see if the player it busy before striking up a conversation.

I like your idea of using a single entity mutex instead, it could really uncomplicate things.

In morning's wrath, certain things such as onPerception were continuous events (they were raised every second if applicable), this was neccisary because if onPerception failed to obtain a lock it could not just 'give up' since there might be somthing important it needed to do. we would use variable gates to insure things happend in sequence too, such as:



I think I am going to give the single mutex a try!
thanks for the idea Visage =)

One thing to possibly think of is having lock priorities. Think MI or Indiana Jones. If you are moving right and a player goes to talk to you, they literally unlock your movement and take control of your character -- and the movement doesn't continue at the end of the scripted sequence. Locks that are hard scripted may have a higher priority than input scripts, and therefore can literally unlock the other script and take control -- and maybe even kill the other script completely.

For example, when you click on an item -- I assume you have something like:

onClickItem(Item &item) {
lockPlayer();
movePlayer(item.x, item.y);
removeItemFromMap(item);
giveItemToPlayer(item);
}

So what happens if I click on an item to pick it up, but a scripted sequence takes over. It kills my walk, but this script continues? Well, shit. Then the item disappears when I am not even close to it. So perhaps upper priorities literally kill the scripts of lower, input based priorities. The player can always click again -- but if a scripted sequence gets terminated, then things could get really ugly as far as logic for the game goes.

But lets say if you have the single lock and a waiting queue, well, it will be awkward if the interaction comes and the NPC is talking like he just noticed you, even though you walked by to pick up an item or something. It would make more sense that his scripted sequence have higher priority over player input.

Definitely a sticky situation...I will be interested to read what your final decision is on how to deal with it.

Wouldn't a stack be better for 'locking entities'?