Detecting if a unit is proned

[Fragorl]

However, the z axis of the position doesn't change even though the unit changes it's stance/pose...
The x and y do change but they can't be used as a reference data...

You're suuuure it doesn't work? :-\ It sounds so perfect.... a drop particle attached to the unit's head would be ideal. D*mn nasty operation flashpointless!

[h-]

I'm pretty sure, I did quite a bit of testing, and we tried to use it in MCAR too but others found out that it really doesn't work...

But if someone makes it work then it would the easiest solution...

[Jezuro]

My idea was to create a camera (it behaves the same way like any other object in the game, but has no visible model) and use no CameraEffect command. You can then execute any camera command and it in fact works!

That way you can command the camera to target a specific soldier. As you know, with _camera CamSetTarget aGuy, the camera always watches the guy's head. So I tried to create another camera in a specific distance from the first one, command it to target the first camera and then CamSetRelPos it precisely in front of the first one.

The thing is that CamSetTarget checks also the vertical rotation of object, something like, let's say, a non existing command GetVerticalDir I think there is no other way to do that, is it?

So if the soldier is standing, his head and therefore also the second camera will be higher than when lying/crouching.

I know it sounds complicated, but only because I don't know how to explain it better. Anyway, I remember I checked it out, but something went wrong, though I can't remember what  

Gotta try it again, I suppose  

[h-]

Sounds interesting indeed...
Actually that should work...

[dmakatra]

I experimented with this idea and came up with nothing. However, I'm not very experienced with cameras and I'd love to see someone else have a go.

:beat: *Gets Shot* :beat:

[General Barron]

Hmm... interesting idea with the camera method. Not sure I quite understand how the camera uses a verticle direction though, perhaps you could explain that some more...

yes.. I thought this was almost common knowledge...

drop["cl_basic","","Billboard",0.01,0.01,"here you can put the model part",[0,0,0],0,1,10,0,[0.1],[[0,0,0,0]],[0],0,0,"","pos.sqs",the 'target' unit]

the model part can be anything that has been named in the model, for example a proxy...

No, I never knew that. I guess because it wasn't in Vektorboson's tutorial. Looking at the com ref, I now see that it does say it there. Hmm... now all I need to do is find out what a 'named selection' is, and how I can know what they are...

Any idea where that skiing script could be found...
Even if it wouldn't work in this case I  sure could find some other uses for such method...

Skiing script, complements of Razorwings18 (maker of the great dialog editor):
http://www.ofpec.com/editors/resource_view.php?id=261

[Planck]

A 'named selection' is a part of a model ......a selection of points and faces......that has been given a name, in order for it to be accessed easily.

For instance hlava is a named selection for a man unit.

Hlava is the head.

I have list somewhere of most of the default selection names.


Planck

[Fragorl]

Re the camera method

Will it be possible to create/settarget/commit the camera and then read it's position, all in the time it takes to run a function - even if you use camcommit 0? I have seen in one or two cutscenes that people have written

_cam camCommit 0
@camCommited _cam

which suggests there is a (negligible) delay there, even though camCommit 0 is supposed to be instant.

Also - when mucking around with the setpos/getpos combination in functions, I've noticed that the function often reads the created unit's position incorrectly, rendering the function useless for checking things like whether the unit has collided something, even though both setpos and getpos are meant to be instantaneous as well (although I'd imagine setpos waits until the next game 'tick' to execute). For example, you setpos one unit inside of another and then query it's position; you are always returned the position you just set it as, even although the second unit is never actually drawn inside the first one, even for a tiny amount of time. Also, camcreating/setposing/getposing a unit causes similar problems with the function sometimes reading positions correctly.

I have a sneaking suspicion that this camera method might not work as an instant check in a function - but I will check this as soon as I can.

[Jezuro]

To the cameras: Imagine a flying plane watched by a looped camera applied with CamSetRelPos command. I mean:

Code: [Select]

#Loop
 _camera CamSetTarget aPlane
 _camera CamSetRelPos [0,+10,0]
 _camera CamCommit 0
 @ TRUE
 goto "Loop"Got it? Now imagine that the plane goes up (its nose is rising). The camera still watches it precisely from the front, so it "knows" that the plane is rotating vertically. You could try it quickly in mission editor.

There's one more slight problem. If you use CamSetPos to set a camera's Z axis, let's say, 2 metres high and then try to get it's Z coordinate, you'll not get 2, but 1.65 (if I remember well, of course  :-\)

It is wise to apply

Code: [Select]

@ CamCommitted _camera even after

Code: [Select]

_camera CamCommit 0 because the engine could delay this command (better say its effect) because of other commands in the queue or slower CPU.

[h-]

@G.B:
Thanks, I need to take a look at that script...
I will need some sort of reference since I'm writing a skiing script myself...

[Fragorl]

Well, I tried that drop particle approach, and I see the problem. Particle appears in unit's torso when standing up (that's for hlava), but in exactly the same place as before when the unit was lying down. Drat.

Another question about drop[], I see from the comref that the ontimer() event 'runs a script every timerperiod seconds, where the parameter _this refers to the particle's position'. Does this imply that it's impossible to affect the particle itself once you've dropped it, e.g. with setvelocity, or setpos?

Going to have a crack at this camera method next.

[h-]

Does this imply that it's impossible to affect the particle itself once you've dropped it, e.g. with setvelocity, or setpos?

Havent tested that, but since the particle is a .p3d model it may be detectable with nearestObject...

So the script that is executed from the drop[] would be something like:

Code: [Select]

_particle = nearestObject [_this select 0,_this select 1,_this select 2]
And if that works, then the particle may be possible to setPos, setvelo, etc...

EDIT:
Just ran a brief test with the camera idea, and no matter what I do the second camera always returns the same height...

[modderman]

off topic a little, but is there anyway to prevent a unit from going prone?

[Fragorl]

unit setunitpos "up"

[DanAK47]

I have had some success dropping an object with a geometry LOD ontop of a unit and measuring the time it takes to reach the ground. However, this method is pretty unreliable.