The bugged command thread

[Doolittle]

If you setPos a "mine" object, it will set itself to the absolute Z value.  Meaning if mine is at [x, y, 0], it will actually be at sea level inside the ground (you should just see its shadow).

If you setVelocity an ammo crate (which doesn't make it move by the way ), you won't be able to pick up anything from that crate even though it gives you the option to do so.  (Took forever to find this.)

Doolittle

[Baddo]

If you setPos a "mine" object, it will set itself to the absolute Z value.  Meaning if mine is at [x, y, 0], it will actually be at sea level inside the ground (you should just see its shadow).

If you setVelocity an ammo crate (which doesn't make it move by the way ), you won't be able to pick up anything from that crate even though it gives you the option to do so.  (Took forever to find this.)

Doolittle

Can you setPos mines? I thought they can't be. I tried to setPos a standard mine and I couldn't get it moving anywhere and when I try to get a mine's position using hint format["%1",getpos mine] it only displays text "array".

Maybe BIS didn't mean that you should use setVelocity on an ammo box? If it even doesn't move when you try it. Well anyway it can be a bug if you say so

[h-]

setVelocity not 'working' is due to the different simulations (found in the config, like simulation="tank" or different classes as there are a few object types that can't be setvelocitied..
Usually they are static objects, houses etc...
Some objects can be setVelocitied after they have been 'pushed' first by creating a bullet and hitting the object with that bullet and then using setVelocity...

Also, if you setVelocity an object that has no geometry it will move pretty weirdly, usually doing the opposite you setVelocity it to do..

And yeah, I'm wondering that mine bit as well..
Mines are very peculiar thing as they don't really exist in any level...
But that's too off-topic

[macguba]

Mines placed in the Mission Editor cannot be setPossed.

Mines created by camCreate can.   (although they go to sea level ... IIRC they are stuck there, but I'm not sure.)

Can you imagine how hard it was finding that one out?  ;D

I know this is technically a bugged command thread, but I think we can allow a bit of discussion about bugged objects.   Or perhaps you could construe it as a bug in setPos, even though it isn't really ......

[THobson]

Well so long as we are dealing with bugged objects as well.

Sound objects cannot be created, deleted, moved or turned off.  But they seem to turn themselves off after a time.

The climb ladder action in the three floor buildings will not be available after a save and restart, or it may be a combination of several save and restarts and long mssion time.

Back to commands:
Deleting a unit that is in a vehicle is only partially successful.  It seems to remove any capability of accessing the unit (name, setPos etc.) but the body stays in the vehicle and there is no way to get it out.  Also any {killed} Event Handler will still fire if they are subsequently killed.  I don't know about other EHs

[Doolittle]

I found if something is in a vehicle and you setPos it anywhere...even on itself, it will move outside the vehicle.  So if I want to delete someone I setPos them ontop themselves first just in case they were inside a vehicle.

On the same note, if you are in CARGO and you setPos yourself somewhere else, you will have a little number icon by your name still...as if you were still in vehicle but you don't see the vehicle icon anymore in the top right of that bottom row.  I haven't figured out a way to fix this.

Doolittle

[UNN]

On the same note, if you are in CARGO and you setPos yourself somewhere else, you will have a little number icon by your name still...as if you were still in vehicle but you don't see the vehicle icon anymore in the top right of that bottom row.  I haven't figured out a way to fix this.

Yeah, setposing units straight out of a vehicle will screw up it's AI. Use the getout or eject action first then setpos them, otherwise OFP thinks there still in the vehicle.

[Mr.Peanut]

This is not a bug per se, but certainly an annoyance.  Neither the GETIN nor GETOUT eventhandlers  fire when a player changes positions within a vehicle.  This makes it impossible to addActions you want only to be visible to the driver of a vehicle, using only event handlers.

[benreeper]

I don't know if this is a feature or a bug but vehicle assignment commands (assignasdriver) do not work on yourself or your group if you are a group leader.  Therefore you cannot script this to speed the process up.
--Ben

[Mr.Peanut]

setDir does not work on triggers.  If you setDir and then getDir a trigger it will return the angle you specified, but the trigger orientation does not change.

[LoTekK]

Both speed and velocity return incorrect values when used on a unit inside a vehicle. Instead of returning the inherited speed or velocity based on the vehicle's movement, both commands return the speed/velocity of the unit in the instant before it enters the vehicle.

Therefore, if you use moveInDriver while running, for example (just to prove a point), as long as you're in the vehicle, speed and velocity will return your running speed/velocity. Once you exit the vehicle, the commands resume working normally.

In other words, if you want to ensure that the commands always returns the expected value, feed them vehicle unit instead of just unit.

[raedor]

In MP: The eventhandler engine gives back false on all clients, where the vehicle is not local, no matter if the engine is on or off. You can easily "fix" it:

Code: [Select]

_vehicle addEventHandler ["fired", {[_this select 0, isEngineOn (_this select 0)] exec "myScript.sqs"}"]

[Pim]

4. objectname setPos getPos objectname
Can result in the object moving a significant proportion of its own size sideways.

The amount of X and Y movement depends on the orientation of the object.  Objects actually move sideways so if you turn it through 90 degrees the X movement will become a Y movement and vice versa.

As far as I have experienced this this, the extent of this ocurring depends on the relative difference between the center of mass of the object and the location of the x,y,z-axes origin in the p3d-editor. It seems that BIS has some very extreme differences between these for some objects (e.g., the standard BIS hangar). For most community made addons this problem does not occur at all (or is unnoticable) as the origin has been placed properly. But I agree, the mere fact that this problem is occuring indicates flaws in the setPos/getPos commands.

[Raptorsaurus]

When a scud missile is set to the launch position (either by the action available when in the vehicle or by use of the action command), after a game is saved and reloaded, the missile will no longer be in the errect position. If the missile is fired the launcher has no missile, but if you save and reload the game, the launcher is "magically" rearmed with a new missile and you can fire it again.