Warehouse control functions

[chromium]

16 ore fa, Pikey ha scritto:

@chromium is writing things now for DSMC https://dsmcfordcs.wordpress.com/ I Chromui He's pinging right now for feedback as he rewrites parts. I presume for all these people there are others doing the same.
 

Thanks a lot for spreading the info here also .

Given the possibility to track everything in the wh right now and more than one solution to make it persistent in the subsequent mission iteration, I believe that soon or later we're going to see much more RMS use in some servers. Mainly what I expect quite soon is some kind of CTLD version with resupply crates implemented.

(PS: the version at the site link is the stable 1.3.4 that does not use the new system, while the openbeta 1.3.5 on github here https://github.com/Chromium18/DSMC does)

 

16 ore fa, Pikey ha scritto:

But in terms of using it, its some of the easiest things to use, you can make factories and supply chains that have physical presence.

And this is exactly what I'm expecting to be realized soon (and I'm also doing that with no rush, not a priority). But it's a very easy step to perform: you would only need to set as negligible the frequency/size/operating level of a warehouse, while coding a "spawn convoy from a to b" when the warehouse goes below a certain level for the desired item.
About this, it might be good in a wishlist to have some events attached to the warehouse management, like "item below specific level", to avoid creating recursive loops to check quantity of each item all the time.

 

 

Edited August 24, 2023 by chromium

[Pikey]

Yes, there is plenty to look forward to. This allows unlimited imagination to be used. From basic script snippets that anyone can use in a DO SCRIPT, to custom factory checks and complete supply chains, either virtual or real. But the best part will be when the C-130 and Chinook arrive to give the player agency for this entire thing and complement or remove the script requirements.

[tacts.zeagle]

Just what I needed

 

[tacts.zeagle]

Here is a listing of a typical inventory table for an airbase. I hope this helps someone.

Notable is the indexing of liquids at [0], which, although normal for C, is not good Lua practice. Lua arrays typically start at index 1.  Also of note is the inconsistent use of the underscore and the hyphen in the naming of weapons. The AIM-9 series is a good example.  The AH-64 internal aux tank simply has no name other than "weapons.droptanks."

Also, the inventory uses a plural for liquids and aircraft, and a singular for weapons. ( inventory = {liquids = {}, weapon = {}, aircraft = {}}... "weapon" needs an "s" at the end.)

This is why we programmers have no hair.

 

edit: this one includes the resource map as well.

 

inventory.lua

 

 

Edited August 28, 2023 by tacts.zeagle
annotations

[Saruman]

After testing a bit, I noticed that carriers do not always get updated after setting items, at least in my mission.

Some times they get updated, some times (when restarting same mission) they do not.

Here's a sample oversimplified code

local friendlyAirbases = coalition.getAirbases(coalition.side.BLUE)
    
for i = 1, #friendlyAirbases do
	local w = friendlyAirbases[i]:getWarehouse()
	local inventory = w:getInventory().weapon
         
	for wpn, _ in pairs(inventory) do
		w:setItem(wpn, 30)
	end
end

Common airbases always work fine instead.

Edited August 28, 2023 by Saruman

[tacts.zeagle]

First, I fail to grasp the reason for the above code. If you are just setting the values once and never changing them, then they are better set in the ME not in code.

Second, this is a brute-force method of changing every weapon in every friendly base. Why? Why not just change the items you need to? Think efficiency. These kinds of things have the potential to really bog down performance.

And lastly, if you are going to run this code, try using a time delay to allow everything to load up before you go and start iterating through all the airbases. Make sure your carriers are actually loaded before changing their internals.

As far as readability goes, using a single letter for your warehouse is not good practice. Also naming a table "inventory" when it actually contains "weapon" is another pitfall.

[Saruman]

58 minutes ago, tacts.zeagle said:

First, I fail to grasp the reason for the above code. If you are just setting the values once and never changing them, then they are better set in the ME not in code.

I oversimplified the example code, because the real function loads inventories from a file, since I created a persistency system to use through rotation of missions being part of my campaign (three missions rotating, one for each time of the day). There is also a resupply system every n days in real-world time, but it's irrelevant to my question.

 

58 minutes ago, tacts.zeagle said:

Second, this is a brute-force method of changing every weapon in every friendly base. Why? Why not just change the items you need to? Think efficiency. These kinds of things have the potential to really bog down performance.

