• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

[General] Detect if player issued an order

Status
Not open for further replies.
Level 1
Joined
Apr 8, 2020
Messages
110
That will not work because even triggered orders are detected by issue order events. Besides, triggering player is simply the owner of the unit being issued an order, not the player issuing an order.

I am trying to achieve an priority system for orders in the following scheme:

Implementing a way to seperate in-system orders from user- or trigger-issued orders; preferrably a priority system; this way, you can basicly have a "basic" AI even on user-controlled units (like autocasting certain spells) without it interferring with user-issued orders; an ideal priority system needs at least 3 layers:

low priority
) takes precedence only over "idle" state of units; but has lower priority than user-issued orders (i.e. auto-cast of spells) ... all AI-issued orders should go into this layer by default.

user priority) takes precedence over low priority orders; user-issued orders (or triggered orders outside of programs) should go into this layer by default. If a user priority order is in place, low priority orders will not be issued.

top priority
) takes precedence over user-priority orders; this is useful for example if you want to code a confusion or mind-control AI; or a morale system for units or anything that makes the user lose control over the unit.
 

Wrda

Spell Reviewer
Level 25
Joined
Nov 18, 2012
Messages
1,864
That will not work because even triggered orders are detected by issue order events. Besides, triggering player is simply the owner of the unit being issued an order, not the player issuing an order.
That's precisely why there must be a boolean.
What I actually meant was, you always know when you want to trigger orders, so before issuing the order you set the boolean "TriggeredOrder" to true, then issue it, and then set it to false. On the 2nd trigger you'll have the event of the unit being issued an order with the condition "TriggeredOrder equal to false" then you know it was the player who issued the order.
Triggering Player can be used for player unit events, but in this case you'll use TriggeredOrder[Player Number of (Owner of Unit blablabla)]
 
Level 8
Joined
Mar 19, 2017
Messages
248
Besides, triggering player is simply the owner of the unit being issued an order, not the player issuing an order.

At least on selection events registered unit by unit (and not player by player), you can get the actual selecting player by using GetLocalPlayer. Just dropping this so you can test it yourself on your particular problem.
 
Status
Not open for further replies.
Top