Checking an aircraft in flight for RTB (5% chance)

[KnightHawk75]

Warning wall of text inbound. [:D]

When it comes to testing in the console vs inside events with randomness... there can be issues. Search the lua sub forum for 'randomseed' and you'll see me and Whicker finding differing results in console\special action vs inside an event at one point, that was in cmano but wouldn't surprise me if holds true still depending on what's being done.

For example if RTB is a "Condition" is there a list of "Conditions" in Command? If so Where?

There is no official documented list (that I know of), that said here is the list that I've come up with some investigation.

The first is the .condition possibilities (not to be confused with unitstate - which is more the fuller text of the status field in the gui)
What follows after the comma is the .condition_v associated value (the base state, since .condition has different text depending on context)


Aircraft:
"Airborne", Airborne
"Parked on flight deck", Parked
"Parked in hangar", Parked
"Parked", Parked
"On elevator, enroute to takeoff", TaxyingToTakeOff
"Taxiing to take off", TaxyingToTakeOff
"On elevator, enroute to parking spot", TaxyingToPark
"Taxiing to parking spot", TaxyingToPark
"Taking off", TakingOff
"On final approach", Landing_PreTouchdown
"Completing landing", Landing_PostTouchdown
"Readying", Readying
"Waiting for available taxiway/elevator", HoldingForAvailableTransit
"Waiting for runway to become available", HoldingForAvailableRunway
"In landing queue", HoldingOnLandingQueue
"Returning to base", RTB
"Preparing to launch", PreparingToLaunch
"Manoeuvering to refuel", ManoeuveringToRefuel
"Refuelling", Refuelling
"Offloading fuel", OffloadingFuel
"Deploying Dipping Sonar", DeployingDippingSonar
"Chicken, critically low on fuel", EmergencyLanding
"On elevator, enroute to flight deck", TaxyingToFlightDeck
"Moving to flight deck", TaxyingToFlightDeck
"Executing BVR attack", BVRAttack
"Cranking", BVRCrank
"Dogfight", Dogfight
"Transferring Cargo", TransferringCargo
"Dragging", BVRDrag

Ship or Sub:
"Underway", Underway
"Docked", Docked
"Deployment Underway", DeployingUnderway
"Docking", Docking
"Returning to base", RTB
"Readying", Readying
"Manoeuvering To Refuel", ManoeuveringToRefuel
"Replenishing", Replenishing
"Providing UNREP", ProvidingUNREP
"Recharging Batteries", RechargingBatteries
"SettlingForCargoTransfer", SettlingForCargoTransfer
----
So when it comes to RTB checking it looks like checking .condition_v == 'RTB' is the way to go for testing rtb status cleanly(?).
As for pathing issues after rtb'ing, that's a totally separate problem. lol One thing at a time. [;)]


The rest of what you posted... give me a ~day (about to go sleepytime), I want to flesh out and test something out before replying though.

[jkgarner]

KnightHawk75,

Thanks for the listing of unitStates:

Aircraft:
"Airborne", Airborne
"Parked on flight deck", Parked
"Parked in hangar", Parked
"Parked", Parked
"On elevator, enroute to takeoff", TaxyingToTakeOff
"Taxiing to take off", TaxyingToTakeOff
"On elevator, enroute to parking spot", TaxyingToPark
"Taxiing to parking spot", TaxyingToPark
"Taking off", TakingOff
"On final approach", Landing_PreTouchdown
"Completing landing", Landing_PostTouchdown
"Readying", Readying
"Waiting for available taxiway/elevator", HoldingForAvailableTransit
"Waiting for runway to become available", HoldingForAvailableRunway
"In landing queue", HoldingOnLandingQueue
"Returning to base", RTB
"Preparing to launch", PreparingToLaunch
"Manoeuvering to refuel", ManoeuveringToRefuel
"Refuelling", Refuelling
"Offloading fuel", OffloadingFuel
"Deploying Dipping Sonar", DeployingDippingSonar
"Chicken, critically low on fuel", EmergencyLanding
"On elevator, enroute to flight deck", TaxyingToFlightDeck
"Moving to flight deck", TaxyingToFlightDeck
"Executing BVR attack", BVRAttack
"Cranking", BVRCrank
"Dogfight", Dogfight
"Transferring Cargo", TransferringCargo
"Dragging", BVRDrag

