Standing up? Crouch? Prone? check with mando_getpos.sqf (ACCEPTED)

[Mandoble]

Topic says more than enough 

EDIT:
Forgot to say, of course this method does not check any animation phase 

[Blanco]

Brilliant again 

[Mr.Peanut]

Mando,
Where did you get any good info on the intersect command? I just searched the Biki and the BI Forum and came up empty handed. In particular, is there a list of LOD's that can be used with this command?

edit: you should post a link back to this thread on the BI Forums. This script of yours is the ArmA answer to one of the longest running forum discussions for OFP.

edit2:your looping condition should be changed to:

Code: [Select]

for [{_i = 0},{_i < 3 && _found ==  -1},{_i = _i + 1}] do

[Mandoble]

This is all the info I had about intersect command:

Intersect

And this is all the info I know about LODs:

LODs

Looking at the ArmA error file I figured out only GEO LODs were valid for intersect, as I got thousands of not valid geometry LOD errors before ending with only VIEW and FIRE (errorless). But I'm in no way any expert about models, lods and anyother arcane modeling terminology (like named selections and anti-intuitive things like that).

[Mr.Peanut]

I know nothing about them either, and don't want to, but the usefulness of the intersect with "FIRE" and "VIEW" makes it important. Why did you use the "FIRE" LOD instead of the "VIEW"?
(Please note suggested code change in edit to my previous post)

[Mandoble]

With a 3 iteration loop adding the "&& _found ==  -1" check is not really needed, while it is indeed more elegant 

With VIEW LOD I got positive results only for vehicles with turrets, for example the turret of a tank (and only with lines intersecting these turrets), nothing else did work. Just the opposite with soldiers, no intersections detected with VIEW, but all and every named selections were returned with FIRE: head, spine, chest, left leg, right arm, etc. You may create a virtual bullet and intersect command will tell you the left eye of the soldier was hit 

With static structures like a Tent, VIEW and FIRE have the same result, no intersectio detected.

[ManDay]

> [...] Looking at the ArmA error file [...]

As I experienced serious problems getting the intersect-command to work, so I am intrested in hearing where I can find that dubious error-file. Furthermore I wish to be told where the LOD-Ident.'s come from - i.e.: where those are defined.

[Mandoble]

arma.RPT file.

[ManDay]

Thank you. Do you know a way to put that to the screen - so I don't have to look it up within this file each time but rather get the output while testing?

[Mandoble]

AFAIK, there is no way to do that.

[ManDay]

Okay. Here I made a optimized version of your script - thought you may care - I only achieved because you showed us how to make use of the right LODs.

Code: [Select]

_obj_obj = player;
while{ true }do
{
_pos_obj = getPos _obj_obj;
_v__mix_intersect = [ _obj_obj,"FIRE" ]intersect[ _pos_obj,[ _pos_obj  select 0,_pos_obj select 1,10 ] ];
_float_spinePos = -1;
_int_i = -1;
while{ _int_i <( count _v__mix_intersect ) && _float_spinePos == -1 }do
{
_int_i = _int_i + 1;
if( ( ( _v__mix_intersect select _int_i )select 0 )=="spine2" )then
{
_float_spinePos =( _v__mix_intersect select _int_i )select 1;
};
};
hint format[ "%1",_float_spinePos ];
sleep 0.1;
};
This one let you also consider "unitPos"s like the one where you have the gun pointing down (green-CM) - because the value goes to >0.9 then

[Mandoble]

Intersting idea, please add coments there so it is clear the purpose of the change for everyone.

[ColonelSandersLite]

Ok, I've been looking at the code here, and while I haven't tested it explicitly, it looks like this may have problems with addon units?

The reason for this is that it is dependent of the model to at least some degree.  Especially manday's code is dependent on the spine, which may not actually be what's expected in a 3rd party addon.

I think that's right, and I was just wanting confirmation of the concept that it may need adjusting dependent on the specific model that it's being run on.

[Mandoble]

it looks like this may have problems with addon units?

why?

[ColonelSandersLite]

Unless I'm greatly mistaken (and I may be since I know very little about models, hence the question here), the script depends on a floating point return value from the model.  If the model isn't done the same as the BIS stuff, it may return a totally different set of numbers, maybe even just junk.

I'm not doubting that it works OK with BIS units themselves since they're most likely done relatively consistently.  But if you go throwing it at an addon unit, you can't actually predict what numbers it will return.

If I'm incorrect, then please say so, without a doubt.