Author Topic: Detecting if a unit is proned (Read 6167 times)

Nemesis6 · « **on:** 23 Apr 2005, 15:23:56 »

Is this possible in any way? I tried (getpos player select 2), but that only works when the terrain is rugged, and it's not reliable... so, help?

EDIT: Maybe this should have been in the General section...

Blanco · « **Reply #1 on:** 23 Apr 2005, 17:52:50 »

AFAIK not possible in any way.
It's only possible in VBS1 (that's what I heard)

h- · « **Reply #2 on:** 23 Apr 2005, 21:09:55 »

I was once working on a workaround for this problem, but it seems to be impossible to do...

My idea was to drop a very short 'lifed' particle on some named selection (of the 3D model) position and then compare that position's height to some initial value to get the units stance but all I found out was that the named selections on the model don't seem to follow the units animations...
The position returned always the same height, no matter what the units stance was...

And I confirmed the named selection's position was returned otherwise correctly as the x and y axis positions changed if the unit moved...

DBR_ONIX · « **Reply #3 on:** 30 Apr 2005, 14:10:09 »

I think it's possible on AI using animationPhase or something (can't remeber exactly)
..but not sure
- Ben

h- · « **Reply #4 on:** 30 Apr 2005, 16:24:33 »

Nope, animationPhase is used to 'detect' O2 anims (like doors on houses etc) not .rtm anims that are used for example on the stances...

Fragorl · « **Reply #5 on:** 01 May 2005, 03:50:57 »

This problem needs major solving.

One idea is to use a 'latent' function (i.e. script), camcreate a smoke grenade (or something) and pass it briefly over the unit at a specific height, then return you a global variable, true or false based on whether the object hit the unit (standing up) or not (lying down).

Pros - It works (much of the time).
Cons- Not reliable
- It doesn't work if the unit is faliing (units tend to fall upside down)
- It doesn't work if the unit it on a very steep incline (can hit the unit's head or legs, or the ground)
- It sometimes fails if the unit is running (level or non-level terrain)
- It is latent, so it doesn't instantly return you a value. Consequently you have to take this into account in a script

Another method is (getpos this select 2) < 0.0135 or whatever it is, which you mentioned in your post.

Pros - It occaisionally works!
Cons- It is very unreliable
- Only works on inclines
- The 0.0135 value changes

Someone mentioned a while ago using a 'fired' evenhandler, comparing the height of fired ammo to the unit's height. The returned value is quite reliable, only you have to wait until the unit shoots (or force it to shoot), which would make it a VERY latent function (unpredictably so), would interfere with the scenario that the script was working in, and would make it dependent on whether the unit had ammo, was reloading etc.

dmakatra · « **Reply #6 on:** 01 May 2005, 14:02:40 »

I've looked into this and found several solutions to this problem. I decided that two of them are reliable enough to document. But I haven't got round writing the tutorial yet. It's very much possible, just gimme your spare time.

:beat: *Gets Shot* :beat:

Jezuro · « **Reply #7 on:** 01 May 2005, 14:17:01 »

Quote from: dmakatra on 01 May 2005, 14:02:40

I've looked into this and found several solutions to this problem. I decided that two of them are reliable enough to document. But I haven't got round writing the tutorial yet. It's very much possible, just gimme your spare time.

Anything concerning camera targeting? I've also wanted to look at this problem and I believe that cameras (without camera view, of course) could solve it. But I've been too lazy to stop thinking and start testing so far

h- · « **Reply #8 on:** 01 May 2005, 17:34:30 »

I've been assing about with the camera stuff actually a while back...
And completely forgot about it, so thanks a bunch for reminding me

I found the old files and after a quick test it seems to work semi-perfectly

Prone is easy to detected but crouch/standing up requires a bit more, but shouldn't be too hard

...

EDIT:
Of course this can be used only on the player(s)...
The AI doesn't press any buttons when it changes stances...

Fragorl · « **Reply #9 on:** 01 May 2005, 22:43:46 »

@dmakatra

Can you outline the bare bones of your method/s?

Nemesis6 · « **Reply #10 on:** 02 May 2005, 16:17:09 »

HateR, could you maybe post an example of this camera method? I'd like to see how it works, and of course, get my hands on it!

