|
KnightHawk75 -> RE: infantry drop (6/10/2020 5:35:24 AM)
|
Weird on the db#'s maybe different ones are enabled in db485, or maybe you're using CWDB?.
[img]https://i.postimg.cc/zyq2FcK0/DB485-AN12-BP-Cuba.jpg[/img]
Anyway...
Ok so I went digging. I found three things.
First yup it's broke, it doesn't matter what you feed it when it's an aircraft.
The part where it dies is after it's found or not found the stuff we send it. Doesn't matter if you feed it guids or {num,dbids} sets or really if it finds any matches or not. It'll die when it gets to a point of code after building it's cargo list that looks something like this [for devs eyes]
...
if(activeUnit is Aircraft) //it is valid and aircraft...so next line fires and then throws object not set.
{
if (((Aircraft_AirOps)activeUnit2.\SomeObsfucatedFunctionOrProperty()).\SomeOtherObsfucatedFunctionOrProperty())
...
I can confirm activeUnit2 is indeed null when it reaches there and whatever the above it meant to do to maybe change that doesn't happen.
Second thing that I noticed during this and maybe one of the devs can confirm or not is that while the {{5,851}...} type parameter works as expected the guid {'guidhere,guidhere'} one does not. It parses the list fine, but it seems to do a compare on each individual cargo entries mount guid vs some overall package\group guid we see in unit.cargo entries.
So for example (in the attached scene) I added 10 #851's and 10 #858's to a IL76MD-90A with a 50ton air-drop loadout, one of those has paradrop capability flagged one of them doesn't (I wanted to see if it would let me drop it anyway).
The print(u.cargo) produces
{ [1] = { name = 'Ace Tomato #1', cargo = { [1] = { crew = 1, guid = '4FH7PU-0HM0CDR2UPE6Q', area = 0, mass = 0, quantity = 10, name = 'Spetsnaz Saboteur', dbid = 858, status = 'Operational' }, [2] = { crew = 1, guid = '4FH7PU-0HM0CDR2UPE82', area = 0, mass = 0, quantity = 10, name = 'SpecOp Saboteur', dbid = 851, status = 'Operational' } }, guid = '4FH7PU-0HM0CDR2UPE4G' } }
I assumed I could pass it those two guids to bulk drop them all but, that's not what think I saw happening, I saw it do a comparison between 0-19 individual cargo entries each having their own guid, of which of course none matched. When I recorded what some of those were such as 4FH7PU-0HM0CDR2UPE81 and 4FH7PU-0HM0CDR2UPE61, and ran it again, then I saw it match and get added to the drop list. Now btw that's cool we can specify specific dudes to drop, but the issue is how do we get the full list of those guids to know to do that?
Third thing is, it does work for Ships. Sort of.
That is the {num,dbid} process does complete without errors for ships. However unlike in gui, there doesn't seem to be a check for near-by land and placement there, it will drop the units into the ocean. So that that's a little bit of a problem. I suppose the guid works too for ships but I didn't want to go through another debug session to find out the individual ones for ones I stuck on a carrier in the scene. Another issue is that when you feed it a guid that didn't do anything it returns true anyway as if it did something. idk I think it should return false that no match was found.
attch: TestRig_CargoOps_TroopDrop2.scen (play red, special actions help demo problems...ignore blue side)
Edit - Side note: When triggering unload via the gui on Ace Tomato #1, it drops the paradrop flagged guys, the other 10 that are not capable just deleted, which strikes me as odd, I guess they just get thrown out the back without chutes. [:D]
|
|
|
|
