9 réponses à ce sujet

[Kilrogg_]

I'm trying to use this event to queue up certain things I want an NPC to do (use Dirty Fighting to stun the player and proceed to run to a location) since WR_AddCommand doesn't seem to actually queue up anything (it'll just execute the last command in the list that I give).

That said, EVENT_TYPE_COMMAND_COMPLETE does not seem to fire at all. Same for EVENT_TYPE_COMMAND_PENDING. My code is working fine since if I replace that event with EVENT_TYPE_ATTACKED, the code fires successfully.

The creature this script is on is a boss character in my standalone module.

Is there something I'm missing?

[_L_o_B_o_]

Kilrogg_ wrote...
since WR_AddCommand doesn't seem to actually queue up anything (it'll just execute the last command in the list that I give).

I had the same problem trying to put 2 play animation commands in queue. I had to add them as static commands in order to get it. I would like to understand better how the command queue works... 

[Kilrogg_]

Well I added them as static commands using AddCommand instead of WR_AddCommand and yeah its a lot more simple lol. Works just like I wanted it to.



Thanks.

[Craig Graff]

A few quick notes:
EVENT_TYPE_COMMAND_COMPLETE and EVENT_TYPE_COMMAND_PENDING are routed to rules_core.nss in events.xls.
To work with the queue outside of combat use EVENT_TYPE_CUSTOM_COMMAND_COMPLETE in your creature script. Use EVENT_TYPE_HANDLE_CUSTOM_AI inside of combat and set local variable AI_CUSTOM_AI_ACTIVE to a positive number in either case.
To stack a command queue use COMMAND_ADDBEHAVIOR_DONTCLEAR as the nOverrideAddBehavior parameter in AddCommand or WR_AddCommand.

Modifié par Craig Graff, 27 juin 2010 - 08:59 .

[_L_o_B_o_]

Craig Graff wrote...

A few quick notes:

Ohhh, mistery solved. Thank you :happy:

[Nattfodd]

Just a doubt while i was reading your posts: you talked about static commands added using AddCommand instead of WR_AddCommand, what is the difference?

@Craig: do you know if the following events could be intercepted in scripts:

EVENT_TYPE_ON_ORDER_RECEIVED
EVENT_TYPE_BEGIN_TRAVEL
EVENT_TYPE_PLAYER_COMMAND_ADDED
EVENT_TYPE_USE_ABILITY_IMMEDIATE
all the EVENT_TYPE_TRAINING_* events

Modifié par Nattfodd, 28 juin 2010 - 02:19 .

[Kilrogg_]

Using AddCommand you can specify whether its a static command or not. I don't know the exact details, but it seems to actually queue up commands instead of replacing the current command.



So basically you can give 2-3 static commands in the same script, and they'll be performed one after the other in the order they were listed in the script.

[Nattfodd]

So if you do not specific that it is a static commad the command will be executed before of others commands in queue?

[Craig Graff]

The only reason for a modder to use WR_AddCommand instead of AddCommand is to add a command timeout. Everything else it is used for internally other than some logic filtering is commented out in the released version of wrappers_h.nss or otherwise disabled (it was basically all logging anyhow). You can use either to specify a static command or the add behavior of the command, but I'd recommend using AddCommand as long as you are making sure the command is valid and the creature you are assigning it to is valid. (Making your own wrapper function for this would be a good idea.)

I believe the default behavior for AddCommand is to add the command to the end of the queue, but replace the first command of the same type if one exists.

Say you have the following queue:

• Move to location A
• Wait 5.0 seconds

and you want to add another movement command (Move to location . WIth the default AddBehavior of AddCommand your new queue would be

• Move to location B
• Wait 5.0 seconds

However, if you set the nOverrideAddBehavior parameter to COMMAND_ADDBEHAVIOR_DONTCLEAR then you can queue up commands of the same type. So if you add Move to location B to the original queue with this parameter you would have

• Move to location A
• Wait 5.0 seconds
• Move to location B

Static commands allow this without overriding the AddBehavior but should be used carefully, since they generally can't be removed from the queue once added.

Modifié par Craig Graff, 01 juillet 2010 - 05:21 .

[Nattfodd]

Thanks for the reply. About the events i listed before, can you explain something? Can them be handled in scripts?