Issue happened again with the latest patch 0.76.

I've figured out the problem, but I don't know if there's a fix. The ID #'s of buildings/objects are changing between patches. So a trigger attached to an Object ID #, will continue to stay attached to that Object ID # after a patch, but the Object ID # will be attached to a completely different object.

For example, in Beta Stable v 0.76, the Radar Array at Air Station Mike had an Object ID # of 68508. I had a trigger linked to that Object ID # and it worked fine.

I upgraded to the Dev version (0.77) and found that the Radar Array now had an object ID # of 123297. The trigger I had placed on the radar array was still there, but it was still grouped to Object ID # 68508 which was now attached to a wall at the airport.

This is starting to get annoying, every patch i have to go into the mission.sqm and update the object numbers for my missions, then update them again.

Im guessing that the numbers update as the devs add objects to the map, but if theres a way to keep the ID numbers from moving I and im sure many other mission creators would appreciate it!

Hey Ben85 - Agree that they still need to fix this. In the meantime, there is a workaround using Game Logic, but it's a bit of a kludge depending on what you're doing

First, create a Game Logic object almost on top of the object you want the trigger attached to. Then in the Game Logic's init field add this:

trigname = nearestObject [gamelogicname,"ObjectClassName"];

Then in your trigger simply set the condition to '!alive trigname' and it should work.

For example in my mission I had a trigger attached to the small radar at the end of the main airstrip on Altis watching for it to be destroyed.

I created a Game Logic Object on top of it called 'glR2' and put 'trigR2 = nearestObject [glR2,"Land_Radar_Small_F"];' in the init field of it. Then I simply created a trigger nearby with a condition of '!alive trigR2' and it works.

Of course, that means you need to go through your whole mission and redo all the triggers, but once you do it, it should stick from patch to patch.

Still...Devs...fix the changing of ID #'s...

Brilliant idea Meatball!

Unfortunately it doesn't quite fit my needs as im essentially trying to delete H barriers. I was using thislist select 0 setdamage 1 and grouping the section of wall to the trigger ect.

Im sure theres a way to make your method work for me but i haven't got my head round it yet. :/

Still no joy, it seems that H Barriers already on the map are unselectable, the method works but only on H barriers placed by the user.

Im just gona continue to update the ID numbers and hope that they settle at some point, would be nice to have some feedback from BIS if this is likely to happen!

Resolved with Eden Editor.