"Hard" unit Unassign?

All discussions & material related to Command's Lua interface

Moderators: RoryAndersonCDT, michaelm75au, angster, MOD_Command

Post Reply
boogabooga
Posts: 851
Joined: Wed Jul 18, 2018 12:05 am

"Hard" unit Unassign?

Post by boogabooga »

I'm trying to 'Unassign' a unit in LUA, in the same way as if I had physically pressed the key. However, it seems that the 'unitstate' attribute is read-only.

Specifically, I'm trying to get an aircraft to break off of a final approach.
The boogabooga doctrine for CMO: Any intentional human intervention needs to be able to completely and reliably over-ride anything that the AI is doing at any time.
KnightHawk75
Posts: 1850
Joined: Thu Nov 15, 2018 7:24 pm

RE: "Hard" unit Unassign?

Post by KnightHawk75 »

Not that I know of exactly. :(
And to be honest even pressing 'u', doesn't seem to completely clear a unit sometimes (mostly it makes sense but sometimes more is needed). Sometimes we need like a ctrl-u for like a full-NoIReallyMeanIt-clear.

What I mean is if a unit gets triggered Winchester\Shotgun and starts to rtb, but you 'u' to stop the rtb, let say for whatever reason you want this guy back in the fight\mission and he still has weapons (or you give him weapons again to make up for some ai fighting-you while you were trying to get it to do what you wanted it to do), well you can put the unit back into the mission or whatever but he will not act like before because 'u' doesn't clear the weaponstate reached flag.

I don't know of a way to officially clear it, short of landing, in LUA I think the workaround I did once was clear the group, clear the mission, unitwrapper:RTB(true); teleport the aircraft to home via HostToParent, then teleport him back to where he was, and then reassigning to the group, and reassigning to the mission.

Would be easier to do some more custom stuff if we had something that was similar\same as 'u', or really if we're gonna ask for that, maybe in the same vain we should do most of the orders that I think can't be done atm without lots of trickery if at all.
ScenEdit_SetUnitOrders({guid='',unassign=true}) -- 'u' (whatever u does today)
ScenEdit_SetUnitOrders({guid='',clearall=true}) -- 'ctrl+ u' (today +stateflags maybe cargo pickup queue too)
ScenEdit_SetUnitOrders({guid='',disenageCurrent=true}) -'e'
ScenEdit_SetUnitOrders({guid='',dropAllTargets=true}) 'ctrl+e'
ScenEdit_SetUnitOrders({guid='',layflare=true}) -- '?'
ScenEdit_SetUnitOrders({guid='',laychaff=true}) -- '?'
ScenEdit_SetUnitOrders({guid='',dropactivebouyover=true})
ScenEdit_SetUnitOrders({guid='',dropactivebouyunder=true})
ScenEdit_SetUnitOrders({guid='',droppassivebouyover=true})
ScenEdit_SetUnitOrders({guid='',droppassivebouyunder=true})
ScenEdit_SetUnitOrders({guid='',deploydippingsonar=true})
or just action=xx where xx is an enum 1 to 11. just spitballing here as if dev time were an unlimited resource. [:)]

boogabooga
Posts: 851
Joined: Wed Jul 18, 2018 12:05 am

RE: "Hard" unit Unassign?

Post by boogabooga »

I'm looking for a way to clear the 'on final approach' flag, whatever it is. So you are saying, "no"?

I'd like to simulate bolters for carrier ops where a certain percentage of landings are rejected.
The boogabooga doctrine for CMO: Any intentional human intervention needs to be able to completely and reliably over-ride anything that the AI is doing at any time.
KnightHawk75
Posts: 1850
Joined: Thu Nov 15, 2018 7:24 pm

RE: "Hard" unit Unassign?

Post by KnightHawk75 »

Assuming it's similar to clearing the "returning to base flag" that can get stuck on a unit that is rtb'd when already on the ground - try using HostUnitToParent() to clear. Again if you're trying to keep said unit in the air still then you'll of course need to put it back into the air after hosting it, or another option is just copy all the attributes you want to preserve to a table or whatever,remove the unit and recreate a new one using the saved attributes to reanimate the fresh one including reusing the guid if needed.

