Some tweaks to Bineshi's "Unleashed" mod

Just imagining the 15 fighter-capacity Pinguin carrier:

There is a iDockport function that locks together two objects that are docked.

I'm imagining a protective shell around the Pinquing cargo bay/hangar deck, with 5 bays each of which has movable doors. This protects the docked fighters from weapon impacts when the doors are closed, and one could code an interlock such that the fighters in a bay cannot be launched (they are locked to their dockports) until the
bay doors are fully open.

Just dreaming, but that would be really cool.

It may be a reason to try to import the US wingman functions back into EoC (a large task -- just something to dream about, perhaps). Then a notional 15 fighter Pinguin could deploy its own little fleet of autonomous fighters with multiple independent flights of one or more craft assigned their own tasks.

Just a note on the status of the tweaks:

I'm working on a "dual-use" (in vanilla EoC and US [and in other EoC mods
also, probably, such as Gold Rush]) mod package that may be called (will consult with
EoC/US Admin) iDockingUtil and that will simplify pod stacking and chaining and many
other docking functions, and will be general enough to permit arbitrary new dockport
types to be used as modders devise new ship types and functions.

The previous images showed some double stacked pods on a Pinguin Armed Merchant
Cruiser and a pod chain towed by a Spider Tug. Those pods were "manually" stacked
with successive commands activated with keystrokes. At the moment, iDockingUtil
can double-stack load any freighter with a single keystroke, and can build a
pod chain of any length behind a Spider Tug with a single keystroke.

This might be handy in the Unleashed mod when the player uses the Pinguin
as a merchant raider. Jafs often flees when scavengers show up to compete for
loose cargo; the player will be able to fly in and hold off competitors with
turrets and the AI Makwa drones while loading cargo that Jafs has dumped our
won't approach.

Just a brief note on the status of "tweaks to Unleashed". I seem to have become an informal member of the Unstable Space development team and have been helping with some debugging. Many features that I had inserted into my local hacked version of the "Unleashed" mod are now residing in a package called DockingUtil.pog that will (I hope) be usable both in Unstable Space and in EoC. Other Unleashed tweaks will go into other "dual use" packages, and I hope to collect these together into a mod for EoC called "vEoCUtilities", for "Vanilla EoC Utilities" which I hope will be compatible with many existing mods.

One of the things I want to bring into EoC from US is the wonderful highly flexible wingmen management functions of Unstable Space. These would be handy in some standard EoC acts/scenes when Cal has several wingmen and might want to break them into multiple groups. This would also be a handy feature for the Unleashed Mod, since the Pinguin has a flight of 5 AI-controlled Makwa drones which could be split into multiple wings if US functions were available within EoC. This might also make larger carriers an interesting possibility within EoC.

Another possibility that intrigues me is the idea of having more control over ship-mounted turrets, which would be useful both in US and in EoC, and with the Pinguin, which has two auto-turrets and two point-defense turrets. I'm currently flying an old Bastille class Destroyer around the Middle States trying to purchase some turrets in order to have some tools to experiment with.

I'll post updates as I have more to report.

If there is interest in a "sooner rather than later" release of the above-mentioned "vEoCUtilities" package, I could bundle up what already exists and attempt to upload an incomplete but usable version of it to the mods page for player experimentation. It does make it easier to collect cargo with the Pinguin -- you can order pods to dock to your ship the way Jafs does. This can facilitate a significant Act 0 insurgency campaign by the adolescent Cal against Maas Corp and the occasional Marauder flight that shows up. That can be useful to accumulate weaponry and other cargo prior to the more demanding missions of Act 1. And, if you also invoke Future Trader, the increased difficulty of cargo accumulation in the Unleashed Mod is alleviated a little.

I'm experiencing an annoying problem in the pod double-stacking function within DockingUtil.pog.

