Disabling basic AI functionality

01-30-2006, 07:04 PM	#1
Panto	Greetings. For certain reasons, I'd like to prevent a slot that's been filled by a computer player from performing even the most basic AI functions, like returning to its guard position. Using the AI action to make each unit ignore its guard position is inadequate because it stops whatever the unit may be doing when the action is issued. Thanks for any help you can provide.

01-30-2006, 07:36 PM	#2
Vexorian	Make neutral use the slot instead of computer?

01-31-2006, 05:01 AM	#3
Panto	It's meant to replace a player. Any of the player slots can be filled with a computer, but the blasted Guard Position is a serious setback to being able to actually play with that player as an ally.

01-31-2006, 05:40 AM	#4
Extrarius	Have you tried using the Jass function RemoveGuardPosition and/or RemoveAllGuardPositions ? I believe the latter just calls the former on all units currently owned by the relevant player, so if you make new units you might need to remove their guard position also.

01-31-2006, 06:50 AM

Panto

Actually, yes.

Quote:

Originally Posted by Panto

Using the AI action to make each unit ignore its guard position is inadequate because it stops whatever the unit may be doing when the action is issued.

But thanks; maybe if I look into the common.j there will be some related function that doesn't override unit orders somehow.

And I looked, but did not find. This is the contents of common.j which contains the function to ignore guard position:

JASS:

//============================================================================
// Computer AI interface
//
native StartMeleeAI         takes player num, string script                 returns nothing
native StartCampaignAI      takes player num, string script                 returns nothing
native CommandAI            takes player num, integer command, integer data returns nothing
native PauseCompAI          takes player p,   boolean pause                 returns nothing
native GetAIDifficulty      takes player num                                returns aidifficulty

native RemoveGuardPosition  takes unit hUnit                                returns nothing
native RecycleGuardPosition takes unit hUnit                                returns nothing
native RemoveAllGuardPositions takes player num                             returns nothing

//============================================================================

PauseCompAI is the only one that looked fruitful to me, but setting a player number to "false", no matter what else it may have done, did not prevent it from recognizing the guard position, so evidently there's no lovin' to be had from this.

However, I don't know a darn thing about AI. I hope someone does, and has a suggestion. Anything would be great.

01-31-2006, 07:26 AM

Anitarf

Quote:

Originally Posted by Panto

Using the AI action to make each unit ignore its guard position is inadequate because it stops whatever the unit may be doing when the action is issued.

Can't you just make the unit ignore it's guard position at map initialization or whenever the unit is created? At the time, it shouldn't yet have any orders.

01-31-2006, 12:11 PM	#7
Blade.dk	I think the computer AI is supposed to take over when the player leaves, and therefore it becomes a problem.

01-31-2006, 01:32 PM	#8
Vexorian	nope, when a player leaves no matter if you set the controller of the player to MAP_CONTROL_COMPUTER the computer ai will not do anything. I think that the return to guard place is actually an order, what if you detect that order and reorder the unit correcty?

01-31-2006, 04:14 PM

Panto

Quote:

Originally Posted by Anitarf

Can't you just make the unit ignore it's guard position at map initialization or whenever the unit is created? At the time, it shouldn't yet have any orders.

Actually, as soon as the unit is created it follows the rally point. If it is told to lose its guard position, it stops without following it.

If returning to the guard position is an order, I could issue the command to lose the guard position at that time, which would be ideal. I'll test; thanks Vex!

01-31-2006, 09:48 PM

#10

Panto

It seems to be more complex. A unit will only try to revert to its guard position if the place that it's rallied on is occupied by something else when it gets there. It has an interesting set of orders.

First it spews out 6 orders when it's spawned by the Factory ability. Half of them are "stop" and half are nothing; how awesome is that!

Once it gets to the general area of its rally, if it can't go there, it gets two orders and returns.

I'm not sure what these orders mean, nor what to do about a null order.

At any rate, here's the trigger I used to gather the debug:

Trigger:

Issued order

Events

Unit - A unit Is issued an order targeting an object

Unit - A unit Is issued an order targeting a point

Unit - A unit Is issued an order with no target

Conditions

Actions

If (All Conditions are True) then do (Then Actions) else do (Else Actions)

If - Conditions

(Owner of (Ordered unit)) Equal to Player 12 (Brown)

(Unit-type of (Ordered unit)) Not equal to Barracks

Then - Actions

Game - Display to (All players) for 5.00 seconds the text: (Ordered: + (String((Issued order))))

Else - Actions

The test map has been attached to this post for reference. I don't know where to go from here; any insight is greatly beloved!

Attached Images

	out.jpg (132.8 KB)
	back.jpg (133.2 KB)

Attached Files

GuardPositionOrderTest.w3x (24.2 KB)

01-31-2006, 10:29 PM	#11
Vexorian	you should use BJDebugMsg(I2S(GetIssuedOrderId())) instead. Most likelly those orders don't have orderstrings

02-01-2006, 12:29 AM

#12

Starcraftfreak

My standard setup for debugging maps is this one:

Trigger:

Order

Events

Unit - A unit Is issued an order targeting a point

Unit - A unit Is issued an order targeting an object

Unit - A unit Is issued an order with no target

Conditions

Actions

Custom script: call DisplayTextToPlayer(Player(0),0,0, OrderId2String(GetIssuedOrderId()) + " = " + I2S(GetIssuedOrderId()))

This way its easy to see which orders have orderstrings and which dont. I also made an order-browser multiboard once, where i can browse through all the ids and strings with up- and down-key.

02-01-2006, 04:14 AM

#13

Panto

EDIT: Got a more informative debug and ran a test. Results:

This is just a unit spawning, no rally order:

Here's the unit spawning and rallying out to a single destination:

Here's the unit spawning, rallying out, and returning to guard position:

Judging by the timing, it looks like "attack" is the critical point. So, how does one stop a unit from attacking, only when it's issued by the guard position mechanic?

851970 and "attack" are the only two orders with targets (points) the other ones are no-target orders.

Attached Images

	1stay.jpg (72.4 KB)
	2out.jpg (74.3 KB)
	3back.jpg (76.7 KB)

02-01-2006, 07:24 AM	#14
Anitarf	Could you not just ignore guard position when the unit spawns and then manually order it to move to rally point? Surely there's a function that gives you the rally location of a building?

02-01-2006, 07:33 AM

#15

Panto

That was the previous solution. However, there are gaping flaws in the older triggers that I have which do just that, mostly revolving around players setting allied players' rally points and queued rally point positions. More foolproof triggers would require substantial work and would still never be as trustworthy as using Blizzard's hardcoded rally point system. It is because of this that I'm pursuing using that system despite the obstacles.