Ship or Sub:
"Underway", Underway
"Docked", Docked
"Deployment Underway", DeployingUnderway
"Docking", Docking
"Returning to base", RTB
"Readying", Readying
"Manoeuvering To Refuel", ManoeuveringToRefuel
"Replenishing", Replenishing
"Providing UNREP", ProvidingUNREP
"Recharging Batteries", RechargingBatteries
"SettlingForCargoTransfer", SettlingForCargoTransfer

In general, I have found the official documentation lacking when it comes to enumerating the potential values of variables such as the unitState.

This makes it more difficult for the novice to write correct code and can be frustrating.

[BeirutDude]

YES! jkgarner beat me too it, but this is very much appreciated.

[BeirutDude]

When it comes to testing in the console vs inside events with randomness... there can be issues. Search the lua sub forum for 'randomseed' and you'll see me and Whicker finding differing results in console\special action vs inside an event at one point, that was in cmano but wouldn't surprise me if holds true still depending on what's being done.

Well this explains a LOT! Interestingly I've noted a pattern where it seems to be the landed aircraft that trigger over and over. I think an Airborne Check might help? I'm going to try some code on it.

[BeirutDude]

So tried adding an If statement to check for the aircraft being airborne and got this.


>> Konge_1SystemsCheck = 0

local Konge_1 = ScenEdit_GetUnit({ guid='XMJRWB-0HLVVBRGSPOG6'})

if Konge_1:Airborne(true) then

Konge_1SystemsCheck = math.random(1,20)

if Konge_1SystemsCheck == 1 then

Konge_1:RTB(true)
ScenEdit_SpecialMessage ('NATO', 'Konge 1 reports it is suffering from a engine systems failure.')
end
end

Konge_1SystemsCheck = 0
ERROR: [string "Console"]:5: Trying to invoke invalid method or an access an invalid index

Not sure the difference between the RTB and Airborne? Why does one work and the other fail???????

[KnightHawk75]

@jkgarner - just note those were not .unitstate, those were .condition and .condition_v., even though I mentally call .condition unitstate and mentally call .unitstate 'status'.

post#25 - " Konge_1:Airborne(true) " is the problem. "if konge_1.condition_v == 'Airborne' the " is probably what you want.

Hold off a bit though from banging your head, I'm rewriting all this in a generic reusable function for you (or others me included) actually series of functions, I should have it in testable state in a few hours, I'm also adding lots of comments so you can follow along and understand what most of the lines do, and why.

[BeirutDude]

if konge_1.condition_v == 'Airborne'

Thanks, I appreciate the help, especially the teaching!

[BeirutDude]

Got the Airborne working fine (THANK YOU) but I set the math random function to a 1/1000 chance math.random (1, 1000) and it still fires every time the test is done! Crazy!

local Konge_1 = ScenEdit_GetUnit({ guid='XMJRWB-0HLVVBRGSPOG6'})

if Konge_1.condition_v == 'Airborne' then

Konge_1SystemsCheck = math.random(1,1000)

if Konge_1SystemsCheck == 1 then

Konge_1:RTB(true)
ScenEdit_SpecialMessage ('NATO', 'Konge 1 reports it is suffering from an engine systems failure.')

end
end

ALSO, when posting here how do I get the post to properly indent?

[CapnDarwin]

Al,

Try math.randomseed to seed the random generator and see if that gets it not rolling a 1 all the time.

[KnightHawk75]

Incoming wall of text warning.[;)]
edit: oops I replied to wrong person, meant to reply to @BeirutDude

Ok so attached in the zip are 2 files, the Scene file (Testbed_RandonUnitEngineFailure_db483_ver1_1_1.scen) and gBDude.lua.

The .lua is provided so you can examine the meat of the startup code contained in the testing scene in another editor without having to copy paste etc. It's also handy for doing a ScenEdit_RunScript() call to make changes on the fly via the lua console in the game.

