It is commonly acknowledged on these forums that FTL Inhibition causes issues for the AI, particularly with its pathing. I think this is probably true. What if instead of blocking hyperlanes, FTL inhibitors instead increased hyperlane jump charge time by a factor of 10 or more?
I'm not opposed to swapping back to slowing down FTL travel rather than blocking, but it really wont change much
gameplay-wise.
- If a fleet is big enough to get through a block, it's going through anyway,
- if it's not big enough it'll die or emergency retreat.
- it's quite rare to see an AI enter then spin around and leave a system - this only happens if your own fleet jumps in whilst they're in-system already but havent yet started combat.
However I'd support this for non-gameplay reasons.
Disabling FTL inhibitors may lead to better performance as taking enemy starbases forces recalculation throughout wars and Pathing is the heaviest AI thread after pops (its also the most mathematically intense and possibly the hardest process to parallelise). It'd also lead to lower memory-overheads I think (not really an issue these days but still a factor); this is because Inhibitors
themselves don't cause issues for the AI. Rather, whenever pathing is broken and the AI is forced to re-calculate that it fails, this is likely because the game doesn't cache its orders in the way some other games handle this sort of thing.
- From my limited tests ive found that adding nodes to the hyperlane network, taking them away or blocking them (But NOT unblocking them) all seem to force a re-calculation.
- Unblocking nodes doesn't force a recalculation, they just get factored in on the next pathing update (imagine youve got 3 doors to go through A and B are open, C is closed, youre half way to A, suddenly C opens, you (the AI) dont change course till "some time" later).
- From this I decided to just outright disable closed borders a few weeks ago on my games and AIs are able to move around a little more intelligently and players (namely me) cant cheese quite so hard by picking systems to block them off, leading to more wars of "border beautification", as I like to call them.
- I imagine disabling FTL inhibitors would only further improve upon this
As an aside, its possible to add multiple auras to an entity. Currently interdictor auras are "hostile_auras = {}" but you can have friendly and "neutral_auras = {}" too, so you could actually rework both FTL inhibitors and border access all at once. Make closed/open borders itself not do anything, but anyone you've closed borders to would now be subject to your FTL snares, so you
can pass through "closed border" space, but by god is it going to take ages.
Knowing that there's a lot of unused assets (that have already been coded and then deleted for some reason) and features that could be restored the broken FTL inhibitor mechanic could be replaced with any number of different mechanics .
They haven't even been deleted there's literally tonnes of stuff lying around in the files, all it takes is a few comments in some cases to get it going again. In other cases a larger re-write is needed.
I've said it for a long time, beyond the FTL/border system (which is what most people gravitate to) what little we gained in military complexity in 2.0 was offset or left
worse in other ways thanks to pre2,0 mechanics(and more complex modifiers) being replaced with over-simplified modifiers and mechanics post2.0
- For example (I assume in the name of performance as the 2.0 economy allows for huge fleets) auras were made to act only on a system-wide (or per fleet/per battle) basis, pre 2.0 they'd act on an Euclidian radial basis (i.e. within 30 units) - with the removal of this code you cant make minefields anymore (as they used to be) or other more interesting items like area-of-effect-blast weapons hitting multiple ships (which could be done with mods, though they were janky.
- I made an event triggered aura ship once that would fly into an enemy fleet and "detonate" itself by triggering a 1-day aura dealing 5000 dmg to all ships in 30 units. Yes Space suicide-bombers were a thing you could mod for pre 2.0)
- Anyway, if we wanted to get minefields back in in the current game, with what we can currently work with:
- add a hostile starbase aura dealing ticking damage to all hostile ships in a system each tick/day/week whatever, or set it to reduce enemy evasion etc (so you could pick from a few diff starbase-unique minefield modules).
- you can weight its chance based on ship properties but i have no idea what performance impact that'd have...maybe better to just weight its chance by ship_class instead (e.g. 0% chance to avoid mines for juggernaughts/titans/colossi, X% for BBs, Y% for CVs, Z% for CRs etc.
- can add a second exclusion block that reduces that chance if they have a "mine nullifier" augment component fitted?
- not sure on this bit you cant actually do as much as you'd think with aura_modifiers. There are a LOT of undocumented restrictions.
- e.g. you can modify hostile evasion (which is an endemic "property" of a ship_entity... but you cannot also use an aura to change that ship's properties so "jumpdrive = yes" (if you could you'd.... be halfway to pre-2.0 wormholes. At the very least you'd be able to make "gate-casters" that can launch your ships one-way across the stars, before swapping to Hyperlanes or looking for another caster, which would be fun)
- (its nowhere near as flavourful as pre 2.0, and PDX gutted the ability to render aura graphics over a volume of space, so no more minefield icons, but thats the best youve got now...)
Solution 1. Restore Snares. Force enemy ships to go where you want them.
+ The old FTL snare was perfect for this. Other solutions include:
+ Increasing engagement radius to the entire gravity well
+ Forcing Ships to enter and exit the system at 100 distance units so they're always in range of the default missile slot
I feel like this is half of the answer. there are exactly 3 defines exposed relating to hyperlanes (though PDX could always do whatever they like with code-access)
- Wind-up (locks ships in place for X/10 days till drive has spooled up), vanilla = 150 (15 days spool up default)
- Wind-down (locks ships in place for X/10 days till drive has spooled down), vanilla = 0 (unused feature right now)
- idk right now if this stops guns from firing in combat, but if not, a modifier could be added which tells ships in wind_down to fully ignore combat, locking them in place, or fight with reduced efficiency and reduce evasion to 0% (like after dropping out from a jump drive) for the wind_down_duration.
- interstellar-speed (reducing this will make ships take longer in transit between stars) and a relic of like pre v.1.2, it'll actually show you a little hyperspace icon at the egress point detailing how many inbound ships there are (this was swept under the rug when they added more galaxy map ship icons shortly after launch, for a time you could even scan FTL trails to learn where a fleet was headed),
-
Interstellar_speed set to 0.1 makes ships waaaay slower (takes multiple weeks to move down long hyperlanes, sometimes and was an exaggerated test of mine) but you also get to see that portal for weeks, which is nice I guess.
- It might be cool if this added a stacking buff to starbases in the system "prepared defence" - starbase deals X% more damage to this incoming fleet for every week it takes to reach the system, stepping up to +100% for example.
That all said, If you want to bring back snares I think
- a constructor could 1 build a "system unique" snare-beacon (just so the game knows where to drop it) and
- then remove ship wind-up time and add back ship wind-down time,
- with starbase "interdictor modules" adding to wind-down time of enemy fleets and
- higher tier hyperdrives (even aux modules "hyperdrive capacitors" "hyperdrive rams" whatever), reducing wind-down times
So you get a dynamic, a push-pull between wind down times, the longer you can extend an enemy fleet's wind-down time, the longer they'll be sitting ducks, indirectly buffing a starbase's ability to fight back.
Will the AI be able to handle this? probably not. It'd be cool though.
Solution 3. Restore those medium and heavy platforms to their former glory.
The models and all that 3D art exists. The mechanic to place them away from the starbase has already been coded once. I don't understand why the functionality was removed. It was a brilliant feature.
This is almost certainly the easiest to do (I think some mods have done it too). I've thought about different ways it could be done, perhaps the easiest is to add a planetary decision to any colonised world or ring segment [not habitats, that'd be weird] :
- "Build [energy/kinetic/missile] orbital defence station" costing alloys and time and
- then have it spawn what was once called a heavy defence platformover the world, auto upgrading its slots to your highest tier for that weapon line.
- An earlier/mid-game version could have it spawn mid-size defence stations instead (as there were tiers, with defence platforms being analogous to small stations)
- If it gets destroyed add a modifier to the world "ruined orbital defences" which unlocks a second cheaper edict "repair orbital defences" that respawns the station and removes the ruined modifier.
- [I say use edicts for this, as the AI is actually quite good at using edicts, if they've got well defined weights and conditions].
- This is also a decent way of bringing back orbital instillations to planets.
- And by midgame (when alloys are usually plentiful) it makes more sense for armies to not be able to land on worlds till their orbital installations have been knocked out too (i'd move the check from "starbase" to "orbital station", so you could land an army on a world w/o capturing the starbase, if no orbital defences are over it,... but I think that might be hard-coded not sure).
.png){kind=avatar}
.png "Screenshot (3977).png")
