Unit In Vehicle

[Ding]

Well basically Im using the "In" condition to play music as soon as the player gets in a car, and I want it to stop when they get out of the car. Is there a similar condition command that goes something along the lines of

Player Out Car1

that could work for this?

[bedges]

i would investigate eventhandlers if i were you. much more versatile.  :thumbsup:

[JasonO]

Hmmm would:

player !in car1

work?

[Cheetah]

Hmm: !(player in vehicle)
is what I would use.

[Terox]

@ (vehicle player == player):

would become true when the player was out of a vehicle

bearing in mind the @ condition is fast looping, so a slower ~1 loop would be better

eg

#LOOP
~1
?(vehicle player == player):goto "OUT"
goto "LOOP"

#OUT
0.1 fadeMusic 0
exit

[h-]

bearing in mind the @ condition is fast looping, so a slower ~1 loop would be better

True, but heed what bedges said..

Looping scripts for this kind of thing are soooo 1.46

[THobson]

I have found no hard and fast rule about the perfomance hit from a loop vs an @ command.

Each case needs to be tested.  For complex conditional statements the @ must suffer vs the the loop, but the loop brings an overhead that the @ does not have.

In many missions the difference will be hard to spot, but in large missions where there may be many such commads running at the same time then you should test which is better.  For example I know that:

Code: [Select]

@ (getdammage _unit >0.9)
is much better than:

Code: [Select]

#loop
~0.5
if (getdammage _unit <0.9) then {goto"loop"}
Because I tested it with 5,000 scripts all running smultaneously.

[Terox]

i think what is more important, is how quickly you need the "condition" to be seen

if you dont need it to be as "instantaneous" as possible, then use a slower loop

[Ding]

actually "!(player in vehicle)" is what i needed really D:, I always forget about the uses of the Exclamation mark, I find that too many eventhandlers can cause lag sometimes when i have used them .

Thanks for all the help though  :thumbsup:

Edit: Do we still need to lock Solved topics?

[macguba]

We're not making a fuss about it but it remains good practice, if your question has been answered satisfactorily, to lock the thread and write something like "Topic solved - thanks everybody" at the bottom.  Always wait a couple of days after the last answer in case somebody has something intelligent to add.

[h-]

@Ding

I find that too many eventhandlers can cause lag sometimes when i have used them

I find that very hard to believe, unless of course you execute scripts directly from them..

[THobson]

I find that very hard to believe,

Me too.  I have a mission  that has around 1,500 killed EHs waiting to fire, and they all do eventually  , many at the same time

[Baddo]

It's not the event handlers, it's the people who start long looping scripts from, for example, fired event handlers and then they go and wonder why they get lag in a firefight of 24 soldiers... weapons on automatic fire.

On topic: there is also a function groupInVehicle written for checking if a whole group is in a vehicle or not. Can be used for checking if group members are in any vehicle or if they are in the same vehicle.