IssuePointOrder, IssuePointOrderById Bug

10-19-2009, 11:20 PM

I've been updating my LastOrder library today and ran into an incredibly wonky bug that really makes no sense, but caused me hours of pain in trying to decipher.

Bug

The gist of the bug is that the boolean return for the IssuePointOrder and IssuePointOrderById natives is always false for "smart" (851971) orders, even if the order is successfully given.

The fix is to not use the boolean return of those natives, but to instead do the following:
JASS:
    call IssuePointOrderById(u, 851971, x, y)
    return GetUnitCurrentOrder(u) == 851971

I wanted to make a thread about this so it'll show up in searches if others seem to have strange bugs in their order handling systems that pop up as a result of this. If you want a testmap for this, you can view the testmap in the LastOrder thread and modify it slightly to not adjust for the bug, then you'll notice strange stuff start to happen. (I mark in the code where I fixed it)

10-20-2009, 02:12 PM	#2
Anachron	Why that? Is it because of smart orders acting like multiple orders? So actually can it be that the function is like this? JASS: function OrderSmart takes unit u, real x, real y returns boolean call IssueSmart(u, x, y) return GetUnitOrder(u) == "ORDER_MOVE" and GetUnitOrder(u) == "ORDER_ATTACK" endfunction

10-20-2009, 02:39 PM

Rising_Dusk

No, see, this bug is only with point smart orders, not target smart orders. That means that you didn't issue smart on a unit, so it will only ever translate to the move order (and it doesn't actually, that's just what the smart order does when targeting a point). This means that issuing smart orders with the target native returns properly. And also, when you issue a smart order, a move order doesn't tag along. You issue a smart order, so the unit's current order is smart, not move.

Remember that the bug here is with the boolean return on IssuePointOrder and IssuePointOrderById with the smart order, not GetUnitCurrentOrder. If you do what I listed in the first post, it will adjust for the problem.

Quote:

Originally Posted by Anachron

Why that?

You tell me why any bug exists in WC3. It generally is because Blizzard sucks.

10-20-2009, 02:41 PM

Anachron

Quote:

Remember that the bug here is with the boolean return on IssuePointOrder and IssuePointOrderById with the smart order, not GetUnitCurrentOrder. If you do what I listed in the first post, it will adjust for the problem.

I see. Thanks again for clearing things up. You help me a lot.

10-20-2009, 02:50 PM	#5
Rising_Dusk	No problem. These bugs really are lame, so having them show up when you search for them saves other people the hours it took me to figure out where the root of the problem was.

10-20-2009, 03:37 PM	#6
Anitarf	Unfortunately, your workaround might not work completely: if the order fails, but the unit's current order already is smart, then the correction will think that the order went through when in fact it didn't. Then again, I'm not sure if a point smart order could ever fail in the first place.

10-20-2009, 06:25 PM	#7
Rising_Dusk	Grim and I discussed this. For almost all cases, the workaround is great and is fine. Heck, you could probably even always return true and get away with it in most cases. The only times it should return false is if your unit can't move. (For a point order, anyways) Not sure what else can be done about it, though.

10-20-2009, 06:33 PM	#8
Captain Griffen	Question: In the cases where it can fail, can it even have a smart order to start with? If yes, couldn't you just issue stop order and, if it fails, re-issue the order it had before?

10-20-2009, 06:43 PM

Rising_Dusk

Quote:

Originally Posted by Captain Griffen

Question: In the cases where it can fail, can it even have a smart order to start with?

Nope, I suspect it couldn't. Can't think of a case where it could, actually. Guess you may as well just force return true no matter what. If you remove the 'Amov' ability right before issuing a smart order, the unit loses the smart order* before the new smart order is issued.

*I haven't actually tested this, but it would make sense. (Not a good measure for Blizzard things)

10-21-2009, 07:37 AM

#10

Anachron

And what about paused units? Are they able to move?
Because theoretically, as long as they are not stunned or stuff like that, they could move as soon as they are unpaused again.

And some interesting things would also be:
Do other order have return bugs?
Is there any good use of them?

And what about a small wait time between an stop order and a new issue point order? I mean something about 0.01, so its unnoticeable.

It may result the same, but still a good thing to look for.