ED can change weapon codes, first of all. Second, new modules and new weapons will be added and it would become a second job to add, check and update a custom weapon table with only the items of interest (consider I run a 24/7 campaign, so new modules will always get added). I started with a (long) custom table, changed my mind on the fly after the above considerations. Third, many items have the same name though being distinct (for example "Fuel tank 300gal" for F14 and F16: the F16 version has no code, the F14 has it). To sum it up: inventory hardcoded by ED is a mess (did you ever notice some items only displaying "!!!!" ?).
Last but not least, last time I trusted ED not to change anything fundamental, they changed the IDs of all buildings in Syria, which I am referring to in some mission files (DCT template definitions used by the underlying DCT framework used by campaign), so I had to double check all the new IDs and modify accordingly the mission files.

About performance, real script runs great, thanks, one time at init and one time before rotating to save updated warehouses into a file.

 

58 minutes ago, tacts.zeagle said:

And lastly, if you are going to run this code, try using a time delay to allow everything to load up before you go and start iterating through all the airbases. Make sure your carriers are actually loaded before changing their internals.

I already make the real code called by timer.scheduleFunction() and delay is 60 seconds, more than sufficient to load every unit I guess, since I can spawn on the carrier 1 second after mission starts.

 

58 minutes ago, tacts.zeagle said:

As far as readability goes, using a single letter for your warehouse is not good practice. Also naming a table "inventory" when it actually contains "weapon" is another pitfall.

As far as I can read and understand the code, it's all that matters. Script is not GPL-ed and have no contributor, therefore I'm the only one who will ever mantain it.

That said, I'd prefer not to derail from argument, which is: carriers do not always get updated by setting items in the aforementioned context; no issue with common airbases instead.

Anyone experienced/tried that?

Edited August 28, 2023 by Saruman

[MarcosR]

Hi @Grimes  i spawn a farp dynamically on my server.. I understand the payload can be send on creation is that the warehouse info? Or will spawned farps will always be unlimited weapons?  Would be great been able to modify the stock of weapons and planes even if it’s unlimited…

[Grimes]

5 hours ago, MarcosR said:

Hi @Grimes  i spawn a farp dynamically on my server.. I understand the payload can be send on creation is that the warehouse info? Or will spawned farps will always be unlimited weapons?  Would be great been able to modify the stock of weapons and planes even if it’s unlimited…

AFAIK they are unlimited for now. The warehouse info isn't saved in the mission file, its in the warehouse file within the miz. Thus there aren't any input parameters right now to define the warehouse functionality. 

[NeedzWD40]

Is addItem functional with equipment like gunpods? I noticed equipment like UH-1 door guns, GAU-12 pod for AV-8, etc. cannot be added through this command, but rockets, missiles, and drop tanks can be added without issue.

[Hotshot 338th]

Does anyone have the item string for AGM_114L?

"weapons.missiles.AGM_114K" is working for AGM_114K, but "weapons.missiles.AGM_114L" is not working for the AGM_114L.

[NeedzWD40]

On 10/24/2023 at 12:04 PM, Hotshot 338th said:

Does anyone have the item string for AGM_114L?

"weapons.missiles.AGM_114K" is working for AGM_114K, but "weapons.missiles.AGM_114L" is not working for the AGM_114L.

Did you try "weapons.missiles.AGM_114"?

[Hotshot 338th]

On 10/25/2023 at 8:42 PM, NeedzWD40 said:

Did you try "weapons.missiles.AGM_114"?

Nope! Will give it a try.

[ZuluThreeZero]

On 9/14/2023 at 10:41 PM, Grimes said:

AFAIK they are unlimited for now. The warehouse info isn't saved in the mission file, its in the warehouse file within the miz. Thus there aren't any input parameters right now to define the warehouse functionality. 

Hey Grimes, on this front, because of when warehouse gets loaded during start-up, it seems there's no function to toggle unlimited munitions once in-game, correct?

Been haltingly working on a script to restrict weapons and items that weren't in service in the year a mission is set, but at present it requires that all warehouses (at least, the ones people will be using) are set to have limited equipment, either in the editor or by doing a find-and-replace-all in the warehouse file in the miz container after saving the mission.

Probably one for the suggestions section instead, but it seems to me that either or both of the following would be awesome:

a) an overall option for the editor that sets whether warehouses are limited or unlimited by default

