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