Door Events

[Legacy_Leurnid]

               According to the Lexicon:

OnPhysicalAttacked
The script attached to this event fires each time the object takes
physical damage...

and

OnDamaged
The script attached to this event fires when the object is damaged.

I have a number of theories about how those very similar sounding descriptions are different, but I thought instead of spending a few hours building scripts and staging a series of tests, I would just go to the experts... What is the difference between these events?
               
               

               
            

[Legacy_henesua]

               Prior to dealing damage other events are executed. A PhysicalAttack is an attack using weapons. So when a PC or NPC attacks (with a weapon) an object (door, creature, placeable), the Attacked event executes.

The Damaged event only executes if the NPC takes damage.

I use these events on all of my doors, and many placeables. Each door can be configured to only be damageable when attacked by particular weapons. So when a door is attacked, I check the weapon of the attacker, and if the weapon lkacks the characteristics I am looking for, I temporarily set the plot flag on the door to TRUE.
               
               

               

                     Modifié par henesua, 21 mai 2012 - 01:27 .
                     
                  

            

[Legacy_Leurnid]

               Ah, thank you.  

Now, my next question on the door event front:  A regular mouse click on a door defaults to the 'OnOpen' event, I have assumed.

Can I detect for a radial menu 'open' command vs.a simple mouse-click, and pass a regular mouse click to 'OnUserDefined', or might I be lucky enough to have a simple mouse-click default to OnUserDefined first?
               
               

               
            

[Legacy_henesua]

               I don't believe so. You'll need to describe what you want to happen if you want help.

I developed a set of scripts for doors to customize their behavior, and it involved going with the assumption that either OnOpen or OnFailToOpen or OnAreaTransitionClick would be the first script to execute.

My door system for example has a way to limit whether the creature using it can open it or not. Some doors require hands to open. Most doors allow some creatures to simply pass them if they fail to open (oozes, incorporeal, mice etc...) These methods required conducting the relevant state and situation checks in one of the three scripts I mention above.

Here's my OnOpen event for a door
               
               

               

                     Modifié par henesua, 21 mai 2012 - 02:45 .
                     
                  

            

[Legacy_Leurnid]

               I want to restrict direct mouse clicking on a closed door to *never* attempt to open the door, but instead fire off

void main() { object oPC=GetLastUsedBy(); object oTarget=OBJECT_SELF; AssignCommand(oPC, ActionExamine(oTarget)); }

I want the radial command 'Open' to attempt to open the door, however.

If I can parse via script if the radial  'Open' command was used, or if a defaulting click was used, I could leave it in the OnOpen event, but I have not been able to find a way to do that.
               
               

               
            

[Legacy_Leurnid]

               I have seen several systems that add functionality to doors via conversations, but I would like streamline why and when a conversation is initiated. One of the chief annoyances (for me) in modules that make heavy use of that sort of system is that most doors become a distracting conversation about opening the door. There are times and places where the conversations make perfect sense, but I would like the option to skip the chat and press one's luck. What I am hoping to find is a middle ground to use the radial menu options without the conversation, but a default click will either return a conversation, or an examination of the door.

I would like to streamline that process by making the radial menu do the heavy lifting for me, and only engaging in a conversation about the door if another option isn't selected.  
The default condition on a direct click of a door that doesn't need a conversation would be to return an examination of the door (as the script above does). That will help reinforce using the radial menu command options in preference to default-clicking doors.

My first thought was to mimic an existing system, and just lock all the doors, then put my script in the FailToOpen, but what I was running into was you can't directly open the door, because it is locked, but oddly, you can directly BASH the door down.

Ultimately, I am hoping that there is a means, possibly a module or area level script, to differentiate a 'click' from an 'open' on a door.  If there isn't,  I have to either only use door conversations when it is probably important (which has the same effect as a DM starting to roll dice and shuffle papers behind the screen), or use door conversations excessively to avoid telegraphing my punches, and boring players.
               
               

               
            

