iEoCUtilities "dual-use" packages, description and

description and progress report.

Hello All,

It's been a while since I posted anything, but I have been quietly working away, and interacting with Cambragol about useful features for US. Here is a current status report, with a list of package names (and descriptions/summaries) that are started (none finished yet, and loads of debugging still needed) and some aspirational ideas as well:

Here is a list of packages that are started or envisaged. None are yet complete, though a few have grown to dozens of coded functions each. None have been thoroughly tested yet.

Mod name: iEoCUtilities

Purpose: provides many useful POG functions for use in other mods, and a set of player-ship functions for improved game-play within EoC or Unstable Space.

All iEoCUtilities Mod packages have names that start with "i" to indicate that they are generic IWar2 packages and end with "Util" to distinguish them from the many "i..." packages in the base EoC distribution. The packages are intended to be compatible with both US and EoC and consequently make no reference to EoC or US-specific data such as geography or factions.

iCargoPodUtil.pog (partially coded/tested)

backport of some tsPodUtil.pog functions with additional functionality such as double-stacking of pods on cargo ships and pod-chaining on spider tugs. The pod stacking and chaining requires revised cargo pod .ini and .lws files to provide a second dockport opposing the first.

iChildSimsUtil.pog (very incomplete and untested)
iParentChildSimsUtil.pog (very incomplete and untested)
[these two will probably be combined into a single package)

when complete, this package will (I hope) provide utilities that assist with the management of complex sets of child sims on ships, for example flotillas of fighters on a fighter carrier. It will also provide a way of carrying child-of-child siims through capsule space. At present the children of child-sims do not jump with the parent ship and the first generation child sims attached to it.


iDockportUtil.pog and iDockingOrdersUtil.pog (partially coded and tested)

utilities to give additional control over dockports and docking. As an example of the additional utility, a new dock order task cross-assigns dockport handles as properties, which makes it straightforward to tell what object is docked to what dockport.

iErrorTraceUtil.pog (aspirational)

It would be really useful to have a "traceback" feature when a function crashes. I'm brainstorming ways of doing this and am leaning toward creating global string variables that contain arrays of strings, with each string being the error message from a deeper layer in the function call hierarchy.

iFlexibleKeysUtil.pog (aspirational)

There aren't enough keybinds for all the commands I envisage implementing. iFlexibleKeysUtil would provide a way of changing the meaning of keybinds "on-the-fly". So, for, example,

CTRL-ALT-SHIFT D

might bring up a "docking menu", with a large set of keybinds related to docking.

CTRL-ALT-SHIFT T

might bring up a "turret target designation and control" menu with keybinds related to that.

And so on. This would make the keybind mnemonics easier to remember, IMO. Cambragol thinks it may be better to have "dialogue" menu options on screen, and I'll try that too. But some modders may like this approach to expanding the range of keybind options.

iGlobalsUtil.pog (aspirational)

At the very least, I want to define some global variables that can be used as "error returns" for float and int valued functions, to signal to the calling function that something went wrong. For example, the most negative possible integer will assuredly never be used for anything in game, and so it could be the "error return" value of an integer-valued function. iGlobalsUtil functions might also be helpful for the iErrorTraceUtil functions.

iINIFileUtil.pog (partly coded/tested)

utilities for managing and interacting with .ini files. Provides interfaces to INIFile package functions which do useful things, such as search for a particular numbered key value and then return the corresponding number of a different-named numbered key in the same section of the inifile.

iMathUtil.pog (very incomplete and untested)

the principal tools I am working on in this package are general purpose sorting utilities for string-encoded arrays of integers, floats and string. This will be useful in cases in which one wants to sort or order data and there is not a handy list of objects to which the data could be attached as handle properties in order to sort using the List.SortBy... functions.

iPlayerEventsUtil.pog (very incomplete)

at present, this package allows the player to launch (and suspend) tasks which will pause the game if the player ship is attacked or if a hostile comes within sensor range. This allows the player to walk away from a game in progress (for example while lurking near an L-point waiting for Marauders to show up) without fear of returning to find that something bad has happened in his absence. Pirate missions in EoC for cargo gathering can be very tedious; this function lets one play in this mode without wasting lots of time waiting for things to happen. Further contemplated developments include pausing for specific factions or even specified cargo on specific faction transports. Complex logic specifications of conditional triggers can be implemented. Other game actions, aside from "pause game" could be implemented. Suggestions are welcome.

iPlayerShipCommandsUtil.pog (partly coded and tested)

This package is the game-playability "payoff" of the other packages in that here are collected implementations of other package functions for use by the player. As an example, there are functions to load cargo to the player-ship transport (if playing Unleashed and flying the Pinguin, which can carry multiple cargo pods), or to build a pod chain of multiple cargo pods (if flying the Spider-class tug).

iSimConfigurationUtil.pog (partly coded and tested)

provides a very reliable method for determining the .ini file of the player ship and a range of utilities for stripping and rebuilding subsims. Some of this functionality is inspired by the US tsShip.pog package. I'm a little concerned about the secureness of the correlation between Sim.NthSubsim() and the INIFile.Numbered ... template files, and will incorporate into iSimConfigurationUtil.pog functions which make a very secure correlation between these. These features are necessary for dockport subsim rebuilds prior to the mounting of Unleashed-style turret-ships.

