The bugged command thread

[Blanco]

I want to start this thread to gather information (or receive solutions) about bugged commands.
Some commands in the command reference do cause a conflict when you save the game. Btw, this is not the savegame bug I'm talking about, the game doesn't crash when this happens.

To start with an other kind of bug :

combatMode

Operand types:
grp: Object or Group
Type of returned value:
String
Description:
Combat mode of given unit ("BLUE","GREEN","YELLOW","RED")

Bug : Return is only correct when you call setcombatmode in a script or trigger. This means when you change the combatmode via the ingame radio actions (7- 1 to 7), return of combatmode  is incorrect.

SCRIPTED WAYPOINTS TYPE

http://www.armaeditingcenter.com/forum/index.php?topic=13884.0
Works, but when you save the game, waypoint status is lost.

DisableAI

Operand types:
unit: Object
section: String
Type of returned value:
Nothing
Description:
Disable parts of AI behaviour to get fine control over unit. Section is one of "TARGET" (disable watching assinged target), "AUTOTARGET" (disable independed target assigning and watching unknown targets), "MOVE" (disable movement).

Example:
soldierOne disableAI "Move"

I know when you use DisableAI "move" and you save the game, the unit starts moving again. Simple way to get EnableAI...
I dunno if this happens with  DisAbleAI "AUTOTARGET" or DisableAI "TARGET"

animate

Operand types:
object: Object
[animation, phase]: Array
Type of returned value:
Nothing
Description:
Process animation on object. Animation is defined in config file. Wanted animation phase is set to phase.

Example:
house animate ["doors1", 1]

Use the example above, save the game and your door is closed again...

Ok , these are the ones I've found, if you know other ones, please tell me because I want to know them too.

PS :Keep this thread strictly to the subject, please. Maybe we can make it sticky after a while...or send a list to BIS to correct this in a patch  (dreaming is free, no?)

[bdfy1]

SCRIPTED WAYPOINTS TYPE

What is this ?

[Blanco]

What is this ?

Check this
http://www.armaeditingcenter.com/forum/index.php?topic=13884.0

[h-]

Better yet, why not call this the 'BISd scripting functions thread'


createVehicle
- created object is not created on the given position (=misplaced)

saveGame
- too much global variables corrupt the savegame file

setObjectTexture
- after reloading a saved game setObjectTextured textures disappear

time
- time elapsed since mission start, resets to 0 (zero) when loading a saved game

animationPhase
- will always return the value 0 (zero) on dedicated servers

setDamage
- when a vehicle is repaired on a reapir truck (or whatever) the vehicle gets a damage value of 1.4013e-45. If setdamage 0 is issued on the vehicle after that the damage value stays as 1.4013e-45 (research by Killswitch )

loadFile
- doesn't 'support' comments...


And many many more I don't remember right now...
I think the only functions that are not 'BISd' are in and player... ;D

[macguba]

# stuck


We'll figure out what to do with this in due course.    In the meantime consider it a temporary sticky and add any information you think is relevant.

[General Barron]

setface
showMap
showCompass
showWarrant (?)
showWatch (?)
showPad (?)

Results of these commands are lost after loading a savegame. The ones with (?) next to them are unconfirmed, but I'm guessing they work like their bretheren.

Also check this thread here for more bugs:

http://www.flashpoint1985.com/cgi-bin/ikonboard311/ikonboard.cgi?s=84afa340b97a1a1a530e42a397fd8f04;act=ST;f=7;t=47190;hl=reporting+errors

[Doolittle]

createVehicle
- created object is not created on the given position (=misplaced)

This isn't a bug, it's a feature.  Think of all the CTI games where vehicles spawned on top of eachother...would be aweful.  It's great they are "moved" to a clear area.  A way to fix this is to just setpos the newly created vehicle.

Another "bug"...if you createunit a soldier and then moveindriver the guy, if you then command him to move to another position within the vehicle...those positions aren't listed.  They have to be instructed to get out of the vehicle and get back in again.

Doolittle

[THobson]

