[FIXED B804] - GetUnitX() bug (Full Version)

All Forums >> [New Releases from Matrix Games] >> Command: Modern Operations series >> Tech Support



Message


mx1 -> [FIXED B804] - GetUnitX() bug (1/31/2016 8:54:58 PM)

This is actually a repost of my own post, but since a year passed I think it is fair to ask again :)

I don't know if it is a bug or WAD, but if the trigger for the 'unit remains in area' is not unit specific then it fires only for the first unit which matches side,type,subtype and class (or in case the event is repeatable once per time interval).
So for example if there are 3 units of matching class that remains in area for X minutes the trigger will fire only for the first unit that remains for X minutes and not 3 times after X minutes.
This behavior is problematic if someone (me) wants to create action based on each unit remaining in the area for some time. My use case is that I want to calculate score based on the number of units remaining in area (to simulate capture progress/strength) but it seems that I can't really tell how many units are in the area.
I can do it by either:
a) repeatable timer event (every X minutes) and then check with Lua if any units are inside the area. Too much coding for me and not very elastic as the unit list to check is within Lua code
b) prepare separate trigger for every possible unit. Not very elegant solution and does not scale well.

So it is either a bug and if not then the feature request would be to make the trigger work separately for every unit satisfying condition.

Attaching scenario illustrating the issue. The event only triggers for "Ship A", never for "Ship B".




Yokes -> RE: [B775.12] - Unit remains in the area - fires only once (2/1/2016 5:20:01 PM)

mx1,

Maybe I'm missing something, but can't you achieve what you are trying to do by having an event for each individual unit?

Yokes




mx1 -> RE: [B775.12] - Unit remains in the area - fires only once (2/1/2016 6:57:37 PM)

Yokes,
The scenario I'm working on includes the evac mission performed by three helos. The idea is to measure mission performance based on the fact that helicopter stays in evacuation zone for 3 minutes. So the mission performance can be scored from 0 to 3 based on the number of helos surviving in the zone for at least 3 minutes.

My idea to implement this scoring was to have an event based on "unit remains in the area" trigger which would execute Lua script that updates the score. The simplest way would be to use ScenEdit_UnitX() to find out which helicopter triggered scoring, which would also assure that each helicopter is counted only once. Current system behavior makes this approach impossible as the trigger fires only once even if more than helicopter stays in the area, since the trigger is unit class based ("side A" aircraft) and not unit specific. The reason why I can't make trigger unit specific is that units are generated by events and trigger editor only allows to specify unit if the unit exists when defining trigger.

If you have idea how to implement this use case in a different way with the current system I am open to suggestions.





Yokes -> RE: [B775.12] - Unit remains in the area - fires only once (2/1/2016 9:19:36 PM)

mx1,

You can work around the "unit doesn't exist yet" "feature". [:)]
Simply create each unit (named appropriately) and set up the three events. Then delete the units. Just make sure you use the correct names when you script the creation of the helos.

Yokes




mx1 -> RE: [B775.12] - Unit remains in the area - fires only once (2/1/2016 10:37:37 PM)

I don't think it works that way. If you set up trigger for specific unit and then delete the unit, the trigger will not fire for the new unit even if the name is the same. If you add a new unit with the same name and then go to trigger editor you will see that there are actually two units with the same name on the dropdown list. After you select anything from the list the list gets updated and the old (deleted) unit is removed from the list (which is sort of a bug itself).




Yokes -> RE: [B775.12] - Unit remains in the area - fires only once (2/2/2016 2:27:57 PM)

mx1,

I know it works because I have done it.

Create three helicopters, each with a unique name. (I usually just add a number after the name.) Create three triggers, each one assigned to one of the unique helicopter names. Delete the three helicopters. Don't go back and edit the three triggers, or you may lose the names. Create three spawning events making sure you get the names correct.

Also, if the devs changed the behavior of the trigger to work like you suggest it would break a bunch of existing scenarios. I am also pretty sure it wouldn't solve your problem, either. The trigger is currently designed to support exactly as you are requesting, but it just takes a bit more work.

Yokes





mx1 -> RE: [B775.12] - Unit remains in the area - fires only once (2/2/2016 6:08:40 PM)

Setup #1
I have created sample scenario with three helos with different names. I've created three separate triggers for each of them remaining in the area for 1 minute. The action is simple Lua script which just pops up message box saying which unit has GetUnitX() returned. There are three separate events, each with separate trigger, and just to be on the safe side, each event has separate action object, although all actions have the same script.

Expected behavior
After scenario runs for 1m, we should get three message boxes, each with the name of the helo which triggered the event.

Actual behavior
After scenario runs for 1m, we get three message boxes, each with the name of the helo number #3. The message logs shows that events corresponding to three different helos have been fired.

Conclusion #1
There is a bug within GetUnitX(). It seems that if there are multiple triggers within the same time window (1 minute???) GetUnitX() always returns first unit which triggered 'unit remains in the area'.

Setup #2
Same scenario as Setup #1. Deleted helos from the scenario, did not touch triggers. Added event triggered by time (2m into scenario)which fires Lua script that adds three helos of the same unit type as deleted units and with exactly the same unit names.

Expected behavior
After scenario runs for 2m, three helos should appear and after additional 1 minute we should get three message boxes, each with the name of the helo which triggered the event. Since we know that there is a bug #1 we could also expect that all three message boxes show the same unit name.

Actual behavior
After scenario runs for 2m, three helos appear inside the designated area. Nothing more happens during scenario run even after 10m.

Conclusion #2
The triggers work as I've wrote in my previous post, that is deleting unit specific trigger invalidates trigger. In my opinion this is WAD since triggers should be related to guids not names and trigger editor UI shows names just for convenience.

Final conclusion
I am still looking for the solution of my use case.



Both test scenarios attached in .zip file.

EDIT
Tested this with both 775.12 and 775.13 with the same results.




Yokes -> RE: [B775.12] - Unit remains in the area - fires only once (2/3/2016 2:36:35 AM)

mx1

Well, I'm an idiot.

I tried about 4 different ways to make this work, and I couldn't.

First off, you are correct that if you specify a trigger based off a specific unit, it apparently uses the GUID and not the name. I understand why they did that, except that it prevents doing what you are trying to do. (All units must exist beforehand.)

Secondly, you correctly pointed out that the "unit remains in the area" trigger only fires once, even if there are multiple units that can make it fire. I agree that this is a bug. I can figure out no way to do what you are trying to do.

Sorry I doubted you before.

I have also included my own scenario I was using to try to test this. It works for the first unit, but fails on the second and third because it only triggers on the first helicopter.

Yokes




mx1 -> RE: [B802] - GetUnitX() bug (3/15/2016 7:44:55 PM)

Bug described in Setup #1 is still there in 1.11 RC1.




ComDev -> RE: [B802] - GetUnitX() bug (3/15/2016 8:46:22 PM)

...but Setup #2 works ok?




mx1 -> RE: [B802] - GetUnitX() bug (3/15/2016 9:18:22 PM)

Yes. #2 is sort of WAD.
"Sort of" because to be really correct, deleting unit which is used in trigger should invalidate trigger, while now the trigger does not show any signs of being invalid. But this is minor, non-breaking bug. #1 is major issue.




ComDev -> RE: [B802] - GetUnitX() bug (3/19/2016 9:38:19 AM)

Fixed #1 in B804, thanks! [8D]




Page: [1]

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
1.75