b) a "copy to all warehouses" button in the ME interface, rather than having to copy airport-by-airport (plus, that list currently doesn't include other warehouses like FARPs and ships)

[EvilKipper]

On 9/14/2023 at 5:41 PM, Grimes said:

AFAIK they are unlimited for now. The warehouse info isn't saved in the mission file, its in the warehouse file within the miz. Thus there aren't any input parameters right now to define the warehouse functionality. 

 

On 9/14/2023 at 12:00 PM, MarcosR said:

Hi @Grimes  i spawn a farp dynamically on my server.. I understand the payload can be send on creation is that the warehouse info? Or will spawned farps will always be unlimited weapons?  Would be great been able to modify the stock of weapons and planes even if it’s unlimited…

It is possible to work around this. If you want to dynamically spawn a farp, you can pre create any number of empty farp pads somewhere on the map in the mission editor with their warehouses empty. Then when you know where you want your dynamic farp to be, you spawn the farp pad with the same name as one of your "template" farp pads. This will effectively move that airbase to wherever you want. You can do this multiple times with the same farp pad. If you are calling world.getAirbases, be sure to check isExist, the previous locations will be returned from world.getAirbases but isExist will be false. Airbase.getByName will always return the most recent one however.

Once you have created your "dynamic" farp you can get it's warehouse and use it normally just like any other airbase.

[MadCartographer]

On 8/16/2023 at 12:08 PM, Grimes said:

Wiki articles for functions added with this patch: https://wiki.hoggitworld.com/view/Category:Game_Patch_2.8.8

Thank you for this reference.

[MarcosR]

I think is relevant again... now the dynamic farps have nothing..  do we know if we will have a way to make dynamic faprs work again? 

[NeedzWD40]

On 7/11/2024 at 9:38 PM, MarcosR said:

I think is relevant again... now the dynamic farps have nothing..  do we know if we will have a way to make dynamic faprs work again? 

Dynamic FARPs now spawn without fuel, munitions, or equipment and have to be added via scripting. The problem remains as I noted before: some weapons and equipment lack a definition and can't be easily added via scripting (if you can dig out the wsType definition you can add it that way, but wsType changes now and again and so is difficult to keep up with changes). Current examples include the M3P gunpod utilized by the OH-58D. So you can add fuel and weapons like AGM-114 to your dynamic FARP, but you can't easily add certain classes of gunpods and other equipment.

Edited July 13, 2024 by NeedzWD40

[NeedzWD40]

An interim fix I'm using for the time being:

Create an invisible FARP on a neutral side, place it off in the corner somewhere. Set the resources to limited; count doesn't matter. Call it "myfarpwarehousetemplate" or as desired. This can then serve as a basis for most of the equipment you want your generated FARPs to have.

Next, use this code and run it in an init somewhere:

--this is the current gunpods and equipment used by most helicopters as of 07/13/24
--expect these numbers to change after DCS updates
myuber_megawarehouse = {
{4,15,46,2578},
{4,15,46,2577},
{4,15,46,2576},
{4,15,46,2575},
{4,15,46,2574},
{4,15,46,1771},
{4,15,46,1770},
{4,15,46,1769},
{4,15,46,1764},
{4,15,46,1765},
{4,15,46,1766},
{4,15,46,1767},
{4,15,46,1768},
{4,15,46,170},
{4,15,46,171},
{4,15,46,183},
{4,15,46,1294},
{4,15,46,1295},
{4,15,46,824},
{4,15,46,825},
{4,15,46,300},
{4,15,47,1100},
{4,15,47,680},
{4,15,47,679},
{4,15,46,2476},
{4,15,46,2477},
{4,15,46,2478},
{4,15,46,2479},
{4,15,46,2480},
{4,15,46,2481},
{4,15,46,2482},
{4,15,46,2483},
{4,15,46,2484},
{4,15,46,2579},
{4,15,46,2580},
{4,15,46,2581},
{4,15,46,1057},
{4,15,46,160},
{4,15,46,161},
{4,15,46,184},
{4,15,46,174},
{4,15,46,175},
{4,15,46,176},
{4,15,46,177},
{4,15,46,20},
{4,5,32,94},
{4,5,32,95},
}
--this will grab the weapons from our template and fill our array with everything else
for i, d in pairs(Airbase.getByName("myfarpwarehousetemplate"):getWarehouse():getInventory("weapon")) do
if(i == "weapon") then
for i2, d2 in pairs(d) do
table.insert(myuber_megawarehouse,i2)
end
end
end

Next, wherever or however you generate your FARP plates, use schedulefunction to fill the FARP "warehouse" with the items from the array:

--farpname is the name of the dynamically generated FARP
local function addmystuff(array)
					--500000 is not required but its a good large figure for now
					Airbase.getByName(farpname):getWarehouse():setLiquidAmount(0,500000)
					--iterate over each uber warehouse item and add nuclear stockpile
					for warei, wared in pairs(myuber_megawarehouse) do
						Airbase.getByName(farpname):getWarehouse():setItem(wared,500000)
					end
					return nil
				end
					--schedule function 5 seconds after the FARP has been made so the game has time to init the plate
					timer.scheduleFunction(addmystuff, {1}, timer.getTime() + 5)

This should cover most helicopter equipment and replicate the previous infinite levels, but it also means we can now dynamically generate a FARP but require supplies to be ferried in before usage. In theory, we could also add dynamic spawns to these FARPs, if the miz level code lets us.

[bal2o]

4 hours ago, NeedzWD40 said:

This should cover most helicopter equipment and replicate the previous infinite levels, but it also means we can now dynamically generate a FARP but require supplies to be ferried in before usage. In theory, we could also add dynamic spawns to these FARPs, if the miz level code lets us.

what i see is that dynamic slot is only in mission file level, so it's load at the beginning of the mission. pretty sure that is not possible to add dynamic slot dynamically :s

let me know if you find something

[NeedzWD40]

11 hours ago, bal2o said:

what i see is that dynamic slot is only in mission file level, so it's load at the beginning of the mission. pretty sure that is not possible to add dynamic slot dynamically :s

let me know if you find something

So there is a way, but it's incredibly inconvenient and has its own limitations, but it does work (at least, for the server side):

The warehouses file is where our dynamic spawn locations are listed, which unfortunately we can't change (yet) via scripting. However, we can fool the game into working with this by creating fake entries linked to IDs assigned by us. We can then create a FARP object with the ID as defined in the warehouse file anywhere we wish, with the caveat we can only do so once. This means that we can only have a limited number of dynamically created FARPs with spawn points that, once set, cannot be moved after they've been set. If it were possible to delete FARPs after creation, we could probably circumvent this rule, but as it stands, once a FARP object has been created, it's there forever.

You could have a list of 10-20 or however many FARPs you wanted with reserved IDs manually added to the warehouses file, then use and discard this reserved ID list until depleted, at which point it would be set in stone. I'm including an example mission where a F10 command is utilized to generate a FARP with dynamic slots with this method. I cannot say if this mechanism will work for all clients, only that it works on the server side.

dyn_spawn_tester.miz

[Dangerzone]

12 hours ago, bal2o said:

what i see is that dynamic slot is only in mission file level, so it's load at the beginning of the mission. pretty sure that is not possible to add dynamic slot dynamically :s

let me know if you find something

Actually, it seems DCS does scan new dynamic FARPS to see if they should be on the list. The problem is that there’s a function it calls (dynamicSpawnAvailable) to see if the FARP has DynSpawn enabled and as it doesn’t (no way at present to set it via lua code and its false by default) it bypasses those FARPS. 

I’ve managed to get this to work by modifying one of the lua files in the DCS install directory, but it is a hack.

It works when running a local MP mission on the client, but I have not yet tested at a dedicated server side level. 

But it does provide proof of concept. DCS does include new FARPs in its scan, so DCS can handle it, if they gave us the option to set the variable that we set in the mission editor for DynSpawn via LUA. Maybe there is already an option but they’re not telling us what the function is called yet. 

We also would need the option to set the stores. I’ve used a script that dynamically created FARPS previous for rearming and refueling that’s worked fine up until this release that is now broken since this patch.  For some reason they’ve changed new FARP creations from unlimited to empty by default.

If you want to know how to get a slot to show up on dynamically created FARPS, here’s how. 

I haven’t persisted with going further than that for now.  TBH, I’m quite discouraged at the moment from mission design in DCS.

When it finally seemed like what I’ve been dreaming of achieving for years is almost within reach, not only is it not, but it’s one step forward, 2 back with more things that used to work are broken (and talking to some others, it seems this change for default FARP parameters is intentional). So, just like the event_dead on cows that was working and has been removed for 2 years, (and I’m now told “it’s intentional to not have it anymore on cows”), the impression I’m getting lately is that nothing is safe. What other work I’ve done is next on the chopping block to be permanently removed at some stage in the future, by intentional design, with no plans to give it back- or at the least take a long time before those features are made available again?

Bugs are one thing, but removals of previous functionality of change of design, while leaving no simple options for us to have backwards compatibility to still maintain existing functionality is another. (Why would they change FARP from defaulting to unlimited to not without giving us an option to switch it back to unlimited via lua?)

Maybe it’s my fault, wanting to design a complex dynamic MP mission/server campaign that ‘s up there with the big ones. I see the potential DCS has and want to get there. I keep finding ways to overcome DCSs limitations which gives me hope, but then see intentional changes made in newer releases that breaks themis disheartening. So is having no feedback on whether ED has any intention of allowing us DynSpawn on DynFarps.

I sometimes think that the CB team get more info on the direction things are going, so they have time to prepare their missions and servers in advance before release, which is why they can maintain their missions easier and prepare for things that break, and the only way to succeed in having a complex 24/7 MP server is to be in the inner circle. But then seeing Enigma’s video of why he left and identifying with his struggles, has me realising while it’s probably somewhat helpful and would solve some of the issues, there is still a lot to deal with even then.

I’m not sure if I’m being rational with my thinking, or I just had some bad nights sleep, but I do feel like I need a lifeline atm to restore my enthusiasm in mission design. Has me wondering how other designers are going, and if it’s just me that’s struggling. 

[bal2o]

7 hours ago, Dangerzone said:

Actually, it seems DCS does scan new dynamic FARPS to see if they should be on the list. The problem is that there’s a function it calls (dynamicSpawnAvailable) to see if the FARP has DynSpawn enabled and as it doesn’t (no way at present to set it via lua code and its false by default) it bypasses those FARPS. 

I’ve managed to get this to work by modifying one of the lua files in the DCS install directory, but it is a hack.

It works when running a local MP mission on the client, but I have not yet tested at a dedicated server side level. 

But it does provide proof of concept. DCS does include new FARPs in its scan, so DCS can handle it, if they gave us the option to set the variable that we set in the mission editor for DynSpawn via LUA. Maybe there is already an option but they’re not telling us what the function is called yet. 

We also would need the option to set the stores. I’ve used a script that dynamically created FARPS previous for rearming and refueling that’s worked fine up until this release that is now broken since this patch.  For some reason they’ve changed new FARP creations from unlimited to empty by default.

If you want to know how to get a slot to show up on dynamically created FARPS, here’s how. 

I haven’t persisted with going further than that for now.  TBH, I’m quite discouraged at the moment from mission design in DCS.

When it finally seemed like what I’ve been dreaming of achieving for years is almost within reach, not only is it not, but it’s one step forward, 2 back with more things that used to work are broken (and talking to some others, it seems this change for default FARP parameters is intentional). So, just like the event_dead on cows that was working and has been removed for 2 years, (and I’m now told “it’s intentional to not have it anymore on cows”), the impression I’m getting lately is that nothing is safe. What other work I’ve done is next on the chopping block to be permanently removed at some stage in the future, by intentional design, with no plans to give it back- or at the least take a long time before those features are made available again?

Bugs are one thing, but removals of previous functionality of change of design, while leaving no simple options for us to have backwards compatibility to still maintain existing functionality is another. (Why would they change FARP from defaulting to unlimited to not without giving us an option to switch it back to unlimited via lua?)

Maybe it’s my fault, wanting to design a complex dynamic MP mission/server campaign that ‘s up there with the big ones. I see the potential DCS has and want to get there. I keep finding ways to overcome DCSs limitations which gives me hope, but then see intentional changes made in newer releases that breaks themis disheartening. So is having no feedback on whether ED has any intention of allowing us DynSpawn on DynFarps.

I sometimes think that the CB team get more info on the direction things are going, so they have time to prepare their missions and servers in advance before release, which is why they can maintain their missions easier and prepare for things that break, and the only way to succeed in having a complex 24/7 MP server is to be in the inner circle. But then seeing Enigma’s video of why he left and identifying with his struggles, has me realising while it’s probably somewhat helpful and would solve some of the issues, there is still a lot to deal with even then.

I’m not sure if I’m being rational with my thinking, or I just had some bad nights sleep, but I do feel like I need a lifeline atm to restore my enthusiasm in mission design. Has me wondering how other designers are going, and if it’s just me that’s struggling. 

I know what you mean, i'm the principal dev for french's communauty call "couteau", we have conquest mission on all map and it's really hard to maintain all code ...

For farp, i always spawn invisible farp + static for fuel/ammo because we don't use logistic game (to hard to fine a well-balanced game play)

For dynamic slot, i think is too early for "dynamic dynamic stuff", just need to wait for ED open API.  All we need is just calling dynamic function.

In a first time, i will try to make a script/program to help to set all dynamic slot in one time, because ED don't do that ...

best,

[Zyll]

On 7/13/2024 at 3:03 AM, NeedzWD40 said:

An interim fix I'm using for the time being:

Create an invisible FARP on a neutral side, place it off in the corner somewhere. Set the resources to limited; count doesn't matter. Call it "myfarpwarehousetemplate" or as desired. This can then serve as a basis for most of the equipment you want your generated FARPs to have.

Next, use this code and run it in an init somewhere:

--this is the current gunpods and equipment used by most helicopters as of 07/13/24
--expect these numbers to change after DCS updates
myuber_megawarehouse = {
{4,15,46,2578},
{4,15,46,2577},
{4,15,46,2576},
{4,15,46,2575},
{4,15,46,2574},
{4,15,46,1771},
{4,15,46,1770},
{4,15,46,1769},
{4,15,46,1764},
{4,15,46,1765},
{4,15,46,1766},
{4,15,46,1767},
{4,15,46,1768},
{4,15,46,170},
{4,15,46,171},
{4,15,46,183},
{4,15,46,1294},
{4,15,46,1295},
{4,15,46,824},
{4,15,46,825},
{4,15,46,300},
{4,15,47,1100},
{4,15,47,680},
{4,15,47,679},
{4,15,46,2476},
{4,15,46,2477},
{4,15,46,2478},
{4,15,46,2479},
{4,15,46,2480},
{4,15,46,2481},
{4,15,46,2482},
{4,15,46,2483},
{4,15,46,2484},
{4,15,46,2579},
{4,15,46,2580},
{4,15,46,2581},
{4,15,46,1057},
{4,15,46,160},
{4,15,46,161},
{4,15,46,184},
{4,15,46,174},
{4,15,46,175},
{4,15,46,176},
{4,15,46,177},
{4,15,46,20},
{4,5,32,94},
{4,5,32,95},
}
--this will grab the weapons from our template and fill our array with everything else
for i, d in pairs(Airbase.getByName("myfarpwarehousetemplate"):getWarehouse():getInventory("weapon")) do
if(i == "weapon") then
for i2, d2 in pairs(d) do
table.insert(myuber_megawarehouse,i2)
end
end
end

Next, wherever or however you generate your FARP plates, use schedulefunction to fill the FARP "warehouse" with the items from the array:

--farpname is the name of the dynamically generated FARP
local function addmystuff(array)
					--500000 is not required but its a good large figure for now
					Airbase.getByName(farpname):getWarehouse():setLiquidAmount(0,500000)
					--iterate over each uber warehouse item and add nuclear stockpile
					for warei, wared in pairs(myuber_megawarehouse) do
						Airbase.getByName(farpname):getWarehouse():setItem(wared,500000)
					end
					return nil
				end
					--schedule function 5 seconds after the FARP has been made so the game has time to init the plate
					timer.scheduleFunction(addmystuff, {1}, timer.getTime() + 5)

This should cover most helicopter equipment and replicate the previous infinite levels, but it also means we can now dynamically generate a FARP but require supplies to be ferried in before usage. In theory, we could also add dynamic spawns to these FARPs, if the miz level code lets us.

interested in how you generated that list of gunpods and equipment? The Apache FCR is missing, and I'd like to be able to determine the codes for other equipment as they arise.

[NeedzWD40]

1 hour ago, Zyll said:

interested in how you generated that list of gunpods and equipment? The Apache FCR is missing, and I'd like to be able to determine the codes for other equipment as they arise.

For the warehouse settings, I set a unique number for the quantity of equipment that wasn't getting added through getInventory, then went into the mission file and opened warehouses, then found the equipment through the unique quantity number. Tedious, but it's how I found (most) of the missing equipment. I didn't have any problems with getInventory returning the APG-78 so I might have to check for that one again.