Fractal Softworks Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Starsector 0.98a is out! (03/27/25)

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Dark.Revenant

Pages: [1] 2 3 ... 5
1
Long-lasting fleets which persist in a deflated state seem to unexpectedly have some uniform (but low, like 20%) CR upon observation in the wild.  It's unclear whether this applies to fleets which are first inflated and then deflated, or all uninflated fleets in general.  I don't know the exact CR percentage they drop to, but it's uniform across the entire fleet and is distinctly not critical CR: the bar is yellow, not red.  Upon inflation, the fleet recovers CR as usual, but it seemingly remains at a low CR permanently until it's inflated.  I do not know which specific conditions trigger the problem, but it becomes quite consistent if a fleet remains deflated for a very long time.

This is a regression of behavior compared to 0.97a-RC11.  For important fleets (i.e., bounties and such), an easy workaround is to keep the fleets permanently inflated, but this still seems like a real problem.

2
Bug Reports & Support / [0.98a-RC7] Main Menu Missions Unlock Codex
« on: April 02, 2025, 08:19:52 PM »
If you press F2 (and possibly some other conditions might cause this?) on any ship in a mission, a couple of the ships on (at least) your side in that mission are immediately unlocked in the Codex.  Weirdly, it doesn't unlock all of them at the same time: when I say a couple, I literally mean two.  It's very strange.  This doesn't affect vanilla presently, but will probably cause problems if David ever adds wacky missions.

3
In the fleet screen, Venture's description is:

Quote
Tough, dependable and not overly expensive, Venture-class cruisers are usually purchased by private corporations for escort duty or refitted by small non-aligned worlds for system defense.

It should be:

Quote
Tough and dependable, the Venture is usually fitted with a good missile complement but lacks the sustained damage output needed to do well in prolonged engagements. A built-in mining drone bay provides additional defenses - a particularly good thing because the civilian-grade power generators make the shields easy to overwhelm.

4
combatFreighterCombatUseFractionWhenPriority is set to 0.2 and a large-sized combat freighter (for example the Venture) is marked Priority.  No other ships are marked Priority.

Expected behavior: 20% of cruisers will be Ventures.
Actual behavior: 100% of cruisers are Ventures.

Expected behavior is established if (in the above example), all cruiser-sized ships are marked Priority.  In effect, the Priority is overriding the CombatUseFraction; a fraction of 0 means no Ventures, a fraction of >0 means all Ventures; 0.2 is essentially identical to 1.

5
Likely unintentional.  The Tri-Tachyon don't spawn the Wolf either.  The regular Wolf seems to be, bizarrely, a mercenary exclusive.

Oddly, the independents have the Hyperion and Scarab, but the mercenaries don't.

Also, I don't know if it's actually affecting anything, but the variant overrides for the Luddic Path are oddly weighted at 30 instead of the usual 10.

6
Fleet danger assessment is impacted far too much by the presence of d-mods.  This is most noticeable with the Remnant ghost, since it's comprised of powerful, officered ships that are covered in d-mods%u2014especially carriers, which are not as negatively affected by d-mods as other types of ships.  At one point it showed me a 2-star assessment, which I was skeptical of... so I saved and tried to fight it.  It was a one-sided slaughter; I had absolutely no hope of victory.

Internally, 0 d-mods is a 1.5x multiplier within the strength assessor in Misc, and each d-mod reduces that multiplier by 0.2, to a minimum of 0.5x after five d-mods.  Thus a ship with 5 d-mods has a 0.5x strength multiplier, i.e. 1/3 the strength of an otherwise identical but fully restored ship.  This is frankly way too much with the current d-mod effects.


Generally speaking, a ship with half the stats in a few major categories is roughly half the performance, if we ignore the finer points about armor cells and weapon/engine mounts.  I'd say there are about four stats that, if you were to halve all of them, would result in a half-strength ship: flux capacity, flux dissipation, hull, and armor.  Other major stats that would have similar impact include speed, maneuverability, range, shield/phase efficiency, and CR.  For carriers, the impact is split between d-mods that affect the mothership, and d-mods that affect the fighters.  This generally means that carriers are affected less by d-mods, since they get the same severity of d-mods as regular combat ships, but comparatively less of their performance is affected by them.