a semi how-to for that you can find in the mass change script I uploaded for someone a couple threads down https://www.matrixgames.com/forums/tm.asp?m=4908508 where the swap code in gKH.Side:ReplaceSingleUnit contained in it is basically a re-animator when source and dest unit dbid's are the same. obviously though you may need to extend the function more for you needs with more feature like copying doctrines and some other things it wasn't built for.
Steve04
Posts: 79
Joined: Tue Dec 01, 2020 1:36 pm
Location: Firenze - Italia

RE: "Hard" unit Unassign?

Post by Steve04 »

Assuming that I have a group of units, called "M113 Group", currently assigned to a mission called "M113 vs. Dardo" and that I want to disengage it ("unassigned" operation using the "U" key) and then assign it to a another mission called "M113 retreat", what is the exact syntax of the LUA command? Should we refer to the name of the individual units or also to the whole group?
And eventually can we do a direct reassignment to the second mission, without going through the "unassign" command?

Specifically how can I bind the
ScenEdit_SetUnitOrders command ({guid = '', unassign = true})
to my specific unit / group?
Thank you.

User avatar
michaelm75au
Posts: 12455
Joined: Sat May 05, 2001 8:00 am
Location: Melbourne, Australia

RE: "Hard" unit Unassign?

Post by michaelm75au »

To un-assign
local u = ScenEdit_SetUnit({name='Seeker #1', guid='7a3b7dce-abe1-4b60-b0d5-b0f27510d4de',mission=''})
print (u.mission)


To assign directly. just 'mission="mission name or guid". Should not need to blank it first.
u = ScenEdit_SetUnit({name='Seeker #1', guid='7a3b7dce-abe1-4b60-b0d5-b0f27510d4de',mission='Rescue'})
Michael
Steve04
Posts: 79
Joined: Tue Dec 01, 2020 1:36 pm
Location: Firenze - Italia

RE: "Hard" unit Unassign?

Post by Steve04 »

Thank michael.
So, in my case, it should sufficient to substitute the names of units and mission, so:
local u = ScenEdit_SetUnit({name='M113 Group', guid='7a3b7dce-abe1-4b60-b0d5-b0f27510d4de',mission=''})
print (u.mission)
Directly:
u = ScenEdit_SetUnit({name='M113 Group', guid='7a3b7dce-abe1-4b60-b0d5-b0f27510d4de',mission='M113 retreat'})
Copying the string directly in the Action / LUA Script window...

PS. I honestly don't know what that string of numbers means, if it's always the same or if it changes for every situation ...?
User avatar
michaelm75au
Posts: 12455
Joined: Sat May 05, 2001 8:00 am
Location: Melbourne, Australia

RE: "Hard" unit Unassign?

Post by michaelm75au »

The 'guid' is the unique identifier of the 'unit'. Names can be sometimes be duplicated which can lead to issues. Use either 'GUID' or 'name & side' to identify units.
In your case drop the guid.
Michael
Steve04
Posts: 79
Joined: Tue Dec 01, 2020 1:36 pm
Location: Firenze - Italia

RE: "Hard" unit Unassign?

Post by Steve04 »

So michael... which are the correct commands ?

EDITED
I tried with GUID
local u = ScenEdit_SetUnit({name='M113 Group', guid='7a3b7dce-abe1-4b60-b0d5-b0f27510d4de',mission=''})
print (u.mission)
and without GIUD
local u = ScenEdit_SetUnit({name='M113 Group',mission=''})
print (u.mission)
but it doesn't seem to work
the unit is not "unassigned" and continues to operate with the mission.[:@] The correlated "unassign" event remains "active" and therefore does not trigger...
I suspect that the command does not recognize the unit to be assigned, by its name.
So I also ask, how do you find the Guid (individual code) of a unit?
KnightHawk75
Posts: 1850
Joined: Thu Nov 15, 2018 7:24 pm

RE: "Hard" unit Unassign?

Post by KnightHawk75 »

Steve04 for your situation and scene (the one you posted a couple days ago) specifically there is no real or easy solution available that fits exactly what you want to happen with the ground units (them to immediately disengage), such a command does not exist, it should in my opinion but it doesn't.

