empty

[jk4t63p4f]

empty

 

[Shar Dundred]

Just have the AI controlled by neutral instead of computer in player settings and you do not have the problem.
You only have to set all alliances (ally, enemy, etc) by using the trigger editor.

This way, the AI not only stops disobeying orders, it also does not just cast spells by itself.

 

[Shar Dundred]

Neutral in player settings, not neutral as in neutral hostile/passive/victim.

 

[Nowow]

No, no not at all! I don't want a dead AI! I just need the AI to obey when you want to intervene with what it's doing, that's all.

That's not going to be as easy as you think. My best idea for how to do this goes like this:

1. Once you send the computer controlled hero a command, store the order id and the target location\unit whatever.
2. Start a timer for X seconds, during which, if the hero receives an order, send the order you stored again.
3. Once the timer stops/target has been reached, stop overriding methods received.

This is the basic outline. BUT, and you might want to allow some orders because some might be essential for normal unit action. And there are a lot of things to consider, like: aggro range and recurring orders, orders following your own walk order (might create something akin to an infinite loop), non immediate build and spell orders (including mana/resource refunding in case of order interrupts), and the effect of a stray unit on general AI behavior (might cause captains to act funky).

Sounds like an interesting experiment, and something someone probably tried doing already. I really suggest searching the hive for questions about this. If you want to try my way, go here for more info:

Orders repo

Missions (see mission 1 - order tracking)

 

[Nowow]

Do you know if AIs ever cancel troop training, cancel building constructions, unsummon already finished buildings, cancel research, or cancel upgrades? These might interfere with the AI or player.

Didn't see any of those, except unsummoning building, and even that wasn't automatic.

 

[3dris]

Hmm, maybe you can change the ownership of the unit for 10 second and give back to the original owner after this. Is a posibility...

 

[Nowow]

Why did it unsummon? Did the AI not place it perfectly?

No, you can make your AI unsummon on purpose with the Unsummon native command. This isn't something you should worry about, AI is not supposed to unsummon by mistake.

 

[Pyrogasm]

You probably gave the best answer/idea to this.

Per ABronzeCross's other post:

• Events
  • Unit - A unit is issued an order targeting an object //"object" may not be the correct term
  • Unit - A unit is issued an order targeting a point
  • Unit - A Unit is issued an order with no target
• Conditions
  • (Owner of (Triggering Unit)) not equal to (Triggering Player) //Triggering Player should work here
• Actions
  • Custom script: local unit udg_Change_Unit
  • Custom script: local player udg_Change_Player
  • Set Change_Unit = (Triggering Unit)
  • Set Change_Player = (Owner of (Triggering Unit))
  • Unit - Change owner of Change_Unit to (Triggering Player) without changing color
  • Wait 10.00 game-time seconds
  • Unit - Change owner of Change_Unit to Change_Player without changing color
  • -------- might not need these lines, but my suspicion is you will: --------
  • Custom script: set udg_Change_Unit = null
  • Custom script: set udg_Change_Player = null

 

[Pyrogasm]

Unless Blizzard added a generic "any order" event with the recent patches there isn't such an event. You have to check all kinds of orders.

 

[Nowow]

Per ABronzeCross's other post:

• Events
  • Unit - A unit is issued an order targeting an object //"object" may not be the correct term
  • Unit - A unit is issued an order targeting a point
  • Unit - A Unit is issued an order with no target
• Conditions
  • (Owner of (Triggering Unit)) not equal to (Triggering Player) //Triggering Player should work here
• Actions
  • Custom script: local unit udg_Change_Unit
  • Custom script: local player udg_Change_Player
  • Set Change_Unit = (Triggering Unit)
  • Set Change_Player = (Owner of (Triggering Unit))
  • Unit - Change owner of Change_Unit to (Triggering Player) without changing color
  • Wait 10.00 game-time seconds
  • Unit - Change owner of Change_Unit to Change_Player without changing color
  • -------- might not need these lines, but my suspicion is you will: --------
  • Custom script: set udg_Change_Unit = null
  • Custom script: set udg_Change_Player = null

You can create local variables with udg then refer to them with gui set variable? What sorcery is this?!
I mean it makes sense, global/local modifiers shouldn't matter when assigning variables but that is a neat trick.

 

[Pyrogasm]

Research is no-target, build is point-target, item drop is either point- or object-target (idk). They’re all covered.

You can create local variables with udg then refer to them with gui set variable? What sorcery is this?!
I mean it makes sense, global/local modifiers shouldn't matter when assigning variables but that is a neat trick.

No those variables have to be created in the variable editor. What I did is called local shadowing to make them behave as local variables.

 

[3dris]

You probably gave the best answer/idea to this.

Thanks for it

 

[Nowow]

No those variables have to be created in the variable editor. What I did is called local shadowing to make them behave as local variables.

So this is hiding a global variable with a local variable, same as hiding a static variable in java for example? Does the value assigned to the local variable stick to the global variable, or are they two separate entities?

 

[Pyrogasm]

So this is hiding a global variable with a local variable, same as hiding a static variable in java for example? Does the value assigned to the local variable stick to the global variable, or are they two separate entities?

Yes basically the same thing, but within the scope of the trigger if a global is shadowed only the local 'copy' can be accessed (no way to refer to the global 'copy'). They keep separate values and the shadowed 'copy' can leak if it's a handle so you still need to null it. This trick only works in GUI because you can't re-use a variable name for a global and a local in JASS without throwing an error.

 

[Daffa]

As a C++ coder, I find that unusual.
What if you want it to leak? Will it crash or error?
JASS is strange.

It is strange if you're accustomed to the coding world. GUI is weird in a way.

Leak in JASS would be where the data is inaccessible, yet it still consumes some memory spaces. This result in the map becoming laggier and laggier with more leaks occurring.

 

[Superfrycook]

Does it also worked on Reforged?