Some tweaks to Bineshi's "Unleashed" mod

The hope that the invisibility of the player-ship .ini template file name could be
alleviated by moving the player into another ship was mistaken. I had hoped that
this "feature" was an exception in the Sim.TemplateName() function that would
return a blank string when the player-ship was inquired, but evidently the
template name is not merely hidden by code, it is absent from the handle of the
ship that the player is first put into when he launches from the base. There
must be some parallel encoding of this information that the game uses, but without
the PS code, we don't know what that is.

This same problem exists in Unstable Space, and there they have a workaround
that works well in that mod. IIRC, the player ship class is inquired (this is
still visible to modded code) and the .ini file is guessed from that. This
solution, if implemented in EoC mods, imposes some serious constraints on the
variety of player ships one could create, since there would need to be a
one-to-one correspondence between the ship type and the template .ini file.

I'll poke around and see if there is other information that one might be
able to fiddle with that could create a more flexible way of creating a
reliable correspondence between accessible in-game information about the
player-ship and the .ini file used to create the ship. Something of this
sort is indispensable for a more flexible Unleashed-style ship-turret
system to be ported into a general-use EoCUtilities (and eventually,
perhaps also for US) package.

Just a quick update on the status of my tweaking of Bineshi's turret-ship
concepts.

I have a robust workaround for the prior annoyance of "invisible ship .ini file".
There may be a related problem in that ship subsystems (dockports, for example)
have invisible .ini files of their own. And even if their .ini files are not
invisible, there is no way using the tools in the SDK to distinguish between
multiple ship subsystems created from the same .ini resource.

This indistinguishability is a problem for me because I want to name mounted
turret-ships with names that reflect where they are on the ship. I'd like to
have this so I can give turret-ships orders such as "watch my six" to the rear
mounted turret. Can't do that if I can't tell which turret mount dockport is
which.

There is a workaround for this inspired by the elegant innovations of the
Unstable Space mod loadout system. The US team defined a bunch of new mountpoints
and built their own loadout system from scratch using these new mountpoints. To
make this work, they enhance the ship .ini file with subsim position and orientation
data copied from the .lws file (which tells the game where on the ship 3D representation
to put the various subsystems that have visible objects in the game)

I have copied this idea, with the null_position and null_orientation number keys
now defined for Pinguin dockports.

On the Enter_Space event, I will delete all the dockports on the Pinguin that I need
to replace, create new dockports of the same type, and put them where the old dockports
used to be. This seems a pointless exercise at first glance, but what it gives me
is the ability to know which dockport is located where on the ship. Then I can dock
turret ships to the turret mount dockports and name them appropriately to where they
are on the ship.

This is all just the beginning, because I want to treat turret-ships as "ship-mounted
wingmen" and given them a range of commands similar to the commands one can give
wingmen (so, for example, in an escort mission, I could instruct Pinguin point-defense
turrets to shoot at missiles threatening mission-critical ships in the convey I am escorting (I have
a tentative function that determines who is most threatened by an approaching missile)
rather than the ones that threaten me. I could instruct Pinguin anti-ship cannon turrets
to target ships that are attacking mission-critical ships in the convoy.

Anyway, it's a start. I'm trying to make this very general, so that any EoC modder
who wants could easily add ship-turrets to his own modded craft. This part is pretty
well defined conceptually and should not be too hard to code. The harder part will be
getting wingman style commands to work sensibly.

Another occasional update:

I am a buggy coder, and am currently debugging a generalization of the
Object package (the Object package provides functions to Create, Change,
Inquire and Delete properties in handles, which is handy for storing
information or for passing results out of called functions to the calling
function. The iObjectPropertiesUtil.pog package, which will be dual-use
(EoC and Unstable Space) absorbs the functions provided in the Unstable
Space tsArray.pog package and adds many more, with good documentation and
error code returns built into the functions to aid in debugging (which I
need ).

The ability to store arrays in object handles is very handy, since it
provides a way of attaching an ordered list of turret-ship handles to the
player-ship handle. It is also useful for passing arrays back to calling
functions (I do wish that Particle Systems had included pointers in its
POG compiler; this would make arrays and returned arguments so much
easier to deal with).

In the interest of general use by other modders, I'm working on some
additional EoC/US dual use utilities packages that should make it easier
to manipulate ship configurations. A lot of this is taking concepts that
are already hard-coded in other places (in Unleashed or in parts of Unstable
Space) and generalizing them to apply to more kinds of data.

The iINIFileUtil.pog package will have a new function (defined, but the
coding awaits the array functions of iObjectPropertiesUtil.pog) that will
return (via an object handle array property) a list of all the numbered
key indexes in a .ini file that match user specified parameters. This
should prove really handy for manipulating ship configurations (which
I need to do to generalize Bineshi's turret-ship concept and which is
also done in the US loadout system).

For example, you might want to get a list of all subsystems that have
defined physical locations on the ship. To do that, you would search
the .ini file for all [Subsim]template&null keys. Or you might want
to get a list of all ship subsystems which have defined positions and
orientations and which have a default docked ship. to do that, you would
search the .ini file with the search key
[Subsims]template&null&null_position&null_orientation&docked_ship

This search function may have uses in accessing .ini files of game objects
other than ships.

I'm still far from being able to dock turret-ships to the Pinguin with the
new code, but there is progress. I'm also beginning to think about the
turret control system that will be needed to make full use of the flexibility
of having turrets that are ships (and so independently AI controllable) rather
than ship subsystems (which are not very controllable given what is available
in the POG SDK.

My tentative thought is to allow the player to assign "batteries" of one
or more turrets that will act together, in analogy to the Unstable Space
wingman system, which allows you to assign wingman ships to numbered wings
and then to give different orders to the different wings. So, on the
Pinguin, you might want to assign the two light-assault cannon turrets
to a single battery to fire together on threat ships designated by a
threat-assessment module (which is mostly in conceptual stages -- sort of
working for missile threats). The two point-defense turrets have very
limited overlap of their fields of fire and would be assigned to separate
one-turret batteries, with orders to independently engage separate missile
threats, or ship threats if no missile threats are in range.

This is all still very preliminary, but I think that it will work. Whether
the threat assessment and turret AI modules running simultaneously for
player ship and non-player turret-equipped ships will bog down the PC
remains to be seen. Hopefully it will all work and then this might create
play balance problems. The Pinguin with 5 turret fighters would be a
very powerful ship, approaching Light Cruiser class. Ships get destroyed
very easily in EoC; much less so in Unstable Space, where they break off
combat and flee to autorepair. I have long thought that ships blow up too
easily in vanilla EoC, and it is not hard in the course of diversions into
anti-Marauder piracy to destroy more Marauder combat vessels that it is
reasonable to suppose exist in the Bandlands Cluster. Vessels should flee
when seriously damaged. They do in Unstable Space and perhaps this is
something that could be ported back into EoC as a separate mod.