'setPos' is not accurate...?

[CptBBQ 10]

Hi all!

I guess this should be already a known issue but I couldn´t find anything about it in the forum. So just to be sure...

After experiencing some strange behavior in one of my scripts I did some debugging. Amongst a lot of other things I ran this line on a number of different objects:

_target setPos getPos _target;

As I understand it this line should not produce any observable results, but actually all of the tested objects changed their positions. The particular offset seems to depend on on the object type.

E.g. an AA Pod moves backwards a few meters with each iteration while 'Fort_Barracks_USMC' sink into the ground and others are lifted into the air.

Then, I wanted to know if the position is read incorrectly or set incorrectly.

_target = cursorTarget;
_pos = getPos _target;
_target setPos _pos;
hintSilent format ["%1 ### %2", _pos, getPos _target];

The two positions returned differ from each other. That means 'getPos' determines the precise position and then the object is 'setPos'ed to a proximate position with a constant offset to the actual position.

This raises a few questions for me..

First of all: are my conclusions correct? ^^

But also: am I the only one who´s bugged by this? Has anyone found a workaround? Is this regarded a bug? And if so, is it already reported?

Yes, there are probably very few situations in which this issue should become problematic - but I´m currently in one of those situations so any feedback is appreciated.

Thanks for reading, even more for answering ;)

Cheers,

bbq

[shuko 59]

Well, I think setpos is more of a "engine, please, could you try to put that guy over there" instead of directly having control of the object.

What exactly are you doing that gets ruined by this "feature"?

Have you tried if setposasl has same effect?

[CptBBQ 10]

Using setPosASL actually reduces the offset for most objects. That´s already a great help. Thank you, shk.

Well, what I´m trying to do (or already did) is not actually ruined by this 'bug' but it was a medium annoyance (now degraded to minor annoyance^^)

I made a script that allows players to build a small outpost with sandbags and static weapons (like in warfare but much simpler). I recently expanded the script to be able to 'copyToClipboard' the type, position and direction for each fortification, static weapon and so on.

The information is stored as executable code which can be pasted and called again in a later mission.

It actually works pretty fine but I noticed that some objects (especially static weapons) aren´t placed correctly.

I think I can live with it as it is now. But still, if anyone knows how to place objects really really precisely, I´d be more than interested.

[UNN 0]

As I understand it this line should not produce any observable results, but actually all of the tested objects changed their positions.

It's a problem with the engine and certain objects, it's been around for ages. IIRC it's down to autocentre and how the object is positioned in O2.

You could try posting a bug report on Dev Heaven, but don't hold your breath. When you look at how many bugs are posted up there and who is actually being assigned to fix them, it doesn't take a genius to work out the probabilities :(

[.kju 3245]

In the CIT assigned to someone or not means little UNN.

Also we recently checked the stats:

1464 open and 579 confirmed fixes/additions for the CIT (later is closed + target assigned).

Means CTD fixed and closed not counted (have no target assigned) - overall ~1500 closed.

Edited February 27, 2011 by .kju [PvPscene]

[faguss 65]

So I've read this and I'm like "they haven't fixed this since OFP? Mein Gott!" but then I've ran the game and noticed that only a couple of objects are affected.

Anyway. Here's the code I'm using to fix position:

_obj setPos [_x, _y, _z]

	_fixX = (getpos _obj select 0) - _x
	_fixY = (getpos _obj select 1) - _y

_obj setPos [(_x - _fixX), (_y - _fixY), _z]

setPos and getPos are innacurate. Don't trust them.

[UNN 0]

Thanks for the err numbers. I'm not disputing they are being closed or fixed. Indeed CTD's have always traditionally taken priority and even if only one person is actually assigned to fixing CTD's, it's better than nobody.

But as this particular issues doesn't cause a CTD, then perhaps you can offer up a probability of it being fixed?

@Faguss

Yeah, if you know what objects you want to use then you can hard code a fix, been doing that since OFP.

Edited February 27, 2011 by UNN

[CptBBQ 10]

Heh, at least I´m not the only one concerned with this^^

Maybe it´ll get fixed sometime, until then I´ll use Faguss´ workaround.

Thanks for all the info guys!

[neokika 62]

Hey CptBBQ,

Well, I dont think its a setPos issue at all. Each object has its center, but for example, between 2 different static MGs the center canbe/will be slightly diferent.

_neo_