h- · « **Reply #11 on:** 02 May 2005, 18:39:35 »

Just 'utilize' the Keyboard input script by hardrock (and Vektorboson)...
http://www.ofpec.com/editors/resource_view.php?id=760

But that won't work for the AI

...

dmakatra, you really should post yer findings, or are you just trying to get faster up to 4000 posts

dmakatra · « **Reply #12 on:** 02 May 2005, 18:59:50 »

Oh, they're all mine. ALL MINE! ;D

I'm still doing some researching in the subject. But I got thursday (or is it tuesday? I never learn to keep those two apart) and friday off from school so I got time to work on it then.

:beat: *Gets Shot* :beat:

EDIT: Dude, I've totally missed that keyboard thingy. Awesome stuff! :wow:

General Barron · « **Reply #13 on:** 02 May 2005, 19:07:22 »

Quote

My idea was to drop a very short 'lifed' particle on some named selection (of the 3D model) position...

How do you do that? I thought you could only pass either an object or a position to the 'drop' command. Are you saying you can drop relative to some specific part of an object's model?

Quote

Just 'utilize' the Keyboard input script by hardrock (and Vektorboson)...

Jezuro mentioned camera targetting, which would be different than a controlable camera (inertial..? whatever its called). I know there was a skiing script written a while back that cleverly used cameras to determine the slope of the ground, so perhaps Jezuro is thinking of a similar method? Not sure how that would work though...

Another, general problem with any 'detect unit stance' function is that there are many different types of 'prone', 'crouched' or 'standing' animations. Pistol vs rifle, for one example. There could be infinite more possibilities, dependin on how many anims people make. How the computer determines if it is 'up' or 'down' depends entirely on how it is configured. Whether this matters or not would depend on what you need to do with this function though, I would suppose...

h- · « **Reply #14 on:** 02 May 2005, 20:24:12 »

Quote

How do you do that? I thought you could only pass either an object or a position to the 'drop' command. Are you saying you can drop relative to some specific part of an object's model?

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

Code: [Select]

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...
The position of the particle is passed into the script that can be executed from the drop[] line...

The pos.sqs would look like this:
_position = _this

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...
I also confirmed that the z pos does work, for example using this method on a chopper makes the z position change as well when the chopper changes altitude...

Quote

I know there was a skiing script written a while back that cleverly used cameras to determine the slope of the ground, so perhaps Jezuro is thinking of a similar method? Not sure how that would work though...

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...

Fragorl · « **Reply #15 on:** 03 May 2005, 00:53:31 »

Quote from: HateR_Kint on 02 May 2005, 20:24:12

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- · « **Reply #16 on:** 03 May 2005, 05:10:12 »

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 · « **Reply #17 on:** 03 May 2005, 18:43:16 »

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- · « **Reply #18 on:** 03 May 2005, 19:23:15 »

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

dmakatra · « **Reply #19 on:** 03 May 2005, 20:41:53 »

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 · « **Reply #20 on:** 03 May 2005, 23:51:53 »

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...

Quote

yes.. I thought this was almost common knowledge...
Quote
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...

Quote

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 · « **Reply #21 on:** 04 May 2005, 00:02:24 »

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 · « **Reply #22 on:** 04 May 2005, 00:33:59 »

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 · « **Reply #23 on:** 04 May 2005, 18:56:26 »

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- · « **Reply #24 on:** 05 May 2005, 12:06:38 »

@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 · « **Reply #25 on:** 05 May 2005, 23:05:47 »

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- · « **Reply #26 on:** 06 May 2005, 08:52:16 »

Quote

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 · « **Reply #27 on:** 12 May 2005, 02:55:55 »

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

Fragorl · « **Reply #28 on:** 12 May 2005, 03:50:36 »

unit setunitpos "up"

DanAK47 · « **Reply #29 on:** 13 May 2005, 22:51:00 »

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.

h- · « **Reply #30 on:** 14 May 2005, 10:40:34 »

Not a bad idea though...

I guess the problem is that the particle needs to fall down insanely fast for this to be usable...
Would need to happen in at least one 0.01 secs when standing...
Otherwise it might not be so usable...

Author Topic: Detecting if a unit is proned (Read 6167 times)

DBR_ONIX

modderman

DanAK47

Sitemap