Terrain object ID changes

[DnA 5143]

Overview

Objects on the in-game environments (placed in the Visitor tool) are indexed in the engine by a numerical ID. This ID can be shown in the editor and referenced by various script commands. Unfortunately the IDs also change with almost every update to the environment - especially when removing / adding objects. Any scripted system or scenario referencing them then needs to be updated, and we're seeing people express their frustration with every patch. Let's see what can be done to address this.

Note: as of 1.14 ("Win"), object IDs are no longer altered after an object is placed. So existing objects on Stratis and Altis will keep the same ID even when the environment needs to be updated. This attempt has failed and needs more work.

Who uses them for what?

To start, we should make an inventory of what you are using these IDs for (for reference: we try to avoid ever using them internally). We'll try to update this OP with a list of high-level concepts, rather than very specific examples.

• Editor waypoints inserted directly onto buildings (to allow selecting building positions in waypoint properties). These get broken when the IDs change.
  

• Also used to get units units to building positions

  
  

• nearestObject (the syntax using an object ID)
  
• Grouping triggers with objects
  
• Removing map objects for specific scenarios
  
• Detecting map object destruction for scenario objectives
  
• ...
  

Potential workarounds?

With a more accurate picture of usage, we can try to find workarounds and possible engine changes to accommodate these. In some cases there may simply already exist another method of achieving the same thing. In other cases we may need to pursue also engine updates to achieve the same in a method that does not rely on the IDs. Fully guaranteeing the IDs will not change with patches is not something we can feasibly do.

• A new 'Teleport' waypoint method to position things at specific build positions
  
• Using a position + object class name for object detection
  
• Special module to link logic to objects (details)
  
• ...
  

Edited March 19, 2014 by DnA

[Dwarden 1125]

posting just to keep monitoring this also myself ...

[.kju 3244]

Why not just leave the objectID with a null reference when it gets deleted in visitor.

This way no other object(ID)s are affected and the null reference could be handled easily via scripting.

[ligthert 21]

What is the expected rate of change in near future?

[tupolov 520]

Would be of great use if BIS shipped a static index of objects that can be loaded in game rather than relying on nearestObjects. We're using a static index with much better results, but we have to recompile it with every change.

Would suggest scripters doing waypoints should be using position plus object type (nearestObject or static index lookup).

Or fix nearestObjects :)

[papy.rabbit.08 0]

I use them with nearestobject, for checking if building get destroyed (objective) and of course with every update, the entire mission goes wrong because of that, the fix is easy of course. But I must say I would be glad if this problem gets fixed!

[JKNuke12 2]

I also use them with nearestobject, but to remove bushes to clear out lanes on a firing range. If you guys could have the grass clippers remove bushes, it would solve all of my issues.

[2nd ranger 282]

Since the Alpha when I noticed the IDs were changing regularly, I started using a world position + the object's classname instead. So I make a point of not using them anymore.

[sproyd 2]

How am I using it - well any mission which is destroy X object I just create a trigger covering the area of the object (i.e. a lighthouse) and then group the trigger to said object. When you change the ID's the trigger then becomes grouped with a different object somewhere way off on the other side of the map so the whole mission is broken. Every time this happens I have to open all of my missions, regroup the trigger with the correct static object, save, re-upload to BIS Forums/Steam etc etc etc. So if this keeps up then you are going to have a huge Steam back-catalogue of broken user missions as I'm sure 99% of people don't know that there missions are busted or can't be bothered updating.

The fix would be that each object has a static ID that does not change even if more objects are added removed from the map.

So if you had a map with object ID's of

1, 2, 3, 4, 5, 6, 7, 8, 9, 10

and you added two more and deleted three it would look like

1, 2, 4, 5, 6, 7, 10, 11, 12

Otherwise 4 becomes 3 and so on.

[nuxil 2]

....

The fix would be that each object has a static ID that does not change even if more objects are added removed from the map.

So if you had a map with object ID's of

1, 2, 3, 4, 5, 6, 7, 8, 9, 10

and you added two more and deleted three it would look like

1, 2, 4, 5, 6, 7, 10, 11, 12

Otherwise 4 becomes 3 and so on.

yes. that would make it backwards compability.

also let it be said that the nearestobject command takes a big dump on your performance.

if a internal static list could be accessed by a new faster scripting command, it would solve lots of the performance issue imo.