Specifically:
Compromised Armor: -20% to one stat.
Compromised Hull: -30% to one stat.
Damaged Flight Deck: -30% to one particularly major carrier stat.
Damaged Weapon Mounts: -30% to one relatively minor stat, -25% to one relatively minor stat.
Defective Manufactory: -25% to two carrier stats.
Degraded Engines: -15% to two stats.
Degraded Life Support: -7.5% to one particularly major stat.
Degraded Shields: -10% to one particularly major stat.
Erratic Fuel Injector: -20% to one relatively minor stat.
Faulty Power Grid: -15% to two stats.
Glitched Sensor Array: -10% to one particularly major stat.
Increased Maintenance: -7.5% to one particularly major stat.
Malfunctioning Comms: -40% to one carrier stat.
Phase Coil Instability: -33% to one stat and -30% to one relatively minor stat.
Structural Damage: -20% to two stats.
Unreliable Subsystems: -30% to one relatively minor stat.

Mathematically, on average for a non-carrier ship, each d-mod is equivalent to a 6% penalty to the ship's performance, going by the 4-stat theory.  This is consistent with Derelict Operations reducing the deployment cost by 6% per d-mod.  If a carrier's performance is evenly split between fighters and direct combat strength, then it's more like a 3.5% penalty for those carriers.  For shieldless/phaseless ships, flux capacity is barely a minor stat, so the overall pool of meaningful stats is lower and we can approximate about an 8% penalty per d-mod.

That 6% figure is far smaller than the roughly 13.5% penalty that the strength assessment algorithm currently assumes, and for carriers it's almost twice as bad.


If it were instead a 1.2x multiplier with 0 d-mods and -0.08x per d-mod, it would still conservatively overestimate the effects of d-mods, but that's fine because compound penalties tend to be slightly exponential when applied to a single ship.  The 5 d-mod remnant ships would be treated as 2/3 their original strength, rather than 1/3; in other words, it would show four or five stars of danger instead of two, which feels way more accurate.  This could be further broken down to react differently with regards to carriers, perhaps by decreasing the penalty to 0.065x for combat carriers and 0.05x for pure carriers.  I'd suggest a similar thing for Derelict Operations as well; the 6% DP reduction really ought to be 3% or 4% for carriers.

This has trickle-down effects to ship quality from the inflater parameters and, by extension, the faction doctrine system.  Right now, ship quality is rather important for auto-resolve strength, but ship quantity does way more for actually winning battles in-engine.  As an aside: officers are also slightly overestimated (+20% ship strength per level); it's probably closer to +15%, but that's close enough for a rough estimate because stacking bonuses tend to be slightly exponential when applied to a single ship.

7
Bug Reports & Support / [0.95a-RC15] Raid-for-blueprints exploit
« on: May 12, 2021, 12:30:00 PM »
It is possible, by judiciously refusing to learn the 4 most expensive blueprints known by a faction, to manipulate the ground raid blueprint picker into always providing duplicates of those expensive blueprints.



This can result in consistently over a million credits of looted value per raid, from blueprints alone.

Side note: getQuantityRange() appears to always produce the result of 3-4 blueprints, because bpUseScale is typically over 1000 and the top bracket looks for 8+.  I don't know if that's intentional.

8
The Codex strips any ship with d-mods.  Unfortunately, this means the Luddic Path skins, the Mudskipper Mk.2, and mod-added base hulls such as the Venom-X from Underworld don't show up in the Codex.

I suggest disabling this behavior and just adding HIDE_IN_CODEX to the old D-skins.

9
For instance, if a ship has no or few Fighter Bays in the main hull, but several Fighter Bays on modules, you’re making off like a bandit.

10
See subject.  Unsure if it happens 100% of the time, but it's noticeable often.  You see the true values when you close and reopen the weapon groups dialog.

11
As the title says.  This could make early game colonization a bit safer and more interactive, and help make small colonies later down the line require less babysitting.

12
Code
105881 [Thread-4] ERROR com.fs.starfarer.combat.CombatMain  - java.lang.NullPointerException
java.lang.NullPointerException
at com.fs.starfarer.ui.A.new.super(Unknown Source)
at com.fs.starfarer.ui.A.new.<init>(Unknown Source)
at com.fs.starfarer.campaign.ui.String.<init>(Unknown Source)
at com.fs.starfarer.ui.P.super(Unknown Source)
at com.fs.starfarer.campaign.ui.oOOo.addIconFor(Unknown Source)
at com.fs.starfarer.campaign.ui.oOOo.<init>(Unknown Source)
at com.fs.starfarer.ui.impl.StandardTooltipV2$9.public.float(Unknown Source)
at com.fs.starfarer.ui.impl.StandardTooltipV2$9.beforeShown(Unknown Source)
at com.fs.starfarer.campaign.C.o00000(Unknown Source)
at com.fs.starfarer.campaign.CampaignEngine.advance(Unknown Source)
at com.fs.starfarer.campaign.CampaignState.advance(Unknown Source)
at com.fs.starfarer.BaseGameState.traverse(Unknown Source)
at com.fs.state.AppDriver.begin(Unknown Source)
at com.fs.starfarer.combat.CombatMain.main(Unknown Source)
at com.fs.starfarer.StarfarerLauncher$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

