In each save folder there is an sqlite database with file name global.db . There is a table called StructuresDeviceCount with these columns: entityid (INTEGER) , which is the structure entity id. deviceid (TEXT) , with strange numbers as a text string. (It does not change in the db even if the device name is changed in the client) count (INTEGER), the count of devices only known by the text deviceid. The mapping is probably held in memory on the server, as the et.dat of the structure updates the naming only when the client logs off or the server shut down. I have tried to make sense of the .dat file and the .area file with no success. As far as I know I can't map devices on a Dedi mod. Anyone knows how to read the ent.dat or make sense of the deviceid column?
I was looking at this the other day after hearing folks talk about wanting a salvaging automation similar to the repair bay in reverse. I thought, incorrectly, the deviceid an enum exposed in the DeviceTypeName class of the ModEnums.cs file described in the mod documents located at \Extras\Modding Doc ... however the list and file contents are not comprehensive of all devices and no id mapping is there. I was about to start a black box of creating a ship and adding the devices to see how it impacted the table but realized there wasn't any obvious way to get a breakdown of the current state of the entity as far as "how many blocks of what type are left." One of the folks with more experience may have already gone through the tedium (that is potentially broken every time a new release gets dropped by changes to the .h file) ... I did a quick poke at it and determined that 2="o2 tank", 20="ammo box", and 35="fridge" ... both small and large 02 show up as a 2 so you would need to use it with the size of the device to get specific. Creating a base in creative and then putting on 1 of one thing, 2 of another, 3 of a third and so on would let you derive it in one shot. Having the fkey implied domain tables in global_db (ie "DeviceType" etc.) would be really helpful.