what comes to mind is someting like this,.

_obja = IdToArray 123456; // returns [obj, type , whatever more is needed.]

if ((getdammage (_obja select 0) >= 1) then {foo

if ((_obja select 1) isKindof "whatever") then {bar

_dude setpos (getpos (_obja select 0));

getting the obj data from a reference list instead of "scanning for it by id" using nearestobject.

[Alias001 10]

I'm not exactly an advanced builder/scripter but I am a regular complainer about the issue on twitter so I'm rather glad it's being addressed. I've been using the object IDs with setpos to establish static garrison positions in buildings without having to give the units walk waypoints and have them betray their position in the building by leaving the door open.

What would solve the problem for me would be a new type of waypoint, Teleport. You could place a unit on the map, give them a teleport waypoint locked to the building and you can instantly drop them into whatever building position you want (incidentally, those need to be named, 'position #12' is a lot less useful than 'top floor rear balcony' would be). I can also imagine it being really handy for setting up ambushes or other scripted events where you don't want to risk the players accidently stumbling across the units ahead of time

Actually what would really solve the problem for me would be a full 3D editor akin to the MCC Sandbox mod but that's somewhat out of scope for this thread.

[mikero 79]

well. apologies, but this is straight out nonsense.

once an object is placed in visitor it's ID is set in concrete, you can alter amend edit or bash the pew file to your heart's content (via visitor) and that id for THAT object remains sacrosanct. I think you have the peculiar idea that if you delete one or several objects in a pew, then all, or at least most, of the remaining objects get renumbered. Presumably along the lines of 1,2,3,4. The facts are different. An ID once assigned can never be used again. If a 'tree' with an ID of 122 is deleted via visitor, it is FLAGGED as 'unavailable', it is NOT removed as such, and plays no further part in the construction of a subsequent wrp. It's ID however is inviolate, along with all the other assigned id's. These pew id's are directly transcribed to the wrp and not fiddled with.

The very 'feature' you seem to want to introduce was installed on the very first poseiden demo island because the creators were working in-tandem with creating missions for, and updating the island pew, at the same time. They recognised the very issue you are raising now, ten years ago, and solved it, then.

The only crying shame in all of this is Bis chose to shoot themselves in the head by removing the sqX objectID command (the only command they did remove), when 'improving' the engine to Armed Assault. Most ofp missions relied on retrieving the known ID for a lighthouse in the northwest corner of the map to spawn vehicles or create waypoints. It rendered most considerations of porting ofp missions to arma as an exercise in futility.

Edited October 30, 2013 by Mikero

[DnA 5143]

;2545951']Why not just leave the objectID with a null reference when it gets deleted in visitor.

This way no other object(ID)s are affected and the null reference could be handled easily via scripting.

Such low-level change in both the tools and engine is not feasible now. Options for the long-term are relevant' date=' since more so than ever will this issue arise (previous, more traditional methods of game release, saw very few terrain updates post-release). Also: we ran into hard-limits with maps like TKOH's Seattle. I'd like to focus on shorter-term work-arounds and compromises that benefit people now rather than in the future.

---------- Post added at 11:02 ---------- Previous post was at 11:01 ----------

What is the expected rate of change in near future?

After the two announced changes, we don't expect larger updates to e.g. Altis. However, even a single object can cause object IDs to change.

---------- Post added at 11:18 ---------- Previous post was at 11:02 ----------

well. apologies, but this is straight out nonsense.

There exists no proposal in the OP for changing anything yet. I may have simplified the description of when object IDs get re-indexed, because the goal of this thread was gathering intel in how you use IDs. It should also be pointed out that there are issues other-than-technical that prevent quick updates to Visitor. We are looking into options.

Edited October 30, 2013 by DnA

[sproyd 2]

What would solve the problem for me would be a new type of waypoint, Teleport. You could place a unit on the map, give them a teleport waypoint locked to the building and you can instantly drop them into whatever building position you want (incidentally, those need to be named, 'position #12' is a lot less useful than 'top floor rear balcony' would be). I can also imagine it being really handy for setting up ambushes or other scripted events where you don't want to risk the players accidently stumbling across the units ahead of time

Agreed. Having to set a WP for a unit's starting position and have AI walk to that WP is frustrating and leaves open all kinds of problems (like open doors, AI pathfinding issues, CPU utilisation, timing). Having a teleport waypoint would be very useful in a number of circumstances I can think of - not just starting positions.

[.kju 3244]

Such low-level change in both the tools and engine is not feasible now. Options for the long-term are relevant, since more so than ever will this issue arise (previous, more traditional methods of game release, saw very few terrain updates post-release). Also: we ran into hard-limits with maps like TKOH's Seattle. I'd like to focus on shorter-term work-arounds and compromises that benefit people now rather than in the future.

Please keep also community terrain designers in mind. In regards to objectIDs community work is far more relevant.

[[aps]gnat 28]

How about BI provide a special Game Logic or module

To use;

- Place the Game Logic beside the object wanting to ID

- Set 1st parameter to CLASS of the nearby object you want ID'ed

- Set 2nd parameter to any unique NAME or NUMBER

This is now the scenario makers new object ID. The GL can be tested at any time, same as the Object under it.

Better still if it could be linked to a EventHandler, so you dont have test all the time.

[LuLeBe 10]

I use them not all that often, but sometimes they play a big role in my missions:

recently I used them to determine whether a building has been destroyed to trigger an action that switches all the lights off. Oh, that's another thing, we still can't switch lights on and off.

[Alias001 10]

I've just found a new way the changing of object IDs annoy me, hooray!

In order to simulate previous damage and/or start buildings as destroyed, I've been using the trick of grouping a trigger with the code "thislist select 0 setdamage 1". It works perfectly until the object IDs update and then a bush 3/4 of the way across altis is suddenly a lot less healthy, the editor complains about invalid links and I spend the next 5 minutes relinking triggers and running through the swearier portions of my vocabulary.

[samatra 85]

Great to see that developers look into this issue, I've been having problems with pre-placed objects since Takistan. Biggest issue for me is that lots of objects like Bags with food, chairs, water barrels are all over the map and when you use these objects in your mission, it confuses players why some objects are interactable and some are not. There are two kinds of pre-placed objects that we have to deal:

1) Objects with classname: Cargo bunkers, towers, HQs, patrol towers, some walls

We use these objects as building material in our mission and having these pre-placed objects is a problem since they have simplified simulation and if you change their position (using attachTo) they do not synchronize with JIP clients (will appear on original spot for JIP players)

Working methods to get rid of these objects:

- attachTo to objects outside of map, apparently requires attachTo on JIP too

- setDamage 1 and then cleanup ruins

- hideObject them (best method)

2) Objects without classname (models). These are the real problem, there are hundreds of water barrels, food sacks, etc. on Altis and Stratis, having these objects pre-placed on the map causes lot of problems when you use same objects for your gameplay mechanics and there is no way to properly get rid of them as of now, these objects react only on setDir, setVectorDir\Up and setDamage commands. With damage some objects can be inflated (better) or flipped over (worse) while other objects do not react to setDamage at all (wooden crates, hbarrier bags, etc.)

Currently we scan entire map for objects with matching model name and dump object locations and object ids and then add this data into the mission so server could go through these objects and setDamage 1 them or setVectorUp [0,0,-1] to flip them over so they would look at least slightly different from objects that we use in the mission. As I mentioned some objects cannot be destroyed at all (for example: wooden crates with arabic writing on them) and this makes use of these objects in the mission unacceptable since it will definitely cause confusion for players.

Now about possible solutions, here are my ideas:

1) Some time after release of A3 Alpha I made a ticket with suggestion to let mission designer exclude objects by their IDs in description.ext so objects wouldn't load\stream at all right from the beginning: http://feedback.arma3.com/view.php?id=6783

