LastOrder

[Rising_Dusk]

I can't really explain that. It must be something weird inside of AutoIndex. I'll look into it and see what I can dig up, though.

[Sinnergy]

hmm...no No Store updated version? I just replaced the requires UnitIndexingUtils to AutoIndex, does work fine?

[Sinnergy]

BUMP
Why not update the No Store version of Last Order? because it really cause bugs with AutoIndex, the No Store Version works better than LastOrder system with AutoIndex combined

[Rising_Dusk]

I really need to figure out why it doesn't work with AutoIndex, because AutoIndex should function nigh-on identically to UIU.

EDIT:
I have decided that if this library has some problem with AutoIndex, then it is AutoIndex's fault. Can you possibly elaborate upon the type of bugs you see? I am almost certain that it means that AutoIndex is not giving correct indexes where it should.

[Sinnergy]

any method to do such thing like this?:

JASS:

call IssueOrderIdEx(GetLastOrderId(GetTriggerUnit()), thisUnit)

I'm trying to figure out that if I want to order a unit using the returned order from a unit, it really need a lots of function calls, since I need to check what kind of order did the unit is issued (instant, target, point), then order the unit to use the order instant, or target, or point.

Lets say a hero (GetTriggerUnit()) issues an order to attack a certain target, then if I want to make a unit (thisUnit) follow the issued order of that hero (so that they would be identical), then I would use the function above, now, there's no need to check what type of order did the hero used, no matter what type of order did the hero is issued, the unit will always try to issue the hero's order

[Archmage Owenalacaster]

Originally Posted by Rising_Dusk

Can you possibly elaborate upon the type of bugs you see?

I'll do you one better. I've attached a version of your testmap fitted to use AutoIndex.
Try using Demo Spell Error.

[ToukoAozaki]

It seems that defend ability messes up with AbortOrder and LastOrder combination.

[Rising_Dusk]

Originally Posted by Sinnergy

Lets say a hero (GetTriggerUnit()) issues an order to attack a certain target, then if I want to make a unit (thisUnit) follow the issued order of that hero (so that they would be identical), then I would use the function above, now, there's no need to check what type of order did the hero used, no matter what type of order did the hero is issued, the unit will always try to issue the hero's order

It's a quick wrapper function call I could add to the system. Heck, you could write it yourself as you described in ten seconds. I like the suggestion, though, so I suppose I will add that in the next version.

Originally Posted by ToukoAozaki

It seems that defend ability messes up with AbortOrder and LastOrder combination.

I was suspecting this as well. I'm not sure why it would cause issues, but I suppose I will have to investigate.

[Sinnergy]

I really can't take the bug anymore, it makes me want to use UIU for last order instead of AutoIndex, I just don't know if two indexing system works in 1 map?

[Rising_Dusk]

They won't. It's one or the other; if you have both your map won't even compile. I really don't know what to tell you about the whole bug, since it is because of the defend orders your units get when using AutoIndex. You could add an exception to LastOrder to ignore 'defend' orders, but that shouldn't be in the submitted library, rather in your copy of it.

[Sinnergy]

ok2x, let me just think a way to exclude 'defend' in last order, I even don't know what part of last order should I implement that.

edit:
wait, you already excluded an order id used by autoindex which is the 'undefend' order id (852056) in here:
(id >= 852055 and id <= 852762)

[Rising_Dusk]

The function is called OrderExclusions, but if it returns true then an order is not excluded. 'defend' is 852055 and 'undefend' is 852056. You would need to change that last segment to: (id >= 852057 and id <= 852762)

[Sinnergy]

ok. I thought the returned order id's are the ones that are not included, so that means I must not create abilities based on defend right?

[Rising_Dusk]

Well, it means that LastOrder will ignore any defend or undefend orders as if they do not exist. So if for some reason you do want IssueLastOrder() to issue your last defend order (Doubt you ever would), then it would pretend as though the original defend order were never issued in the first place.

[Sinnergy]

I can't think of any usage for defend ability, I even don't base my spells with the defend ability, so I'm 100% sure that I won't use defend ability (except for a requirement like AutoIndex)