When you dock item A to item B, whichever of the two items had to move to dock to the other becomes the "child" of the stationary item. So pods become the child of the ship to which they dock (not sure what happens when you order the playership to dock to a pod to collect it).
If docking pods to pods (double-stacking or pod-chaining), the additional pods are children of the pods to which they are docked.

And apparently the grandchild pods don't capsule jump with the ship and the daughter pods.

There some SDK functions which allow one to detach a grandchild sim and attach it to the parent ship, but for some reason these do not preserve the position of the grandchild with respect to the parent ship. The double-stacked pods end up floating in space, fixed with respect to the ship, but no longer visibly attached to it.

I'm back in significant "unleashed" mode and I'd like to call attention to something ingenious that Bineshi/Nathan Kinsman did in his Unleashed mod. I mention this because it permits some interesting enhancements and also because this feature is something that, if it were reckoned to be desirable, could be ported to Unstable Space without (I think) disrupting the existing loadout scheme.

In vanilla EoC and likewise in US, turrets on the player ship are a special class of subsystem that can act semiautonomously of the player. The SDK provides functions that could allow a modder/hacker to create a function that trains the turrets on any target the player specifies. The default mode in EoC and also in US (AFAIK) is to have turrets fire at contact list hostile "targets of opportunity" within their respective fire arcs. So there are three turret fire modes:

a) no fire (weapons locked down)
b) player designated target
c) target of opportunity on the contact list

And there are SDK functions that let you implement each of these.

option b) above gives the player limited control over the turrets. He can tell them to fire at his designated target and, if they can train on it, they will. A function would need to be coded to do this -- I'll stick that into a "dual use" EoC/US utility package called "iTargeting.pog". I suspect that a turret in mode "b" that cannot see its target will not fire on anything.

The player cannot assign different targets to different turrets. This is highly unreasonable as a within-game-world limitation. If the turrets were manned by humans, they could independently target distinct player-designated targets; likewise if they were controlled by autonomous AI systems. This is a coding convenience, and perhaps also a game-play simplicity issue, since it would be a bit of work for the player to assign different targets to different turrets in the midst of a fight.

Now to Bineshi's Unleashed innovations.

Bineshi/Nathan Kinsman reconceptualized turrets as ships in their own right. They have no propulsion (unless the turret in question is a turret fighter) and so are stuck on the ship location to which they are mounted.

But because each "Unleashed-style" turret is a ship in its own right, it can be assigned its own target, or its own targeting rules. The "point defense" turrets in Unleashed, for example, only shoot at missiles, but that limitation is a software limitation coded within the Unleashed package. These turrets can in principle fire at anything, but the Unleashed targeting rules limit them to missiles closer than 8km.

So, these turrets are essentially permanently attached turret fighters and should be thought of as "wingmen" rather than ship subsystems. This leads to several interesting possibilities:

1) Each turret on a ship or gunstar or station can be assigned its own targets and/or its own targeting rules. On a large object such as a gunstar or station, the targeting rules might result in different turrets engaging different targets, especially if some turrets cannot see the target(s) of the other turrets. I'm not sure whether this happens in vanilla EoC but it surely is feasible within the game-world technology.

2) One can imagine "smart" turret targeting that assesses the threat of each potential target and that also assesses damage. Turrets might work in pairs to beat down shields on target ships and increase the fraction of shots that reach the target hull.

3) The point defense turrets are not very powerful, but when there are no missile threats, they could be trained on attacking ships.

4) The auto-turrets have a lower rate of fire than the PD turrets, but when there are no ship threats within effective range, they could be trained on missile threats.

5) the wonderful US wingman system could be generalized to "attached ship-style" turrets to allow them to engage multiple player-designated targets.

6) one could envisage classes of turret orders or targeting rules or "rules of engagement" that could be precoded and assigned at need.