There are lots of preplaced objects on Stratis that you simply don't want to have in your mission because you might use same object for your mission and players will confuse pre-placed objects with actual usable script-placed object. As of now there are hundreds of such questionable objects with simplified simulation and no classname that use models of useful objects and you cannot do anything with them, even if you get their handle with nearestObjects, you cannot move them away, they do not react to setPos, attachTo, anything, even when you destroy them they just flip on their side and you can walk through them, nothing but problems.

My feature request is to allow mission maker to exclude certain objects from map completely by specifying their IDs in array in mission.sqm or description.ext.

Something like this:

excludeObjects[]={103532,125324,106320};

2) Make hideObject work with models (classless preplaced vehicles) so we can hide these objects like we can now with pre-placed vehicles that have class

3) Make deleteVehicle work with pre-placed objects so we can simply delete them instead of hiding

Additionally it would be great if we had a command that would return vehicle by model name and a command that would translate vehicle into ID number and vise versa (ancient nearestObject where you have to specify coordinate along with ID is not a best thing in the world).

Also I have no issues with object ID changes since we update mission often and updating IDs is not a big deal. Manipulating objects by IDs is the issue for me.

Edited November 22, 2013 by SaMatra

[meatball 25]

Back in Alpha/Beta my first mission used triggers grouped to objects primarily to watch when they were destroyed. After a few patches and changing ID numbers I figured out what the problem was and have stepped away from using ID's at all because of this.

