OFPEC Forum
Editors Depot - Mission Editing and Scripting => ArmA - Editing/Scripting Resources Beta Testing & Submission => Topic started by: Mandoble on 16 Apr 2007, 21:25:41
-
Topic says more than enough :D
EDIT:
Forgot to say, of course this method does not check any animation phase :P
-
Brilliant again :)
-
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:
for [{_i = 0},{_i < 3 && _found == -1},{_i = _i + 1}] do
-
This is all the info I had about intersect command:
Intersect (http://community.bistudio.com/wiki/intersect)
And this is all the info I know about LODs:
LODs (http://community.bistudio.com/wiki/LOD)
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).
-
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) :)
-
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.
-
> [...] 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.
-
arma.RPT file.
-
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?
-
AFAIK, there is no way to do that.
-
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.
_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
-
Intersting idea, please add coments there so it is clear the purpose of the change for everyone.
-
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.
-
it looks like this may have problems with addon units?
why?
-
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.
-
Yes, you are wrong, the script is not depending on any floating point return value from any model :blink: which floating points returned by any model are you talking about?
-
Oh, I see. This is caused by me mixing your script and manday's scripts together in my head I think.
You're detecting if the model intersects a line at various altitudes, right? Hence the "_alts = [1.4, 1, 0.2];". This still means that gigantous and tiny models (there where some of those for ofp that I just couldn't stop lauging at ever) will bug but in general it's not a big issue for most purposes. Is that understanding correct?
Now, manday's *does* return a floating point indicator of the unit's "spine2". Meaning that if the unit is made differently then the bis units, it's bounds may change to the unexpected. Is that understanding correct?
If both of those are correct understandings, then clearly your method is far superior.
-
Yes, these are altitudes to check. Obviously the script is designed to work with normal human units, but in case you need to check the position of a colosus you may modify them at will.
ManDay uses a different aproach, he checks for the existance of a "spine" named section which should be intersected by a vertical rect over the unit, but the _float_spinePos is returned by the intersect command, not by the model config, it is a dynamic value.