I have started into a new (hopefully) dual-use package, "iTargetingUtil.pog" that will attempt to implement some of these ideas. It will be built only with the original EoC/SDK functions so that it can work within both EoC and US. I'll also look into porting the US wingman functions back into EoC. The Pinguin has a flight of five drone wingmen, and some EoC missions give Cal additional helpers, so there are occasions where Cal may have as many as 10 wingmen and the added flexibility of the US wingman system would come in really handy.

Some iTargetingUtil functions will eventually be ported back into Unleashed to, at the very least, improve the missile targeting algorithm for the playership Pinguin point-defense turrets.

Another interesting feature of the Unleashed approach to turrets is that it may allow one to exceed the game code limit of two functional turret fighters on the player ship. The EoC loadout scheme limits you to two, but Unleashed intervenes after launch to populate the spine of the Pinguin with as many turret fighters as are in inventory, up to the limit of the 5 spine fighter ports. The Pinguin's turret fighters are 5 AI drones (souped-up Storm Petrel interceptors). I'm not sure whether that the standard turret fighter orders work with these, but I suspect that they do not (I never used them in that mode in prior games as they are much more useful launched as a wing of super-maneuvable AI-controlled fighters. If, this time through, the turret fighter commands turn out to not work for the Pinguing and its drone flight, then it may be possible, using Unstable Space wingman commands, to form the five docked turret fighters into a single wing while still attached to the Pinguin and instruct them to fire as a broadside on the designated target.

More on Bineshi's ingenious implementation of "smart turrets" and some thoughts on how to make this more widely applicable in EoC and possibly also how to port it to Unstable Space.

As I work through the code of the Unleashed mod, I continue to be filled with admiration for Bineshi's/Nathan Kinsman's ideas, and also for the great flexibility that Particle Systems built into their POG SDK.

The vanilla EoC loadout system does not allow you to mount ships wherever you wish on a modded player-ship -- indeed, you can't mount ships at all (except for up to two turret fighters).

Bineshi worked around this with a special function in the main iUnleashed.pog package that is invoked whenever the player ship leaves the Biobomber base. There are special dockports in the .ini file of the player-ship pinguin (this is in the storm_petrel.ini file since one is obliged to use one of the four pre-defined player ship .ini files when modding the player ship in vanilla EoC) called

turret_port

with type-flags = 32 (this is the universal dockport, IIRC)

The special function that is invoked when the player-ship leaves the biobomber tests the player ship to see if it has any of these special turret_port subsystems, and if it does, it assumes that the ship is the Pinguin, and it populates them with "ship-style" (ie, these are ship sims functioning as turrets) autoturrets and point defense turrets (two of each). It locks the docking lock between each turret and its respective turret port and then puts (what I think is) a passive AI pilot into each turret and then locks the turret's weapons down.

Other functions activate the turrets when there are ship or missile threats in range.

---

How to generalize these ideas to make them more widely useful within EoC mods?

I'll make some definitions here for the sake of clarity in the following discussion:

a) turret-subsystem = current EoC style turrets (which are a kind of weapon subsystems that is defined to be part of the ship in the ship.ini file [or in some cases is mountable to the player ship through the vanilla EoC loadout system])

b) turret-ship = Bineshi's innovation = an armed turret that is a ship in its own right that must be docked to another ship in order to function as a ship weapon.

turret-fighters, which already exist in vanilla EoC, could be thought of as a special self-mobile form of turret-ship that can undock from its mounting dockport and independently fly as a wingman.

c) turret-mountport = a special dockport to which a turret-ship must be mounted in order to function as a ship weapon.


1) the basic idea of mounting "ship-style" turrets at a game event such as "Enter Space" (player leaves the biobomber) is necessary because the ship.ini files don't allow you to mount one ship onto another as a matter of vessel definition.


So we need a general purpose function to "populate turret-ship turret-mount-ports with appropriate turrets". This function could also be used to mount turret-ships onto non-player ships, or onto stations or gunstars in order to provide those structures with the smart-targeting and independent targeting capabilities that the player ship will (eventually, see prior posts) have.