I think it is a good idea to get all these together in one place, but they should also be added as comments in comref under the appropriate command.  I suggest that at some point a cross-check be done between what we have here and what is in comref to ensure they are both aligned.

My initial contribution:

1. name  
Ceases to work a few seconds after the death of the unit.

2. buildingPos
Returns incorrect values after an abort - resume.  

3. Not so much a command - but a bug none the less:  Armoured units that have no artillery shells (HEAT or SABOT) cannot rearm correctly from a standard ammo truck.

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

5. triggername setPos [x,y,z]
Will result in the trigger being placed Z above sea level not Z above ground level which is what would happen for all other objects.

6. getPos
getPos of an object that is inside, or over the top of a building will return a height that is measured from the nearest floor vertically down from the object, and not the height from ground level.  It could be argued this is not a bug but it does create inconsistencies:
unit setPos [getPos unit select 0, getPos unit select 1, 3.5]
Will put the unit on the middle floor of those houses that have three floors.  Then:
getPos unit select 2
will then return a number very close to 0 being the height of the unit above the floor it is on.

[macguba]

Yes in the fullness of time we (by which of course I mean you  ;D) will disseminate this information.   At the moment we're just collecting it and comments thereon.    We all know how fickle this game is, what appeared to be a bug to one person in one circumstance, may appear different to somebody else in another circumstance.

[THobson]

 ;D
I had a manager once that gave all the work to the smart alecs that suggested it.  It seems he was not alone.  ;D

Indeed one person's bug can be another person's design feature.  Case in point:
If a loon has used up all his mags exept the one in his weapon, if he is then killed, the only way the player can pick up that mag is to pick up the weapon and take it out.  Realistic, but a pain in bum.

[h-]

1. name
Ceases to work a few seconds after the death of the unit.

This is probably due to the dead unit being switched by the game engine to a static object a few secs after the unit has died...

This isn't a bug, it's a feature.  Think of all the CTI games where vehicles spawned on top of eachother...would be aweful.  It's great they are "moved" to a clear area.  A way to fix this is to just setpos the newly created vehicle.

Ok, every single bug could be argued that it's a feature

IMO it is a bug since you give exact coordinates to where the vehicle should be created and it's not created there...

[General Barron]

As long as we're getting really nit-picky...  ;D

loadFile
- doesn't 'support' comments...

It does: with the "comment" command. It does not remove // or /* comments, for good reason though: that is the point of the preprocessfile command. This way you can use loadfile for other things than just functions, like loading text from a textfile (to be displayed in a dialog, for example), and not have to worry about it deleting your text because it thought it was a comment.

One very real and annoying bug, however, is that the preprocessfile command doesn't work from scripts placed inside of an addon! (Or is it you just can't preproccess the scripts that are inside the addon...)

[h-]

It does: with the "comment" command.

Quite... Forgot that completely

But isn't that a bit hinky since you basicly need to waste the good'ol resources by using a function that tells OFP the next string is going to be a comment instead of anything else.. ;D