I now setup some gameLogic near the object I want to monitor using a 'nearestObject' and the classname of the object to assign an object name to that object. This of course means I need to determine what the actual classname of that object is and can be very challenging when there are multiple similar classnames for the same 'type' of object (factories, bridges, towers, houses, etc.) Once I've figured out what the actual classname is of that object and have the gameLogic working I can then set up a trigger to check against that gameLogic generated object name. Assuming the classname doesn't change, that keeps working from patch to patch.

If I could suggest anything it would be:

1) Preferably, just don't ever change an object ID. Once an object ID is assigned to an object, it's never changed, or re-used if the object is deleted.

2) If that's not feasible, set it so when grouping a trigger to an object, it doesn't attach itself to the ID, but perhaps to the nearestobject at that location.

3) Finally, it would be _awesome_ if there was some way to easily determine what (a button like the "ID" button in the editor perhaps?) classname an object actually is.

[sproyd 2]

Back in Alpha/Beta my first mission used triggers grouped to objects primarily to watch when they were destroyed. After a few patches and changing ID numbers I figured out what the problem was and have stepped away from using ID's at all because of this.

I now setup some gameLogic near the object I want to monitor using a 'nearestObject' and the classname of the object to assign an object name to that object. This of course means I need to determine what the actual classname of that object is and can be very challenging when there are multiple similar classnames for the same 'type' of object (factories, bridges, towers, houses, etc.) Once I've figured out what the actual classname is of that object and have the gameLogic working I can then set up a trigger to check against that gameLogic generated object name. Assuming the classname doesn't change, that keeps working from patch to patch.

If I could suggest anything it would be:

1) Preferably, just don't ever change an object ID. Once an object ID is assigned to an object, it's never changed, or re-used if the object is deleted.

2) If that's not feasible, set it so when grouping a trigger to an object, it doesn't attach itself to the ID, but perhaps to the nearestobject at that location.

3) Finally, it would be _awesome_ if there was some way to easily determine what (a button like the "ID" button in the editor perhaps?) classname an object actually is.

this. God... this.

Basically, why does the Editor permit grouping with static map objects if the IDs are not fixed and constantly change everytime the map is patched. Please tell me there is a better fix than using nearestObject with the (indeterminate) class name.

[DnA 5143]

I've updated the OP with this bit of info: as of 1.14 ("Win"), object IDs are no longer altered after an object is placed. So existing objects on Stratis and Altis will keep the same ID even when the environment needs to be updated (more info).

[highhead 20]

I've updated the OP with this bit of info: as of 1.14 ("Win"), object IDs are no longer altered after an object is placed. So existing objects on Stratis and Altis will keep the same ID even when the environment needs to be updated (more info).

We decided to go the route to analyse the map object indexes with DEWRP for ALiVE early on, since analysing with nearestobjects (type) had always been too performance heavy.... As there is no command "object" (ID) anymore (there was in OFP) we still needed to use nearestobject ID to get the referenced object from the map indexes. Since the mentioned change, nearestobject ID is completely broken, and there is no workaround. It has a high impact on performance (again) and locks up the game if the command is used with ID as intended. We are really hoping that there is a fix before 20th, as this is really a gamebreaking issue for us!

http://feedback.arma3.com/view.php?id=17856

[DnA 5143]

As far as I've seen that issue has been fixed and is merged to the 1.14 update.

[tupolov 520]

BIS why u no test properly? lol

"On a very simple QA analysis the issue becomes obvious so quickly...

I took the 10 minutes to analyse the houses incl. references on stratis: Of 682 "house" objects, over 450 are still broken, 66%!"

http://feedback.arma3.com/view.php?id=17856