[Legacy__Guile]

               Lock the door.....  (use a bogus name for the key required, that way it's only opened through scripting)

and then from the OnFailToOpen event, place your script...

After the they have failed to open, unlock the door after a short delay (say 10 second or whatever)
(that is if they are suppose to open the door)

You may want to just simply put a start conversation script in the OnFailToOpen event and put the information you need the PC to read there....
               
               

               

                     Modifié par _Guile, 21 mai 2012 - 03:41 .
                     
                  

            

[Legacy_Leurnid]

               

_Guile wrote...

Lock the door.....  (use a bogus name for the key required, that way it's only opened through scripting)

and then from the OnFailToOpen event, place your script...

After the they have failed to open, unlock the door after a short delay (say 10 second or whatever)
(that is if they are suppose to open the door)

You may want to just simply put a start conversation script in the OnFailToOpen event and put the information you need the PC to read there....

But doing that precludes using the radial menu option to open the door without conversation or delay, because the door is locked. 

I suspect I am trying to find an elegant solution where none exists... story of my life.
               
               

               
            

[Legacy_kalbaern]

               

Lock the door.....  (use a bogus name for the key required, that way it's only opened through scripting)

Actually, lock the door and set the door as requiring a key to open. No bogus name is required, just leave the name field blank.

As far as what the OP is attempting, I don't think its possible.
               
               

               
            

[Legacy_Leurnid]

               I have seen a few modules that were designed using the placeable 'secret doors' as regular doors. I had initially assumed the choice was a visual aesthetic, but now I am wondering if it was motivated by scripting issues as well.
               
               

               
            

[Legacy_henesua]

               At moments like these, I take a step back and look for other ways I might achieve the results I want.

Perhaps those secret doors were a means to that end.

Anyway, thats my advice. There's more than one way to solve a problem. And sometimes redefining the problem helps too. '>
               
               

               
            

[Legacy_kalbaern]

               I think the real question is: Why do you want the door's description to show up upon a mouse over?

If this is an attempt to add depth and realism based on that description appearing to a player, then another option might be to use "flavor" triggers instead. By "flavor" trigger, I mean a painted trigger with an OnEnter script that fires of some type of text message about an area or specific object. I use these in all "flavors" and "varieties", some needing only a PC to cross into them, some displaying a message based on a skill check like Lore or Spot, some check for a known language or race, etc... .

Anyhow, telling us "why" seeing the description on your doors is desired would help with alternate solutions here. '>
               
               

               
            

[Legacy_Leurnid]

               

kalbaern wrote...

I think the real question is: Why do you want the door's description to show up upon a mouse over?

If this is an attempt to add depth and realism based on that description appearing to a player, then another option might be to use "flavor" triggers instead. By "flavor" trigger, I mean a painted trigger with an OnEnter script that fires of some type of text message about an area or specific object. I use these in all "flavors" and "varieties", some needing only a PC to cross into them, some displaying a message based on a skill check like Lore or Spot, some check for a known language or race, etc... .

Anyhow, telling us "why" seeing the description on your doors is desired would help with alternate solutions here. '>

Using 'examine' as the default action on a mouse click was not my chief goal, actually, but part of a grander scheme that is appearantly out of reach within the default coding of NWN.

What I would like is this:
You see a door, if you want to open it, you use the radial menu - open.
If you want to unlock it or damage it, again, use the raidal menu options.
If you want to examine it, either use the radial menu, or click on it.
If you click on it and there are other 'enhanced' examinations or interactions available (via script, obviously), then, and only then, will a 'conversation' possibly occur, although floating text would be acceptable for non-interactive feedbacks.

What I REALLY want (and can't have) is a radial menu I can just add buttons to for the extended functionality, and ditch the conversation for all the enhanced examinations (listen at door, feel door, etc) and some interactions (knock on door).

I have considered putting some sort of door-bell / -knocker on civilized doors, but that only begins to scratch the surface.
               
               

               
            

[Legacy_henesua]

               Some possibilities:
If you use a chat command system like AID, you can provide hooks into those functions you describe via chat commands. You'd have to code new keywords into AID but its not very hard to do so.

If you have particular objects/tools that enable some of the functions you describe you can either create them as items or feats depending on which is more appropriate. Some examples follow:

   An active listening ability for example could be a feat which when used asks for a target. If the player clicks on a door, then the "listen at door" part of that ability would proceed, perhaps responding to data stored on the door.

   Feats can be given to every class automatically and then added to the class menu. I did so with a few generic OOC functions and tied them into a "Player Tools" submenu of the class abilities, things like the DMFI dicebag, Emotes etc... I also created a few new abilities that go into that menu representing in character actions - actions like converting another character to your religion, teaching certain abilities, jumping etc....

   Door spikes, crowbars, lockpicks etc.... can be items you create that open up certain options with doors as well. I did something similar with rope. Rope is a tag based item that the player uses and then selects a target. If the player selects a hole it enables the player to climb down safely into the hole. At a second story window or move skill climb point it does something similar. And I can continue to add different kinds of behaviors depending on what kind of object was selected by the player. The interface for the player however is fairly consistent.


Anyway... those are some ideas.
               
               

               
            

[Legacy_Leurnid]

               

henesua wrote...

Some possibilities:
If you use a chat command system like AID, you can provide hooks into those functions you describe via chat commands. You'd have to code new keywords into AID but its not very hard to do so.

If you have particular objects/tools that enable some of the functions you describe you can either create them as items or feats depending on which is more appropriate. Some examples follow:

   An active listening ability for example could be a feat which when used asks for a target. If the player clicks on a door, then the "listen at door" part of that ability would proceed, perhaps responding to data stored on the door.

   Feats can be given to every class automatically and then added to the class menu. I did so with a few generic OOC functions and tied them into a "Player Tools" submenu of the class abilities, things like the DMFI dicebag, Emotes etc... I also created a few new abilities that go into that menu representing in character actions - actions like converting another character to your religion, teaching certain abilities, jumping etc....

   Door spikes, crowbars, lockpicks etc.... can be items you create that open up certain options with doors as well. I did something similar with rope. Rope is a tag based item that the player uses and then selects a target. If the player selects a hole it enables the player to climb down safely into the hole. At a second story window or move skill climb point it does something similar. And I can continue to add different kinds of behaviors depending on what kind of object was selected by the player. The interface for the player however is fairly consistent.


Anyway... those are some ideas.

Great minds think alike!  Except your mind is faster than mine with far more complete solutions...

I was just coming back from NWN Nexus where I saw AID, had a thought, and came here to ask about using a widget like the various Emote-wands many PW's supply to characters, except load it with actions and checks. I was first thinking that the emote wand could just trip the AIM system, then it seemed it might be smoother to just skip the middle man and instead of having the widget talk to AIM, just have the widget interact with the features directly.

I will have to do a bit more research on that and see if I can cobble it together.  Thanks for those great suggestions!