Workaround to Access the Player-ship .ini file
12 years 5 months ago #19185
by SRC
Workaround to Access the Player-ship .ini file was created by SRC
An annoying limitation, that was built in by Particle Systems for a reason that is not obvious to me, is the absence of the "template_name" handle property from the player-ship handle.
It appears to me that you cannot add new object properties by adding new keys to the [Properties] section of the player-ship .ini file (this may be more generally true of other .ini files as well; haven't checked), so that does not provide a workaround.
I'm interested in finding a solution to this for generalization of Bineshi's turret concepts in his wonderful Unleashed Mod to make them easily configurable in .ini data rather than, as at present, hard coded in the Mod packages.
There is a slightly involved way to work around this obstacle. I'll describe two methods, one easier to code but more complex to administer, and the other harder to code but simpler to administer once it is coded. I have coded the second method into a package called iShipUtil.pog and an helper package called iINIFileUtil.pog, both of which will go into the "vEoCUtilities" mod I hope to eventually put up (can put up the bits that exist now if there is interest) at the EoC mods page.
Both methods involve putting the .ini file URLs of the player ships into [Section]key(s) of auxiliary .ini file(s) that are accessible to code via the INIFile package. All that is needed is a way to reliably determine from within code which [Section]key to use.
In both cases, it is necessary that every different player ship that is needed to be accessed by one of these methods must have a unique ship name.
A. Easy to code method:
in the /sims/ships/player folder, create a new folder called
auxiliary_data
The new folder is not necessary, but I find it helpful to segregate new kinds of .ini files in places where they will not further clutter the ship data.
In the auxiliary_data folder, put a .ini file for each player ship in the /sims/ships/player folder. The name of this .ini file needs to be guessable from within code. A possible way to do this is to call the file
ship_name.ini
where ship_name is the name the ship has in the game. This can be determined by the Sim.Name() function. Provided that the game or modded code does not change the name, the string returned by Sim.Name() will be the same as the [Properties]name= key of the player-ship .ini file. But many mods do change the ship name and vanilla EoC does this too (for example, Cal has to select a name for the escape tug). So the name you choose for this auxiliary .ini file must match what Sim.Name() will return.
Inside this ship_name.ini file (one such file for each player ship), create a section and key, with the key being the ship .ini file URL
So, for example, in vanilla EoC, if Cal calls the tug "Crazy Horse",
you would create a file
/sims/ships/player/auxiliary_data/Crazy Horse.ini
and in Crazy Horse.ini you would have a section with the section name and key (for instance)
[INIFile]
ship_iniURL=ini:/sims/ships/player/tug.ini
In modded code, you would get the ship name with Sim.Name(), construct the auxiliary file URL with String.Join, and then use INIFile packages to recover the ship .ini URL, which can then
be accessed with the INIFile package.
B. somewhat messier code, but only requires a single auxiliary .ini file (and in fact one must use only one file for all accessible player ships)
Create a single auxiliary file that has a pair of numbered keys, one for the various player-ship names and the other for the corresponding .ini URLs. For example, in the Unleashed mod, the cross-ref data might look like:
[INIFile]
ship_name[0]="Crazy Horse"
ship_iniURL[0]=ini:/sims/ships/player/tug.ini
ship_name[1]=PINGUIN
ship_iniURL[1]=ini:/sims/ships/player/storm_petrel.ini
.
.
.
with additional numbered key pairs for the command section, patcom and corvette.
This file is accessed from code with the INIFile package, and the ship name is searched in the numbered key. The corresponding .ini URL is retrieved and used to access the player ship configuration data using the INIFile package.
It appears to me that you cannot add new object properties by adding new keys to the [Properties] section of the player-ship .ini file (this may be more generally true of other .ini files as well; haven't checked), so that does not provide a workaround.
I'm interested in finding a solution to this for generalization of Bineshi's turret concepts in his wonderful Unleashed Mod to make them easily configurable in .ini data rather than, as at present, hard coded in the Mod packages.
There is a slightly involved way to work around this obstacle. I'll describe two methods, one easier to code but more complex to administer, and the other harder to code but simpler to administer once it is coded. I have coded the second method into a package called iShipUtil.pog and an helper package called iINIFileUtil.pog, both of which will go into the "vEoCUtilities" mod I hope to eventually put up (can put up the bits that exist now if there is interest) at the EoC mods page.
Both methods involve putting the .ini file URLs of the player ships into [Section]key(s) of auxiliary .ini file(s) that are accessible to code via the INIFile package. All that is needed is a way to reliably determine from within code which [Section]key to use.
In both cases, it is necessary that every different player ship that is needed to be accessed by one of these methods must have a unique ship name.
A. Easy to code method:
in the /sims/ships/player folder, create a new folder called
auxiliary_data
The new folder is not necessary, but I find it helpful to segregate new kinds of .ini files in places where they will not further clutter the ship data.
In the auxiliary_data folder, put a .ini file for each player ship in the /sims/ships/player folder. The name of this .ini file needs to be guessable from within code. A possible way to do this is to call the file
ship_name.ini
where ship_name is the name the ship has in the game. This can be determined by the Sim.Name() function. Provided that the game or modded code does not change the name, the string returned by Sim.Name() will be the same as the [Properties]name= key of the player-ship .ini file. But many mods do change the ship name and vanilla EoC does this too (for example, Cal has to select a name for the escape tug). So the name you choose for this auxiliary .ini file must match what Sim.Name() will return.
Inside this ship_name.ini file (one such file for each player ship), create a section and key, with the key being the ship .ini file URL
So, for example, in vanilla EoC, if Cal calls the tug "Crazy Horse",
you would create a file
/sims/ships/player/auxiliary_data/Crazy Horse.ini
and in Crazy Horse.ini you would have a section with the section name and key (for instance)
[INIFile]
ship_iniURL=ini:/sims/ships/player/tug.ini
In modded code, you would get the ship name with Sim.Name(), construct the auxiliary file URL with String.Join, and then use INIFile packages to recover the ship .ini URL, which can then
be accessed with the INIFile package.
B. somewhat messier code, but only requires a single auxiliary .ini file (and in fact one must use only one file for all accessible player ships)
Create a single auxiliary file that has a pair of numbered keys, one for the various player-ship names and the other for the corresponding .ini URLs. For example, in the Unleashed mod, the cross-ref data might look like:
[INIFile]
ship_name[0]="Crazy Horse"
ship_iniURL[0]=ini:/sims/ships/player/tug.ini
ship_name[1]=PINGUIN
ship_iniURL[1]=ini:/sims/ships/player/storm_petrel.ini
.
.
.
with additional numbered key pairs for the command section, patcom and corvette.
This file is accessed from code with the INIFile package, and the ship name is searched in the numbered key. The corresponding .ini URL is retrieved and used to access the player ship configuration data using the INIFile package.
Please Log in or Create an account to join the conversation.