Steve04
Posts: 79
Joined: Tue Dec 01, 2020 1:36 pm
Location: Firenze - Italia

RE: "Hard" unit Unassign?

Post by Steve04 »

Knighthawk, it's hard to admit, but I'm starting to think it's really not possible to assign ground units to a mission other than the one they were originally assigned to.
I emphasize "ground units", because with air units this is possible.
I just wish some of the developers would confirm this problem, take note of it and possibly try to fix it with the next versions.
User avatar
michaelm75au
Posts: 12455
Joined: Sat May 05, 2001 8:00 am
Location: Melbourne, Australia

RE: "Hard" unit Unassign?

Post by michaelm75au »

I'll check on the 'facility' mission aspect. I thought it was catered for.
Michael
User avatar
michaelm75au
Posts: 12455
Joined: Sat May 05, 2001 8:00 am
Location: Melbourne, Australia

RE: "Hard" unit Unassign?

Post by michaelm75au »

I have created a simple scenario to show that mission switching does work for ground units too.
Load it and run the Lua commands to see the ground unit switch between missions.
Attachments
Changeof..mission.zip
(8.39 KiB) Downloaded 9 times
Michael
KnightHawk75
Posts: 1850
Joined: Thu Nov 15, 2018 7:24 pm

RE: "Hard" unit Unassign?

Post by KnightHawk75 »

Knighthawk, it's hard to admit, but I'm starting to think it's really not possible to assign ground units to a mission other than the one they were originally assigned to.
---
Nah that's not the problem AT ALL.
You can assign them to different mission easy peezy ScenEdit_AssignUnitToMission(UnitNameorGuid, "Italy_Withdraw"); for instance. The problem you have is one of the engagement not ending quickly and in the way you desire - if this is the same scene you posted about a few days ago("ScenarioTest 1 Limited ark OK"). That ground units don't have an base and as such the RTB command that would usually trigger the disengagement can't be use as klutch here like it can in the air or see made producing the exact scene you desire more complicated then it might otherwise be.

Your scene specifically, mission switching doesn't have the desired immediate un-engage effect you want the way you want it due to other factors, one has to determine the opposing party in the engagement and flip that party as well, including plotting a new course to have the desired effect for your scene. I also noticed "ignore plotted course when attacking" upon mission change was also not being inherited like it in theory should from the newly assigned mission, which while not "complicated" to reapply made for some additional steps.

I was screwing around a couple days ago trying to get the exact thing you want and it seemed more difficult than it was worth for 'exactly the way you want' ... with out play-play scripting every piece of the scene, who engages whom and when etc etc that isn't worth the effort imho. I could however get something close to what you wanted and when I get some time later tonight I'll post your scene (from that other thread) with my modifications and scripts you can look at that approximates sort of what you're goal was - it's was very tricky to get it working along with the % damage aspect, and while the scripts aren't complicated it's more than a few lines. I had not posted yet because it was complete. I got as far as the first cycle kind of working the way you wanted and needed to still script the repair and re-engagement portions you wanted. Give me a couple hours as I have to get back into the head space of that scene from other things I'm doing. ;)


KnightHawk75
Posts: 1850
Joined: Thu Nov 15, 2018 7:24 pm

RE: "Hard" unit Unassign?

Post by KnightHawk75 »

Steve04, spent the night working on that concurrent events issue\challenge, need sleep and another day to get back to your stuff. sry.
Steve04
Posts: 79
Joined: Tue Dec 01, 2020 1:36 pm
Location: Firenze - Italia

RE: "Hard" unit Unassign?

Post by Steve04 »

Michael and KnightHawk, you are truly splendid and priceless for the help you are giving, which testifies to your great passion, in the spirit that animates this forum.
Now I test the scenario developed by Michael and try to understand how I can exploit it for my definitive goal which, as mentioned in the main thread ("About ground combat" in Tech Support) and is to extend the life of the units in ground clashes, even by making short or slower fights, interrupting the battles, making retreats, supplies, repairs and then returning to battle again.
In this process, the ability to reassign units to another mission - thus bypassing the impossibility (so it seems ...) to interrupt an attack mission - can be an important first step.
Thanks for the work you are doing.
KnightHawk75
Posts: 1850
Joined: Thu Nov 15, 2018 7:24 pm