iStringArrayListSetUtil.pog (partially coded and tested)

encodes and decodes arrays, lists and sets of objects in strings. This frees one from the need to use handles or handle properties to construct arrays, lists or sets.

iSubsimsUtil.pog (partly coded)

provides a very secure way of identifying the template file that was used to create a subsim on a sim.

iThreatAssessmentUtil.pog (very incomplete)

ranks threats against specified ships for the purpose of provided guidance to targetting codes. This is only in initial stages of testing and coding. I am using missile threats as a test bed. The Unleashed mod does not do a good job of assigning missile targets to the Pinguin's twin point-defense turrets. In the Stepson station tour scene of EoC Act 0, for example, the Pinguin's turrets will shoot at Carva missiles that are targeting the hostile tugs. I'm working on code to determine whether missiles are approaching and how oblique their trajectory is. The LOS velocity or estimated time to impact would provide a useful metric for ranking missile threats. One could also imagine further enhancements, such as evaluation of whether the missile is homing or unguided, and perhaps even an evaluation of the strength of the warhead, based on the quality of the ship's sensors and whether active sensors are energized.

After missile threats are properly evaluated and turret targeting control functions are working, I'll turn to the assessment of ship threats.

Initially, this code will be used to provide targetting guidance to tasks that control the player-ship's turrets, but it should be generalizable to non-player turret-ships also. It might ultimately provide inputs to AI-like tasks that control flights, squadrons and fleets of player wingmen or non-player faction ships.

iTurretTargetAssignmentUtil.pog (aspirational)

initially this will control the ship-turrets on the player ship, but eventually will have codes to control turrets on all ships and gunstars. The problem of assigning targets to ships (such as player wingmen or non-player faction AI ships) beckons, but I think that will be a challenge.

iTurretShipsUtil.pog (partly coded, testing very incomplete)

this package converts the Unleashed mod hard-coded turret-ships into .ini file specifiable dockport attachments (numbered keys in the [Subsims] section of the ship .ini file can specify the specific turret ship which is to be mounted on turret-mount dockport), which makes it easy to extend the Unleashed turret concept to other ships.

---

The Mod is still very incomplete. For example, iTurretShipsUtil.pog requires functions in iSimConfigurationUtil.pog to strip and rebuild the turret-mount dockports, and the method I want to use to match the Subsims with the .ini file template keys calls for functions in the iStringArrayListSetUtil.pog package which are my current focus of attention.

In the interest of flexibility and utility, I'm trying to anticipate possible modder needs and am coding functions that I don't expect to use right away myself. For example, in the iStringArryListSetUtil.pog package, the string-based lists and sets functions will reproduce the syntax and functionality of the List and Set POG packages.

I'd appreciate feedback from any coders out there who are still working with EoC mods codes. If there are features you would like to see, let me know. I can't promise to incorporate them right away, but it wouldn't hurt to have a growing "wish list."

Here is a quick status update on the vEoCUtilities mod.

I have been focusing on the iSimConfigurationUtil.pog package, on functions that produce reliable correlations between sim .ini file [Subsims]template[] keys and the subsims that are returned by the
Sim.NthSubsim() function.

A reliable correlation is really useful if you want to selectively delete subsims and rebuild them with in-game knowledge of where they are on the sim.

For my present purposes, I want this so that I can control which mounted-ship-style turrets (following Bineshi's approach to turrets in Unleashed mod) get mounted where on a sim.

Using a standard gunstar as a test bed, I have modified the gunstar .ini file to have dockports at the ends of the 6 "arms" of the sim, and the gunstar .ini file also specifies the template URLs of the turret-ships I want mounted at each of these locations. Since the Sim.Create function ignores this additional auxilliary information, I need a function that creates and docks the turrets to their respective locations. And for that, I need to know which dockport subsim is which on the gunstar sim.

Which brings me back to the iSimConfigurationUtil.pog function that reliably matches subsims to sim template [Subsims]template[] keys.

I'm comparing the [Properties] keys that are specified in each subsim template URL with the values of the handle properties of the subsims on the sim. I have an auxilliary .ini file that enumerates all the [Properties] keys that exist in each [Class] category.

I have encountered two unexpected hiccups.

a) a property exists in the subsim handle but not in the template file that was used to create that subsim.

This puzzles me as I thought that the subsim .ini files [Properties] keys all went into the subsims handle, and only those keys specified in the .ini file were created in the subsim handle.

But I am finding that the "power" property is present in dockport subsim handles, but generally is not specified in the corresponding .ini files. However, when "power" is present in the dockport handle, its value is zero.

So that suggests a workaround for this discrepancy between the handle properties and the template file Properties keys: if the key is absent from the template file, but the handle property is null, ignore the discrepancy.

b) an odder case is when the [Property] key is defined in the subsim template file but is not present in the handle.

The nps_sensor.ini file specified "whiteout_brightness=1e20"
but this property is not present in the subsim handle.

I can work around this too by deleting "whiteout_brightness" from my auxilliary data file that tells me which properties to check for in any given [Class] of subsim.

But it is a puzzle. I don't understand where these discrepancies come from. I thought that the .ini files properties controlled the handle properties of the corresponding game objects.

I welcome feedback about this from anyone who has insight into these oddities.