(Or is it you just can't preproccess the scripts that are inside the addon...)

I'd bet this one...

Sometimes it can work if you use blah=preprocessFile "..\pboname\func.sqf"...
I haven't been that lucky, but that may be because I had the sqf in a subfolder in the pbo...

Of course if you are making a total conversion mod for example you can preprocess the sqf inside the OFP main scripts.pbo, even if the sqfs are in subfolders...

[UNN]

time
- time elapsed since mission start, resets to 0 (zero) when loading a saved game

That comes in quite handy, I believe it's the only way to tell (all be it, longwinded) if a saved games been loaded. If they fix this, they should make sure all addon\scripts\mission init events are called when a save game is loaded. Then apply all the saved variables, to make sure nothing gets reset.

Another "bug"...if you createunit a soldier and then moveindriver the guy, if you then command him to move to another position within the vehicle...those positions aren't listed.  They have to be instructed to get out of the vehicle and get back in again.

I think this might be a feature. As a player you only get access to all positions if you get in as Commander?

Can result in the object moving a significant proportion of its own size sideways.

What sort of objects? Static objects work in multiples of 25 meters, when using setpos. But not when placed in the editor.

1. name  
Ceases to work a few seconds after the death of the unit.

It's probably freeing up the name to be used by another AI, later on?

[h-]

That comes in quite handy, I believe it's the only way to tell (all be it, longwinded) if a saved games been loaded.

True...
Comes in handy when using for example setObjectTexture which also gets funked by loading a saved game...
Checking whenever time is close to 0 and re-applying setObjectTexture you have setObjectTextured parts that stay setObjectTextured...

[THobson]

UNN:

Can result in the object moving a significant proportion of its own size sideways.


What sort of objects? Static objects work in multiples of 25 meters, when using setpos. But not when placed in the editor.

Any object that you can place inthe map..  Place a wire, an ammo crate - anything on the map.  Give it a name say thing  then run the code

thing setPos getPos thing

Keep repeating this and you will see it move across the map.

[Mr.Peanut]

onMapSingleClick
This command is definitely bugged.

Try the following:
Put a marker on the map called "markPos" and a single unit.

init.sqs

Code: [Select]

onMapSingleClick {[_pos] exec "onMapClick.sqs"}
onMapClick.sqs

Code: [Select]

onMapSingleClick {}
_pos = _this select 0
"markPos" setMarkerPos _pos
onMapSingleClick {[_pos] exec "onMapClick.sqs"}
exit

Run the mission and start clicking on the map. Even with slow deliberate clicks, eventually it stops accepting single map clicks.

[Tyger]

Actually mate, it must be your computer because I just used your code and got up to fifty clicks before I got bored and stop. Worked every time.  

[UNN]

Any object that you can place inthe map..  Place a wire, an ammo crate - anything on the map.  Give it a name say thing  then run the code

thing setPos getPos thing

Keep repeating this and you will see it move across the map.

Yeah, only static objects. As you said ammo crates seem to move by X+0.3 & Y+0.2. Houses by 3.9 & -2.0. Regular units and vehicles are uneffected. The 25 meters I mentioned was with Hawks Nimtiz, sections. Not had chance to check the base class for these.

[THobson]

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.

[Planck]

onMapSingleClick
This command is definitely bugged.

I tried your code today as well Mr Peanut.

Everything worked beautifully even after 501 clicks.


Planck

[Tyger]

501? Wasn't that taking it a little too far?!?  ;D

Dedicated loons    ;D

[bdfy85]

Commands "enemy" and "friendly" seem to be nt worky at all - but at least it mentioned in russian comref.
Besides I can't get commands : "sideEnemy","sideFriendly", "countEnemy" to work properly.
But countFriendly works...
See the  example attached.

[macguba]

I don't think "enemy" is a command as such, it is the side of a renegade unit.    (One that has killed too many friendlies and is therefore enemy to all units.)   In other words it is a value returned by other commands.     I suspect "friendly" is similar, but opposite obviously.   Perhaps that can be achieved with setCaptive true, dunno.

sideEnemy and sideFriendly are not listed in the online comref.   However,

countEnemy
countFriendly
countSide

do exist.

[bdfy85]

However, countEnemy countFriendly countSide do exist.

But do they work ?  That is the question

[macguba]

countSide works, I used it in a mission once.  

[Mr.Peanut]

Must be my computer then... dammit...!
But it is still a bug to me.

501? Wasn't that taking it a little too far?!?  ;D

Dedicated loons    ;D

[Planck]

sideEnemy and sideFriendly are not listed in the online comref.

I do believe there is also a sidelogic, which is also not listed in any comrefs.

Don't ask me what it does, if anything.


Planck

[RujiK]

Setposing a unit off a ladder is bugged. As soon as you setpos him he goes away for a split second then goes right back to the ladder.

Also during a cutscene if you are on a ladder and you push up or down your unit moves around even though its a camera scene.

[Planck]

Also during a cutscene if you are on a ladder and you push up or down your unit moves around even though its a camera scene.

Hmmm....Interactive camera scenes.   ;D


Planck

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