The Testrig contains a basic blue side and red side with some bases and ports for each.
Each side has a bunch of aircraft,subs,ships, including some inside the bases and ports. They both have the same units.
There are 2 basic missions for each, one tanker\aew and a cap. If you want to "reset" the scenario in the special actions execute the CleanScenarioUnits option, then the CreateScenarioUnits option should appear. It doesn't matter what side you're currently on I duplicated all the SA's on both sides to save some switching back and forth.

Now onto your new gBDude.RandomUnitEngineFailureRTBCheck(p) uber function.

First I'll describe what it does and can do, then I'll throw down some examples with parameters, but contained in the .scen there are a bunch of Event Actions that you can look at that show off all the different parameters you can use. The function will operate depending on what you feed it for 'mode'. In 'TBL' mode it will loop over a custom table you provide it of units you want checked. In 'SIDE' mode, it will loop over the units of the sideName you provide it. By default when in SIDE mode, it will search all subs,ships, and aircraft, however should you only want a subset of that you can inform the function of that via a unitType parameter which can be one of those keywords. I've made an effort to make sure CapiTals don't matter in the text you feed it for that or mode, though it does matter for the parameter names. Additionally you can specify the pctChance parameter to adjust the % you want per call, the default is 5%, valid values are 1-99. Also you can set a maxLimit parameter that will control how many 'actions' (aka rtb's) it will allow itself to do per call. The default is 1, 0 means unlimited. In the test rig scene I alternate between using 5% and 10% and 1, or 2 maxLimit. Upon successfully doing something it returns a table containing the guid,name,side,and unittype of all the entries it performed an action on, if things went well but no units qualified or got a matching dice roll then the table is empty. If something went really really wrong nil is returned.

The process. First thing it does it checks all the parameters you feed it, including any tables and does it's best to validate the input, and where possible if things are missing infer the correct settings\defaults, if it finds a major problem it will stop and print to the log exactly what the problem was. So like if you only have sides red\blue in the scene, but you feed it green as sideName...it's going to tell you to fix that.

During it's search it will process each unit specified, first it'll check if the unit qualifies, for a sub or ship that means its 'Underway' or 'Recharging batteries', for an aircraft it's 'Airborne', any condition state other than those and the unit is disqualified and it moves on to the next unit. If it does qualify then a random number is generated, you will see in the gBDude.RandomEngineFailureDiceRoll(pct) function i adjust randomseed on every call, this ?should?\?seems? to avoid the 'randomseed inside events problem'. if the generated number is < = to our roll then we go ahead and take the action, but only if we're not over our maxLimit. The only action at the moment is get the unit object and triggering RTB. However if people are interested I can flesh out making Ferry Mission assignment an optional mode. Anyway, upon triggering the RTB, that unit's data gets recorded in the return table.

The parameters:
So i've made it easy so you can just call gBDude.FailureRTBCheckParams.new() to give you a pre-made table with all the default parameters as fields. You can equally call it to set 1 or more parameters inline, and should you forget parameter names you can just print() what .new gives you to see them.

inline method:
local params= gBDude.FailureRTBCheckParams.new(mode,tblOrSidename,pctChance,maxLimit,unitType)
Note anyone of them can be left out, whatever is left out or nil will use defaults.
local params= gBDude.FailureRTBCheckParams.new('SIDE','Blue',nil,nil,'aircraft') --is valid.
local params= gBDude.FailureRTBCheckParams.new('SIDE','Blue') --is valid. etc.

The way most my examples in the scene use it:
local params= gBDude.FailureRTBCheckParams.new(); --is valid
params.mode= ['TBL' or 'SIDE' string] default is TBL
params.pctChance = [1-99 number]
params.tbl= [a table or variable reference to var that holds a table.; defaults to nil].
params.sideName = [the string name of a valid side] default is nil.
params.unitType = ['ALL','Aircraft','Ship','Submarine'] default is 'ALL'
params.maxLimit = [number 0 or greater; 0 signified no-limit] default is 1.
params.action = hardcoded to 'RTB' at the moment, 'Mission' not implemented yet.
params.missionPrefix = Not implemented yet.

simple usage example to check all of side blue:
local params= gBDude.FailureRTBCheckParams.new('SIDE','Blue')
local returnedTable = gBDude.RandomEngineFailureRTBCheck(params)

simple usage example to check all aircraft of side red,with 10%,and maxLimit of 2:
local returnedTable = gBDude.RandomEngineFailureRTBCheck(gBDude.FailureRTBCheckParams.new('SIDE','Red',10,2,'aircraft'))

simple usage example to check two specific units, one by guid, one by name+side:
both at 10% and then also check blue subs at 2%.
local mytable = {{guid="abcdef-ghijklmnopqrs"},{side='Red',name='SomeUnit #3'}}
local params= gBDude.FailureRTBCheckParams.new('TBL',mytable,10)
local returnedTable = gBDude.RandomEngineFailureRTBCheck(params)
params.mode='SIDE';
params.sideName='Blue';
params.unitType='Submarine';
params.pctChance=2;
returnedTable = gBDude.RandomEngineFailureRTBCheck(params)

What makes a valid custom table\entry to feed it? Pretty simple you need either a 'guid' field that is not empty, or both a name and a side field, you can include all 3 but if guid exists it will always be used over the other two. Lets at a sample.
{
{side='Red', name='Red F-22 #1'}, --valid
{side='Red', name='Red F-22 #2'}, --valid
{side='Blue', name='Blue F-22 #3'}, --valid
{side='Blue', name='Blue F-22 #4'}, --valid
{side='Red', name='Red KC-10A #1', guid='4FH7PU-0HM01PAHCTPBF'}, --valid but only guid will be used.
{guid='4FHRED-KHCUSTOM0TPBF',name='Red CustomGUID'}, --again technically valid, but only guid will be used.
{guid='4FH7XU-0HM01P8HCTPBF'}, -- perfectly valid. btw if a unit\guid does not exists that's ok function handles that.
{side='Red',guid=''} --NOT valid, it has a side but no name value and,
-- more importantly it has an empty guid. this will fail the validation check that runs before the function really starts.
}

You probably get the idea by now. I tried to make as flexible as possible without going to overboard.
There is one line at the very top the script you might want to try changing or you actually just change it on the fly in the console since it's global, just don't set it to nil. gBDude.dbglevel = 1; Set it to 2 or 3 to see a lot more in the logs,0 for minimal.
I've left a fair amount of comments in the code maybe more than needed in some areas and maybe a little less then than needed in others.

As for the testrig .scen I ran all sorts of variations, the baseline inside an event without re-seeding was definitely a problem (I was getting the same sequences repeatedly like you, but not when run interactively). After forcing a reseed no matter if I was reseeding before for-looping through units or setting a new one on every single random call it seemed to go away, though I left it per-diceroll. Just eyeballing while logging the numbers it seemed the most random. Though I saw some a weird run or two where 5 units got rtb'd out of 10 on a 10% chance (wtf?), but that didn't happen consistently, and far as I could tell no one unit kept getting predictably hit. That said it could use some more testing, most of mine was done at 15sec intervals while staring at the log, pausing, un-rtb'ing, and pressing play again. Anyway if nothing else there is shared scene and code compare specific results with. By default on scene load it'll run an event every 1minute that checks 8 or 10 units in a custom table containing blue units. Have full playing around with the different options.

[BeirutDude]

Thank you! [&o] [&o] [&o] [&o]

Trying to digest this right now! I'm SURE I'm going to have LOTS of questions. I have to look at my licence each morning to remember who I am! [:D]

Honestly thanks for your help and its going to take me a while looking this over. Downloaded the ZIP.

[KnightHawk75]

ALSO, when posting here how do I get the post to properly indent?

In normal forum text you kinda can't I don't think. But if you wrap it in a code block (see 'code' button in reply dialog) it usually sticks... though you might have to break things up into multiple blocks, I often have to do that if it's longer than 10-15 lines.

Code: Select all

 local Konge_1 = ScenEdit_GetUnit({ guid='XMJRWB-0HLVVBRGSPOG6'})
 if Konge_1.condition_v == 'Airborne' then
     Konge_1SystemsCheck = math.random(1,1000)
     if Konge_1SystemsCheck == 1 then
         Konge_1:RTB(true)
         ScenEdit_SpecialMessage ('NATO', 'Konge 1 reports it is suffering from an engine systems failure.')
     end
 end 
 

[KnightHawk75]

ORIGINAL: BeirutDude

Thank you! [&o] [&o] [&o] [&o]

Trying to digest this right now! I'm SURE I'm going to have LOTS of questions. I have to look at my licence each morning to remember who I am! [:D]

Honestly thanks for your help and its going to take me a while looking this over. Downloaded the ZIP.

Your welcome, and take your time, you're not wrong it's a lot to digest.

[jkgarner]

This is some good stuff...
lots of useful tricks (parameter checking, pseudo namespaces, default parameters)
and all well commented for understanding.

thanks

[KnightHawk75]

ORIGINAL: jkgarner

This is some good stuff...
lots of useful tricks (parameter checking, pseudo namespaces, default parameters)
and all well commented for understanding.

thanks

Thanks. yeah lots typos in the comments looking back on it now I'll try to clean some of them up when\if I go back in to add the mission assignment parts, but something is usually better than nothing. I'm fan of pseudo namespaces now that cmo does not clean up the environment between scene loads, a potential for conflict exits now, even though in theory one scenes on-load of global vars and functions should overwrite prior scenes copies with the same name, but there are cases where issues can still come up unless one is very careful.

On that note I'm trying in a longer term person habit\project to pull together all my personal scripts (and some from others with credit) that have some generic use under a sort of larger api framework. Atm i call it gKHApi and then split all my files up and load\register them in a semi organized namespaces like gKH.base,gKH.Sensors, gKH.Comms,gKH.Movement,gKH.Waypoints,gKH.Unit, gKH.Database, etc That way I only load what's needed for any given scenario during startup by running the script from file, and each sub namespace knows the other namespace requirements for itself and checks if they exist first before loading. Maybe sometime I'll give a preview of the whole thing in some sample scenario or just upload it to github where people can just grab what they find useful. Would be so much easier if the default 'module' and some other basic features in lua were available, but they are restricted in the commercial version for presumably security reasons the same that all the io and load functions are so been trying to find workable ways to overcome that. The down side is it assumes it's folder and files exist under \lua\gkhapi and making people copy things into folders while shouldn't be a challenge seems to be if judging just by beta release threads.

But back to the topic..

Before I add the addition of the MISSION action option, I should explain what I'm thinking it'll do and maybe you guys can tell me if it's even worth adding or useful? So the idea is you set the action parameter to 'mission', and when set to mission instead of rtb'ing, it will assign the unit to a mission instead of RTB which the dice hit them.

Which mission it gets assigned to will depend upon what home base (unit.base) the unit has, and what the missionPrefix parameter is set too. So let's say unit#1 is based out of Airbase1, and misisonPrefix = 'Ferry_' it'll lookup the unit's base and then look to see if a mission "Ferry_Airbase1" exists, and if it does it will assign the unit to that mission, if does not it will print an error that the mission doesn't exist and move on with processing. Optionally... I could just have it create the ferry mission if it doesn't exist... but then we get into what parameters should that ferry mission have, and should it ever get removed?

Another option I thought of is when dealing with a custom TBL mode vs SIDE mode which I had in mind above, just allowing an additional action= and mission= entries in the user supplied table, in that case it'll try and first use those settings, which will allow far greater flexibility such that one can mix and match what they want done per-unit, with RTB being the default if missing.
{guid='ABSOME-GUID123456789',action='RTB'}
{name='Some Unit #1',side='Red',action='Mission',mission='FerryToSomeAirport1'}
{guid='ABSOME-GUID12345678A',action='Mission',mission='FerryToSomeOtherAirport',create=true} --create if doesn't exist?
--if we wanted to go yet another step further.
{name='Some Unit #1',side='Red',action='DamageEngine',damageType='light'} -- no auto rtb.

-- or further still, though at this point we're becoming just a generic random action on unit script.
-- which may\may not be a bad thing but i'd probably rename all the function at that point lol.
{name='Some Unit #1', side='Red', action='DamageSensor', sensorType=dbid#} --disables first matching sensor
{name='Some Unit #1', side='Red', action='DamageSensor', sensorType='Random'} --picks one at random to disable.

Thing is, and maybe one of you can enlighten me, is I don't fully grasp what the ferry mission solves that RTB doesn't. Is it just wanting to be able to easily control the speed\altitude and doctrine of the returning unit(s) per-homebase? I can see that aspect, but I'm probably just missing something obvious that's more important.

Thoughts?

[jkgarner]

@KnightHawk75:

Regarding your statement...

On that note I'm trying in a longer term person habit\project to pull together all my personal scripts (and some from others with credit) that have some generic use under a sort of larger api framework. Atm i call it gKHApi and then split all my files up and load\register them in a semi organized namespaces like gKH.base,gKH.Sensors, gKH.Comms,gKH.Movement,gKH.Waypoints,gKH.Unit, gKH.Database, etc That way I only load what's needed for any given scenario during startup by running the script from file, and each sub namespace knows the other namespace requirements for itself and checks if they exist first before loading. Maybe sometime I'll give a preview of the whole thing in some sample scenario or just upload it to github where people can just grab what they find useful. Would be so much easier if the default 'module' and some other basic features in lua were available, but they are restricted in the commercial version for presumably security reasons the same that all the io and load functions are so been trying to find workable ways to overcome that. The down side is it assumes it's folder and files exist under \lua and making people copy things into folders while shouldn't be a challenge seems to be if judging just by beta release threads.

I have been looking at (and started) creating a pseudo-namespace for the functions similar to what you describe. One issue that I ran into was how to insert them easily AND ensure they remain in the scenario after saving and loading, all while choosing the directory for the scripts... (I like to keep my stuff separate from community/official release, AND I like to have each scenario's scripts in its own directory. This makes finding stuff later a lot easier.

To accomplish this, I put together a way to insert the 'library' functions easily into the scenario, and guarantee that they are available when reloading.

The short of it is that I have two scripts. The library script and a library init script. My library is called 'AFWI', thus I have AFWI.lua and AFWIinit.lua.

I have written the instructions for use in the init file. This file creates the sides, and a few events (with triggers and actions) to load the side scripts, and most importantly, load the AFWI library.

I have uploaded an abbreviated AFWI library (as an example) and the AFWIinit file along with simple scenario side setup scripts to show how things go together.

Feel free to examine are modify/use as you see fit.

[KnightHawk75]

I'll look it over later tonight, sounds like we're doing similar things (just makes sense after all right!), similarly organized .. Just quick eyeballing though.... dam though dude your comments are so neat and tidy!

[BeirutDude]

Man you guys are soooooo far beyond my skills. I'm looking at the code and, well I guess I'm hopeless!

[BeirutDude]

So I initially did a Ferry Mission and that worked well.

The two issues I had with it were...

1. The player could just reassign it to the original mission (which admittedly they can as well with an RTB)
2. If I assigned the aircraft to an "Allied Side" and Ferried/RTBed it to the base then it gone for the remainder of the scenario unless I found a way to "Give it back" some time after it landed and the first was within my skills but the second wasn't (didn't know how to test if a unit has returned to base and landed nor allow proper time to "fix" the aircraft).

I'm still troubled on why
Math.Random(N,M)
Math.Randomseed(ostime())
Are not working correctly in the game but ARE working in the Lua Console!!!!! That is a major issue to me!

[KnightHawk75]

Well you know #2 now, sort of anyway.
Just for clarity for future readers the order should be reversed when used, though it was probably just how you typed it for the post.
Math.Randomseed(ostime())
Math.Random(N,M)

As for the why, idk.

But you're not saying the sample (with use of improvedRandom() ) isn't working right?