Bug #13620

variable-space from (world) objects doesn't get cleaned... ever :/

Added by ruebe almost 7 years ago. Updated over 5 years ago.

Status:Closed Start date:09/10/2010
Priority:Normal Due date:
Assignee:Dwarden % Done:

0%

Category:Scripting: Problem
Target version:1.60.87580
Affected ArmA II version:1.60 BETA First affected build:
Reproduced by another DH user:No First affected ArmA II version:
I am using some Mods:No Single / Multi Player?:
I am using: BIForumURL:
Reproducible for you:Yes NGUrl:
Related to content of DLC: WIKIurl:

Description

The variable-space (setVariable/getVariable) of world objects does never get cleaned. It's a big problem if these variables get carried over the restarted or new games/missions. Only restarting the game itself cleans that variable-space, while this should happen everytime a new mission/game is started prior to the missions initialization, so that all objects variable-spaces are empty again.

Observation:
  1. Open the editor,
  2. pick a house as test-object and setVariable something,
  3. quit/restart the mission,
  4. the test-object's variable-space is still intact, the previously set variable still existing.

What should happen instead:
On restarting the mission, the test-objects variable-space needs to be empty.

Why this is so bad (example):
Imagine you write a script that sets houses on fire, burning it down slowly. Further we need a way to let the AI know, that this house is actually burning and thus dangerous. For example you don't want to see AI walking into such a buildings (house patrol script or something), catching fire and die a horrible death (assuming our house-on-fire script set's units near particle sources on fire, hehe). So naturally we simply flag the house (_obj setVariable ["TAG_isBurning", true]) and may adjust our other scripts to filter out buildings flagged with that variable and tada, the AI will know that this house is burning, thus we exclude it from our house-patrol or whatever...

Sounds like a sound plan, doesn't it?

Well... play that mission again (and again), other houses get randomly picked to be burning... and suddenly no houses are patrolled anymore... Why? Because all these houses are still flagged as TAG_isBurning from the previous runs... oh my.. :/

Dimension:
I'm not sure if this bug was always present. But at least it's in the game since the latest stable for OA (154) and for every beta since.

Also note that I'm not sure what else (besides buildings) is affected by this bug. I assume it affects all world objects that have an object variable-space. But that's just a guess.

Conclusion:
Yeah, it really is that bad. An already littered variable-space at the start of a new mission is terrible.
:|

Demo Mission/Reproduction:
I've attached a demo mission to conveniently check this bug out:
  1. open the map
  2. click somewhere near a house which flags it
  3. reload the mission
  4. repeat with the same house, note that it was still flagged from the previous run

The first time you flag a house you'll get a "OK: obj flag set" message.
Once flagged, you will get a "WARNING: obj was already/still flagged!".

objectVariableSpace.Takistan.pbo (2.7 kB) ruebe, 09/10/2010 22:36


Related issues

related to ARMA2 Community Issue Tracker - Bug #13643: setCamShakeDefParams and setCamShakeParams effects kept a... Assigned 09/11/2010 12/11/2010

History

Updated by q1184 almost 7 years ago

Confirmed with buildings.
I tried to setvariable a vehicle and reload the mission - the variable wasn't kept. So it's probably just map objects.

I've found another issue of the same kind: setCamShakeParams and setCamShakeDefParams commands effects are also carried over to the next mission. If you alter camera shake (e.g. disable it completely), it will stay like that in the following missions until you change it again.
It's hard to imagine this is the way developers intended it to be.

Updated by Xeno almost 7 years ago

Exists allready since A2 was released (and probably allready in A1).

As far as I remember if you start another island and then go back it goes away. But I might be wrong here, it's about a year or so that I've tested it.
(was playing around with storing user name and some other data into an island object to detect JIP players who connected again :P)

Updated by ruebe almost 7 years ago

Well... It's about time then.
Tagging world objects is an important trick for lot's of ideas, just like pheromones are essential for ants.
:)

Updated by kju almost 7 years ago

  • Due date set to 12/01/2010
  • Status changed from New to Assigned
  • Assignee set to Dwarden

ty

Updated by Crowe2Extreme over 6 years ago

i had same issue in arma 1 with setvectorup [0,0,-1]

not sure if this is fixed yet

Updated by Suma almost 6 years ago

  • Status changed from Assigned to Resolved
  • I am using deleted (CO (A2+OA))

Fixed in 83076

Great repro, BTW. Unobtrusive hint (I hate blocking hints in repros), very quick to follow, clear repro steps here in CIT.

Updated by zGuba almost 6 years ago

  • Target version set to Upcoming version

Updated by zGuba almost 6 years ago

  • Status changed from Resolved to Closed

Updated by kju almost 6 years ago

  • Due date deleted (12/01/2010)
  • Target version changed from Upcoming version to 1.60 BETA
  • Affected ArmA II version changed from 1.55 BETA to 1.60 BETA
  • CPU deleted (T9300)
  • Audio card deleted (Please specify!)
  • Size of OS swap file deleted (Please specify!)

Updated by kju over 5 years ago

  • Target version changed from 1.60 BETA to 1.60.87580

Also available in: Atom PDF