[JASS] GetUnitX, GetUnitY inaccuracy

[Retera]

When I call GetUnitX and GetUnitY on a unit, they are returning the X and Y of the unit +16 rather than its true coordinate, but only when the unit in question has collision size >= 16 and is not UNIT_TYPE_STRUCTURE. However, as we cannot query the unit's collision size in JASS, this would seem to suggest that there is no way to accurately determine the coordinates of a unit.

That seems absurdly stupid to me. How do I accurately determine the coordinates of a unit in JASS (or vJASS)? Has anyone decompiled game.dll and built a special one for mods, where we can accurately determine the coordinates of a unit maybe?

I just feel like I'm missing something, I was never aware that this was an issue before, I had put my faith in GetUnitX and GetUnitY.

 

[edo494]

as mentioned in another thread, decompiling game.dll is against the ToS and you can get sued if you do so.

The unit's coordiantes is always where its center of collision is, there shouldnt be any major inaccuracy(note: major being bigger than .1)

Buildings have collision maps, so their positions arent exactly in the center

 

[PurgeandFire]

are you sure GetUnitX/GetUnitY is inaccurate? How do you know it is 16 coordinates off?

If you need to factor collision size into your spells, use the IsUnitInRange() functions:

constant native IsUnitInRange       takes unit whichUnit, unit otherUnit, real distance returns boolean
constant native IsUnitInRangeXY     takes unit whichUnit, real x, real y, real distance returns boolean
constant native IsUnitInRangeLoc    takes unit whichUnit, location whichLocation, real distance returns boolean

 

[rulerofiron99]

You could save each unit type's collision size in a hashtable at map init and just fetch it when needed.

 

[Bribe]

The best way to check this is to use GetUnitLoc and GetLocationX/Y vs GetUnitX/Y

 

[Wietlol]

    set u = CreateUnit(GetTriggerPlayer(), 'hfoo', 11.11, 22.22, 0)
    call BJDebugMsg("Unit location = (" + R2S(GetUnitX(u)) + ", " + R2S(GetUnitY(u)) + ")")
    
    call SetUnitX(u, 33.33)
    call SetUnitY(u, 99.99)
    call BJDebugMsg("Unit location = (" + R2S(GetUnitX(u)) + ", " + R2S(GetUnitY(u)) + ")")
    
    call SetUnitPosition(u, 45.45, 54.54)
    call BJDebugMsg("Unit location = (" + R2S(GetUnitX(u)) + ", " + R2S(GetUnitY(u)) + ")")
    
    call SetUnitPositionLoc(u, Location(66.66, 77.77))
    call BJDebugMsg("Unit location = (" + R2S(GetUnitX(u)) + ", " + R2S(GetUnitY(u)) + ")")

Results:
"Unit location = (11.000, 22.000)"
"Unit location = (33.330, 99.990)"
"Unit location = (45.450, 54.540)"
"Unit location = (66.660, 77.770)"

CreateUnit() is inaccurate to round numbers.

SetUnitX()/SetUnitY(), SetUnitPosition(), SetUnitPositionLoc(), GetUnitX()/GetUnitY() are accurate enough to make everything work.

results made with unit collision size 0, 31 and 1024(default max)

From my tests... R2SW() is inaccurate... serious inaccurate.

 

[Spellbound]

Apparently if you collision is 16, moving your unit will cause it to go off-center. I was trying to center a crypt field in a circle of power and it would only center correctly when it's collision was 32 or 8.

I tested various collision sizes (up to 128) and it seems as though 16, 24 and 48+ are all off-center values. The other multiples of 8 up to 48 seem to center correctly.

 

[Bribe]

SpellBound, are you using the GUI "Unit - Move Instantly" method? You can use SetUnitX/SetUnitY in JASS to circumvent that.

 

[Spellbound]

I tested using SetUnitX/Y, not the GUI move. Or did you mean convert the entire trigger to custom script?

 

[Bribe]

No, just that. Very weird that it didn't work properly. You only convert the whole trigger if you want to code everything manually.

 

[Wietlol]

@Spellbound
Can you post the map with the inaccuracy being displayed when I test it?
I cant seem to recreate the scenario as you described.

 

[Spellbound]

Well It's a sandbox testing grounds thing. I'll PM it to you (or smthing).

 

[Wietlol]

The SetUnitX() and SetUnitY() are not the problem as its location is exactly the same as the target.
However the unit does get a little offset.

Why? I dont know, but setting collision to 15.99 does solve it.

 

[Spellbound]

Anything below 16 seems to work. Anything from 16 to 24 doesn't. Also, I'm not entire sure how collision works, but doesn't it work only with multiples of 8? As in, wouldn't a collision of 15.99 or 12 or 9.99 have the same collision as though it was set to 8?

 

[Bribe]

What if you turn off unit collision via triggers before moving it?

 

[Spellbound]

What if you turn off unit collision via triggers before moving it?

I did. Kind of a habit I have.

 

[Dr Super Good]

It likely returns the mechanical origin of the unit hence it should be the accurate position of the unit. Searching an area which contains that position will (should) return the unit.

I think the problem here is you do not care where the unit is, but rather where the centre of the unit actor is. This has nothing to do with the mechanical position of the unit.

So why is the unit offset? I agree it does not make much sense but could possibly come from how stuff was done in a 2D situation such as SC1 or WC2. There unit art position would likely be the lower left corner (or some other corner) since they were sprites. They probably adapted that into 3D with WC3 so that the unit is located at some sort of corner and then both its actor and collision are offset by some amount. The reason it relates so poorly to collision size could be some sort of correction they added to make collision size less relevant or that the origin is vaguely near the unit centre for large collision units.

I agree that it is kind of stupid but you must remember WC3 was a game that sort of came about rather than was designed so (like SC2 was). Origin should be the centre since that is the most natural and logical position for it to be but that does not mean it has to be.

 

[Bribe]

DSG, one would think that, with units' X and Y being set, that the Get functions would coincide. I think something else is the matter here.