2) The Unleashed mod defines the number and kind of turret-ship on the player-ship Pinguin and on other ships (the Marauder corvette chin turret is a turret fighter, I believe, for example)

To make this more general, we need a way for the game to know how many and what kind of turrets the modder has defined in the .ini file.

This is not too hard for non-player ships (for which the ship .ini file is visible to the game. You could define a special distinct turret-mount dockport name for each distinct kind of turret-ship, and the turret-setup function would simply match turret-ship to turret-mount.

(As an aside, I would like to try putting a pair of point defense turrets on the old-style gunstars. This should make them much more survivable)

For the player-ship, this is trickier because the .ini file is not visible to the game (or at least not to the SDK functions; an impediment PS inflicted on modders for some reason).

I speculate that there may be a way to work around this by temporarily putting the player-pilot into another ship (perhaps an invisible flitter docked at the "crew" ship location). With the original player-ship now a non-player-ship, perhaps the .ini file would be visible.

3) this more general "populate ship/gunstar/station" with turret-ships would be callable at any game event that involved the creation of a ship, a station or a gunstar.

4) Additional special function calls would be needed to activate these turrets and manage their engagement with local threats. One could imagine a basic "turret-ship" monitor function that checks each turret-ship within range of the player ship, determines whether it faces any threats, verifies that the threat it has been firing on (if any) is still alive, is still in the turret fire arc, and is still a significant threat, and then adjusts orders as necessary). Hopefully this monitor function would not significantly slow the game. Such a basic monitor function might be able to simultaneously manage all turret-ships belonging to all factions as once.

5) further additional functions would be wanted to give the player (and notional non-player AI executive functions, such as nps commanders, gunstar commanders and station commanders) further flexibility in how the turrets are used (per prior posts)


---

The above 5 items will focus my efforts to move Bineshi's turret concepts into a "general purpose utility" form for wider use in EoC.

===

The notional "iTurretsUtil.pog" package would be dual-use, also callable within Unstable Space, but the Unstable Space loadout scheme is substantially different from that of vanilla EoC. Some further features would be needed in a supplementary "usTurretsUtil.pog" package.

In Unstable Space, ship loadouts are changed with a "Ship Fitter" function that is accessible when near certain stations which have dockyard-type facilities. Turrets can be mounted to or dismounted from special ship turret system mountpoints.

This system works well and it would be best not to change it. How to "overlay" smart-turrets (turret-ships) onto this system?

The Subsim package of the SDK has functions to create, place, orient and destroy subsims.

One could conceive of an additional "usTurretUtil.pog" package with a functon that would be invoked to prepare the ship for the invocation of the "iTurretUtil.pog" function to populate turret mounts with turrets.

This "usTurretUtil.pog" function would examine the ship to see what turret subsystems were present, and would destroy these and replace them with properly oriented turret-mounts of the type appropriate to each turret (alternately and more simply, the turret-mounts could be part of the original ship .ini files -- these special dockports would need to be disabled when the ship is first created to remove the possibility of odd docking behavior). Then the "iTurretUtil.pog" function would be called to populate these turret-mounts with turret-ships of the right kind to exactly replace the turret subsystems which had previously been removed.

This would require the creation of turret-ships with the exact same appearance and weaponry as the current Unstable Space turrets, and with turret-ship compatible dockports properly positioned on them so that when they dock to their respective turret-mounts, they are in the same positions as the turret subsystems they replace. There might be added complexities in reproducing the US damage model on turret subsystems and the dependence of turret subsystems on ship power (a ship-turret has its own independent power supply)

---

I think that this will work and it would bring the much-increased flexibility of Bineshi's/Nathan Kinsman's turret concepts into the Unstable Space world.

It also illustrates a concept that I like very much, which is that of "dual use" packages that work in both vanilla EoC and in Unstable Space, but which when necessary are further enhanced with additional Unstable Space overlay packages (which call the vanilla package functions)