This crash is triggered when the player mouses over an NPC fleet when the following combination of conditions apply:
  • A ship-with-modules is present in the fleet
  • That ship-with-modules has a cloned or otherwise custom variant with the REFIT variant source (i.e. it's permanently inflated)
  • The game was previously saved whilst the fleet existed in the game world

There does not appear to be a workaround with regards to cloning or otherwise changing the IDs of the module variants.  I have not tried resetting the module variants to be stock variants, but that would defeat the purpose of the feature I was adding.

I can't begin to imagine what the root cause of this crash is, and I'm out of ideas to fix it on my end.

13
General Discussion / Station Balance - Methodical Analysis
« on: July 31, 2019, 01:38:38 AM »
As I personally have never created a station in Starsector before, and yet am endeavoring to do so, I reasoned that I need a repeatable test procedure to measure stations.  This would help me determine the overall strength of the station, at least as a reasonable preliminary balance point.

After creating a test-bench and a methodology to go along with it, I began measuring the vanilla stations to establish a baseline to judge my own creations upon.  This led me to some interesting discoveries that, in some cases, confirm "metagame" assumptions about the stations.  In other cases, however, the test results directly contradict accepted "metagame" knowledge.

Test Method
  • Use a battle size of 500, and all other gameplay settings (such as max ships per fleet) are left at vanilla defaults.
  • Use the mods Ship and Weapon Pack, Underworld, Interstellar Imperium, and any applicable faction mod required to spawn the station being tested.
    • The rationale for this is simple: my goal for this was ultimately to make Imperium stations, so that mod contains the testbench and is included by default.
    • In addition, SWP is required for the procedural faction framework I used.
    • Since the Imperium and SWP mods are already included, I added Underworld because just about everyone who is playing with the former two mods will be using UW as well.
  • Spawn a 100%-CR station, no officer, no auto-fit, for the player side and assign full control of the fleet and station to the AI.
  • Generate a procedural faction with unweighted access to the ships, weapons, fighters, and hull mods available to all other factions (including derelicts and remnants) - using the following doctrine:
    • Warships 3 / Carriers 2 / Phase Ships 2
    • Officers 2 / Ship Quality 3 / Fleet Size 2
    • Ship Size 3
    • Aggression 3
    • Combat Freighter Fraction 1.0
    • Auto-fit Randomize 0.1
  • Select a fleet size, in FP (Fleet Points) according to the following logic:
    • If this is the first test, begin at the best guess of the tester (e.g. 100 FP for an orbital station).
    • Otherwise, adjust by some constant number of FP (typically 5% of the original guess): up, if the station won the last bout; down, if the station lost the last bout.
  • Spawn a 70%-CR fleet of the faction and size described above, no officers, using auto-fit, no D-mods, for the enemy side - and use starting command points equal to the fleet size divided by 40, rounding down.
  • Repeat the previous step up to 1,000 times if the fleet's size does not match the target size, choosing the single fleet that wound up closest to what we want.
  • Generate a random battle scenario using the same algorithms/parameters as a campaign station battle.
    • Non-hyperspace.
    • 50% chance of being in a nebula.
    • 48.8% chance of being in an asteroid field; 1-20 asteroids nearby if so.
    • 43.8% chance of being in at least one ring system; 6.3% chance of being in two ring systems.
    • Fixed standoff range of 6000 units.
  • The enemy is not allowed to retreat, must fight to the last, and must deploy all ships.
  • Repeat the test until a minimum of 10 bouts of mixed or unpredictable outcomes (i.e. a mix of Win and Lose) has been observed.
  • The final score is the sum of the fleet sizes of the last 9 bouts plus the fleet size the following bout would have been (had the test continued), divided by 10, rounded to a whole number.

The generated scenario isn't meant to be perfectly realistic to a particular in-game scenario, but rather something that won't be unfairly biased towards one particular fleet composition over another.  The following represents a typical max-strength fleet:


To speed up testing, a plugin automatically speeds the game up such that the internal game logic is running at 1/30 second intervals at the fastest possible speed, limited by the refresh rate and system hardware.

Results
Low Tech Orbital Station: 124 FP
Midline Orbital Station: 135 FP
High Tech Orbital Station: 161 FP

Midline Battlestation: 207 FP
High Tech Battlestation: 245 FP
Low Tech Battlestation: 253 FP

Low Tech Star Fortress: 346 FP
High Tech Star Fortress: 354 FP
Midline Star Fortress: 358 FP

Damaged Remnant Station: 173 FP
Remnant Station: 370 FP

Shadowyards Orbital Station: 170 FP
Shadowyards Battlestation: 333 FP
Shadowyards Star Fortress: 394 FP

OCI Orbital Station: 205 FP
OCI Battlestation: 490 FP
OCI Star Fortress: 579+ FP

Note: the OCI Star Fortress is literally off the chart.  I couldn't generate fleets above ~600 FP, as the test method essentially broke down and couldn't scale high enough to produce an accurate score.

Analysis
Aside from the Remnant Stations and the High Tech Orbital Station, the tested FP scores are not that far off from the advertised FP scores in the game files.

As for balance between the tech levels, at least when it comes to a station soloing an AI fleet, the star fortresses are all basically balanced with each other.  As for the battlestations, Midline is a clear loser - perhaps because of the lack of armor and dissipation on the main module.  For the orbital stations, High Tech is the runaway winner thanks to how strong those shields are.

The big surprises are:
  • Midline is strongly competitive at tier 3, even though it is lagging behind at tiers 1-2.
  • High Tech is not utterly dominant (other than at tier 1).
  • Low Tech is strongly competitive at tiers 2-3.

However, let us not forget a few important facts about the vanilla stations that significantly color the overall experience players have with them, observed through gameplay and many hours of looking at AI tests:
  • Low Tech stations tend to incite AI glitches at an alarming rate, particularly with regards to shooting through/at invincible modules, wasting ammo and flux to achieve nothing.
  • Midline stations are disproportionately easy to dispatch by a clever player by taking out the protective spurs and sending precise shots through the shield gap towards the main broadside section.
  • High Tech stations are reportedly frustrating and dangerous to fight because of how their shields work and of the ship-loss risk the mine strike modules pose.

If we assume that 60 FP with this test methodology is a "level 1" threat (on a scale from 0 to 10), we have the following threat classifications:
Orbital Station: Level 2
Damaged Remnant Station: Level 3
Battlestation: Level 4
Star Fortress: Level 6
Remnant Station: Level 6

A level 0 threat is a truly beginner challenge solvable by the tutorial fleet, while level 10 represents a challenge that requires game mastery to overcome, because it isn't possible to overcome through sheer numbers.  While I think a level 20 officer on a station affects the station more than a bunch of level 20 officers in the player fleet affect the player's fleet (considering you're boosting 100% of the station and perhaps 37% of the player's fleet), there is definitely still room to include even tougher threats in the campaign world.

14
Bug Reports & Support / ShipAPI.getShipAI() CTD when used on shuttle
« on: June 19, 2019, 09:52:08 PM »
This log should be self-explanatory:
Code
228287 [Thread-4] ERROR com.fs.starfarer.combat.CombatMain  - java.lang.ClassCastException: com.fs.starfarer.combat.ai.movement.maneuvers.TransferCommandAI cannot be cast to com.fs.starfarer.api.combat.ShipAIPlugin
java.lang.ClassCastException: com.fs.starfarer.combat.ai.movement.maneuvers.TransferCommandAI cannot be cast to com.fs.starfarer.api.combat.ShipAIPlugin
at com.fs.starfarer.combat.entities.Ship.getShipAI(Unknown Source)
at data.scripts.everyframe.II_TitanPlugin.advance(II_TitanPlugin.java:698)
at com.fs.starfarer.title.Object.float$Oo.o00000(Unknown Source)
at com.fs.starfarer.combat.oOOO.B.super(Unknown Source)
at com.fs.starfarer.combat.CombatEngine.advanceInner(Unknown Source)
at com.fs.starfarer.combat.CombatEngine.advance(Unknown Source)
at com.fs.starfarer.combat.CombatState.traverse(Unknown Source)
at com.fs.state.AppDriver.begin(Unknown Source)
at com.fs.starfarer.combat.CombatMain.main(Unknown Source)
at com.fs.starfarer.StarfarerLauncher$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Tagged as not a mod-related bug because of the high likelihood that some vanilla script might use this method and would, therefore, suffer from the issue.

15
Suggestions / Annoying Suicidal Patrols
« on: June 26, 2018, 02:10:01 PM »
https://youtu.be/_V1gXc198Xs

In my eyes, the ideal workflow for transponder-off patrol interrupts would be that the patrol first asks for compliance as normal, but the patrol would decide how to respond to the player's action with the following logic:

* Comply, Hostile: Pull in allied fleets and evaluate confidence of combined fleets.
* Comply, Friendly: No change.
* Refuse: Pull in allied fleets and evaluate confidence of combined fleets.  Mark player fleet as hostile.

If hostile:
* AI picks Engage: Prevent escape.
* AI picks Standby/Disengage: Standby and deliver a stern warning.  Perhaps additional rep loss.

Pages: [1] 2 3 ... 5