RE: "Hard" unit Unassign?

Post by KnightHawk75 »

@Steve04

Attached is mostly working prototype of what you wanted.
Needless to say it was more involved than even I thought it would be, namely due to:
-A Lack of a 'disengage (drop all)' in Lua. this is actually biggest problem as mentioned already and a recurring issue.
-B 1 definite bug in the software (I'll be reporting it shortly) - unit.damage.dp_percent is not updated upon repair even if the actual unit\gui is. This was the single biggest head ache.
-C A feature of triggers not working as I would expect, ie you can't trap every 'damage' for a side broadly, only damage events of a type\specific amount. trigger, and even after that it will not trigger again upon 'more' damage. This is in-artfully solved by defining a trigger for every unit. I may submit a feature enhancement request for this, something like [X] trigger fires on every event, or 0 threshold actually triggers for every event. Additionally for in-area-triggers, they seem to only fire on the first unit unit matching the condition at a time, even if the condition is broad. I kinda get why that is the way it is, but again wish there was a way to say "fire this for each unit matching the condition" instead of the "any" way. This worked around with a In-area-trigger for each unit, so that two units can be in the area at the same time and get repaired at roughly the same time without having to wait for one to leave first.

-D 2 features just not consistently working (patrol zones area and prosecution zone areas not working for ground units like they do for aircraft), and not breaking engagements when reaching those limits. if A existed this would be fairly easy to workaround.
-E A minor issue of units swapped from one mission to another NOT INHERITING their ignored plotted course setting even when they were previously set to at unit and prior mission level. idk if that's by design or not, minor issue easily scripted around.
-F An issue with ScenEdit_SetDamage, that actually doesn't really effect this scene in a breaking way but which complicates repair logic in general. Basically DP=X value is internally getting converted to a integer instead of a float or double or decimal. So negating damage "exactly" is impossible, and workarounds that don't end up destroying the unit had to be made.

However I still somehow manage to code around all these issues and get something like you wanted. It's hard to explain all the reasons why so much code exists in this sample but the TLDR of it is 50+% of it is to attempt to "work around" A-F, and even it's not perfect though with more time and more code and a couple more events to control other events sure one could get there. In fact if I had to start over I would refactor some of what is included here but half of it was done before coming across certain problems.

Anyway... In the attached the 2 units on each side will engage each other for like an hour+, this all depends on settings and some inherent randomness. Upon each unit taking damage said unit will "disengage and head home on a withdraw mission", he will also tell his opponent if that opponent is 'targeting' him still to do the same - no matter if that opponent is damaged or not, and that opponent will check for anyone targeting himself and do the same (this is recursive so to speak, though it's capped at one cycle deep). The "disengagement" problem is solved in two ways, the first is a mission swap + course setting toward the units own "safezone", which doesn't do jack for breaking most engagements...so I invented something else that will that sucks but works - dropping the opposing contacts who are being targeted. There is alot of code related to that because while it's "simple enough", obtaining the right contact object in a semi performant way who is being targeted is a little involved. The main reason it "kinda of sucks" is less about this specific sample and more that we're dropping contacts for the side regardless of who is actually targeting that contact, so in broader sample\scene, this is a sledgehammer approach with lots of downsides - but hey....it got the job done.


Now how is damage trapped for if not by triggers, welp every second we lookup all mobile-vehicals and investigate thier damage (and update our records from the last second - if needed), if it's changed then we trigger the aforementioned damage procedure. The things is because of problem B this is NOT reliable and beyond other problems it causes in the case of the above if a unit has already repaired say from 33% damage to 0, welp we know it's really 0, but the unit will keep telling us it's 33% and it will not update till the there is a true damage event in the system (I mean cmo core code here). SO you will see at time a "repaired" unit on his second encounter may not actually "disengage" till he takes damage that causes < or > his previous damage amount. Ie if he took 33% went home to repair now get's hit again to cause 33% damage we'll not pick up that change till he take another hit say... bringing him to 66% or 20%. Just wanted to put that out there in case you wonder why the behavior in the scene is what it is.

Now on the repairs, each side is capped to a maximum number, and counts are kept, including saved to the file (that is if you save the running example and reload it - just make sure you have the original saved as different filename).

These variable are at the top of the SceneLoad - Startup script that help control things
gKH.SceneGlobals.dbglevel
gKH.SceneGlobals.ItalyMaxRepairs = 8; -- max number of times Italy units in total can repair.
gKH.SceneGlobals.TunMaxRepairs = 8; -- max number of times Tunisian units in total can repair.
gKH.SceneGlobals.ItalyRetreatDmg = 30.0; --if dmg >= this then abort engagement
gKH.SceneGlobals.TunRetreatDmg = 30.0; --if dmg >= this then abort engagement
gKH.SceneGlobals.ItalyRepairCounter = 0; --gets saved to file and reloaded from file if exists.
gKH.SceneGlobals.TunRepairCounter = 0; -- gets saved to file and reloaded from file if exists.
gKH.SceneGlobals.ItalyRetreatWaypoints = {[1]={latitude='37.048966', longitude='11.015755'}}; -- where to go manually when withdrawing
gKH.SceneGlobals.TunRetreatWaypoints = {[1]={latitude='36.954446', longitude='10.974709'}}; --where to go manually when withdrawing
gKH.SceneGlobals.ItalySafeZoneRPs = {"RP-750","RP-751","RP-753","RP-754"}; --use overcome some complicated bugs and non-feature in CMO.
gKH.SceneGlobals.TunSafeZoneRPs = {"RP-762","RP-763","RP-764","RP-765"}; --use to overcome some complicated bugs and non-feature in CMO.
gKH.SceneGlobals.ItalySideGuid = 'IEUKQL-0HM6UAV36E6VC'; --guid id of this side as opposed to name- used during contact related ops
gKH.SceneGlobals.TunSideGuid = 'IEUKQL-0HM6UAV36E6VE'; --guid id of this 'side' as opposed to name - used during contact related ops

Some notes about these:
- The MaxRepairs values are tricky because of prior mentioned problems "repairs" have to allowed to run while in the safezone no matter if they are needed or not - because we can't actually know for sure because unit.damage.dp_percent is half broken. Because of this a side can get charged twice or even 3 or 4 times per-repair if they hang out in the safezone long enough. However I make some attempts to prevent it but they'll not always work. There are ways I could make it work by switching to an event per-unit and disabling the in-area event for that unit while in the zone and having another per-unit NOT-in-area event flip it back on or do that only when disengagement is called, but I didn't cause I was trying to avoid relying on per-unit events and triggers as much as possible and it would tie triggers to unitguids or unitname which again I was trying to avoid, but if starting over I probably would go that route as it would save more code that it would cost and probably work better. If both sides are over over the MaxRepair's then "disengagements" are disabled.
TLDR = give each side at least double the repairs you really want them to have as a guide.

- RetreatDmg vars - Set this to the amount >= in which you want to trigger a reteat on the taker (who also then triggers retreat on his attackers)
- I think the waypoints are self explanatory just remember if you move the safe-zone RP's around make sure the waypoint\course location is updated to still be inside them.
- Similarly with the SafeZoneRps var's - if you re-name the RP's or change them they must be changed here. I could pull them dynamically from the mission, but for simplicity I did not.
- The SideGuid vars - These are absolutely critical to screwing with and matching contacts, if you delete a side and recreate them they'll need to be changed, similarly throughout the code "Italy" and "Tunisia" exist, I should have made those vars of side1 and side2 but I didn't so those will need to change if side names are changed, probably a dozen places.


This again is just a sample to show this 2v2 engagement\withdraw\repair\re-engage \withdraw\repair loop thing can kinda...sorta be done, it would be easier in the future with a couple cmo fixes\enhancements.

I've tried this scene over and over again with and without enabling the various mission setting about staying in the patrolzone and weapon ranges and while initial targeting does seem to obey the patrol zone (not PRZ), no engagement is ever actually broken that I ever saw when leaving the PZ or prosecution zones be they the targets or the units on their own -without assistance from code anyway.

Special actions - There are 5, 4 related to the debugging log settings, and one to clear the repair count keys from any save (it also reset them in the loaded scene). The logging levels are 0-3 and controls how much stuff is logged to your logs\lua-history-thedate.log file, don't use 3..lol, 2 is pretty insane still when things are actually happening but if you want to follow the code it's like a play-by-play. 0 - is basically errors only, and 1 is maybe all you want to really have on when not trying to track something down or see how things work. 10-15% of the code is all about logging - hey I like to know when and why things are breaking while I work, what can I say. ;)

Events -
SceneLoad - Loadup the main code, execute bootstrapping routines.
ScanForDamgeEverySecond - The trigger and actions associated with looking up everyone's damage constantly.
ItalyRepairs - contains the two triggers and one action associated with detecting when in safezone and kicks off possible repairs.
TunRepairs - contains the two triggers and one action associated with detecting when in safezone and kicks off possible repairs.

Let me know what you think, I'm not "happy" with it (more improvement could be made even as is in 1147.25) but does show one way of how it can be done without actually scripting out each and every shot fired. Playing repeated sessions the whole engagement should last about a least an hour with 30% damage and max repairs set to 8, with Tunisia losing more often than not.

(updated ~10am) attachment: KH1h_Scenario-test-1-Limited-atk-OK.zip (contains .scen and the global functions startup script, event action code have to look inside the scene for though those are pretty simple small snippets that call the rest)
Attachments
KH1h_Scena..d-atk-OK.zip
(97.87 KiB) Downloaded 9 times
Steve04
Posts: 79
Joined: Tue Dec 01, 2020 1:36 pm
Location: Firenze - Italia

RE: "Hard" unit Unassign?

Post by Steve04 »

Dear KnightHawk you have done a great job and a great research!
Thank you so much for your work, I believe not only from me but also from the CMO community.
I have read carefully what you wrote, although I must honestly say that, in some cases you eviscerate problems and propone solutions that are beyond my technical knowledge (apart some difficulties in correctly understanding some concepts into my mother language), but I can certainly admire the deep and detailed way in which you face and try to solve problems.
I am amazed at how, in my small way, and trying to achieve very simple things by the A.I.- like interrupting a fight when certain situations occur, reassignign units to other missions... - has brought to show the problems and gaps that were unthinkable in CMO. At least I believe that, thanks largely to your help, certain issues can be considered and resolved in one of the next versions.
As for the scenario you have attached, however, I have tested 2-3 times, without finding the expected behavior by the units engaged in combat. After just three minutes from the start, the two Tunisian units were targeted and destroyed.
Maybe I need to do some work on the scene before starting to activate the introduced functions ?
In the same time I want to tell you that for a few days I will not be able to access CMO, so thank you again and see you later ...
Steve.
BDukes
Posts: 2577
Joined: Wed Dec 27, 2017 12:59 pm

RE: "Hard" unit Unassign?

Post by BDukes »

Yeah thanks from me too. You're a good one for helping make lua more accessible to others and helping the coders with some things.

Mike
Don't call it a comeback...
KnightHawk75
Posts: 1850
Joined: Thu Nov 15, 2018 7:24 pm

RE: "Hard" unit Unassign?

Post by KnightHawk75 »

First question: Are you using build 1147.25 or an earlier one?

Second question I update the .scen file to a newer version about 2hr after posting ( I found another interesting weirdness with certain command and fixed it), so if you downloaded the zip file in the first too hours you got version kh1g... try kh1h. version 1g was definitely broken and would have caused what you saw, something I saw myself soon as I restarted CMO which I'd not done for like 2 days. If that one (kh1g_scenario-test-...) is not showing the behavior mentioned in the other post, then please check your <cmo install path>\logs\lua-history-todaysdate.log file. Maybe something is blowing up (you can zip it and attach it if nothing is obvious in there), that i didn't account for, but I'd be surprised, and yet not so surprised at the same time. [:)] I'm assuming you're just letting it play out as is without introducing other factors like aircraft attacking etc.

Lastly after posting I think I've found a workaround for most of the the whole dp_percent field not updating problem. You can see what I'm thinking for work around in the recent tech support threads.



Post Reply

Return to “Lua Legion”