Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Sundog]

@Alex: Not much luck using INDIVIDUAL_SHIP_RECOVERY_MOD, sadly. Looking at Misc.isShipRecoverable and FleetEncounterContext.getRecoverableShips, the chance of recoverability is capped at 100% before being multiplied by a value that will be lower than 1 if the ship is destroyed (stats.getBreakProb().modifyMult(id, 0f) doesn't seem to prevent that?) or the player contributed to the battle only partially. Given that, it looks like my options are to override FleetEncounterContext (a cure worse than the disease), or try to find a way to manually insert ships into the list of recoverable ships at the right moment. For now I'll take another crack at that method, but later I might beg you for a simple and clean way to guarantee enemy ship recoverability. I know of at least two other (outdated) mods that needed the same thing.

Edit: Looks like there's also a chance to negate the result of Misc.isShipRecoverable later on as well:

Spoiler

         if (!own && (storyRecovery || normalRecovery)) {
            float per = Global.getSettings().getFloat("probNonOwnNonRecoverablePerDMod");
            float perAlready = Global.getSettings().getFloat("probNonOwnNonRecoverablePerAlreadyRecoverable");
            float max = Global.getSettings().getFloat("probNonOwnNonRecoverableMax");
            int dmods = DModManager.getNumDMods(data.getMember().getVariant());
            
            float assumedAddedDmods = 3f;
            assumedAddedDmods += Global.getSector().getPlayerFleet().getStats().getDynamic().getValue(Stats.SHIP_DMOD_REDUCTION, 0) * 0.5f;
            
            float recoveredSoFar = 0f;
            if (storyRecovery) recoveredSoFar = storyRecoverableShips.size();
            else recoveredSoFar = result.size();
            
            if (random.nextFloat() < Math.min(max, (dmods + assumedAddedDmods) * per) + recoveredSoFar * perAlready) {
               noRecovery = true;
            }
         }

[close]

[Tartiflette]

This is pretty much exactly why I made this thread:
http://fractalsoftworks.com/forum/index.php?topic=20155.0
A way to ensure a ship is always recoverable would be more than welcome. Or at least always recoverable if Flagship if you are concerned with going beyond the 16 ships limit.

[Sundog]

Yeah, a hint like that would be ideal for IBB and HVB ships. In my case it wouldn't do the trick though, as the ships I need to make recoverable don't have unique hull specs.

[Alex]

Made a note. A possible alternative approach: spawn the ship hulk post-battle, make it always recoverable, and flag is as important.

See (bit of a campaign spoiler):

Spoiler

The TTBlackSite class, the Ziggurat encounter works like this...

[close]

[Timid]

Hmm - there's two problems. One is this code will get called every time a fighter spawns. Two, you want to be modifying getFighterWingRange() on the *carrier*, not the fighter.

Hmm.. the 1st code would be bad performance-wise? May I ask for something like getWeaponRangeThreshold(), but in the code of getFighterWingRangeThreshold() ?

[Alex]

No not performance-wise, just it might run more times than you'd want and depending on exactly how your code does the calculation it *could* become incorrect as a result.

May I ask for something like getWeaponRangeThreshold(), but in the code of getFighterWingRangeThreshold() ?

I'll keep that in mind, but honestly, chances are a bit low. What you're doing seems like it ought to work, anyway!

[Sundog]

Made a note. A possible alternative approach: spawn the ship hulk post-battle, make it always recoverable, and flag is as important.

Ah, that makes sense. I'll probably do that since there's vanilla precedent. I'll have to see how those spoilerey things work first though...
Thanks again!

[shoi]

Thanks alex!

I didn't see anything in the changelog, what does "hist1t" do for wings in wing_data tag?

[Sordid]

I'm not sure if this question turns out to be minor or not, but here goes: Is there an easy way to dial down the scaling of fleet sizes as the game goes on?

[theDragn]

This is a bit of a weird one- hotfixes are breaking my modded saves, but not my vanilla ones. The error log indicates that it's my custom submarket (I think), but I have no issues loading saves otherwise. Not a big deal at the end of the day, but since this is the first update I've experienced, I'm wondering if it's simply a consequence of how savefiles work or if it's something I can fix. This only happens with saves from a previous hotfix version, starting a new save in the most current hotfix allows me to save and load the new save without issues.

Errors:

Spoiler

---- Debugging information ----
cause-exception     : com.thoughtworks.xstream.mapper.CannotResolveClassException
cause-message       : com.fs.starfarer.loading.specs.g
class               : java.util.ArrayList
required-type       : java.util.ArrayList
converter-type      : com.thoughtworks.xstream.converters.collections.CollectionConverter
line number         : 173295
class[1]            : com.fs.starfarer.api.util.WeightedRandomPicker
converter-type[1]   : com.thoughtworks.xstream.converters.reflection.ReflectionConverter
class[2]            : plugins.drgSvarogMarketPlugin
class[3]            : com.fs.starfarer.campaign.econ.Submarket
class[4]            : com.fs.starfarer.campaign.econ.Market
class[5]            : com.fs.starfarer.campaign.CustomCampaignEntity
class[6]            : com.fs.util.container.repo.ObjectRepository
class[7]            : com.fs.starfarer.campaign.StarSystem
class[8]            : com.fs.starfarer.campaign.CampaignPlanet
class[9]            : com.fs.starfarer.campaign.CircularOrbit
class[10]           : com.fs.starfarer.api.impl.campaign.fleets.RouteManager$RouteSegment
class[11]           : com.fs.starfarer.api.impl.campaign.fleets.RouteManager$RouteData
class[12]           : com.fs.starfarer.api.impl.campaign.fleets.RouteManager
class[13]           : com.fs.starfarer.campaign.fleet.CampaignFleet
class[14]           : com.fs.starfarer.campaign.ai.NavigationModule$AvoidData
class[15]           : com.fs.starfarer.api.util.TimeoutTracker$ItemData
class[16]           : com.fs.starfarer.api.util.TimeoutTracker
class[17]           : com.fs.starfarer.campaign.ai.NavigationModule
class[18]           : com.fs.starfarer.campaign.ai.ModularFleetAI
class[19]           : com.fs.starfarer.loading.specs.FactionProduction
class[20]           : com.fs.starfarer.campaign.Faction
class[21]           : com.fs.starfarer.campaign.econ.reach.ReachEconomy
class[22]           : com.fs.starfarer.campaign.econ.reach.ReachEconomyStepper
class[23]           : com.fs.starfarer.campaign.econ.Economy
class[24]           : com.fs.starfarer.campaign.StarSystem$UpdateFromHyperspaceLocation
class[25]           : com.fs.starfarer.campaign.BaseLocation$LocationToken
class[26]           : com.fs.starfarer.campaign.Hyperspace
class[27]           : com.fs.starfarer.campaign.CampaignEngine
converter-type[2]   : com.fs.starfarer.campaign.save.I
version             : not available
-------------------------------
com.thoughtworks.xstream.converters.ConversionException:
---- Debugging information ----
cause-exception     : com.thoughtworks.xstream.mapper.CannotResolveClassException
cause-message       : com.fs.starfarer.loading.specs.g
class               : java.util.ArrayList
required-type       : java.util.ArrayList
converter-type      : com.thoughtworks.xstream.converters.collections.CollectionConverter
line number         : 173295
class[1]            : com.fs.starfarer.api.util.WeightedRandomPicker
converter-type[1]   : com.thoughtworks.xstream.converters.reflection.ReflectionConverter
class[2]            : plugins.drgSvarogMarketPlugin
class[3]            : com.fs.starfarer.campaign.econ.Submarket
class[4]            : com.fs.starfarer.campaign.econ.Market
class[5]            : com.fs.starfarer.campaign.CustomCampaignEntity
class[6]            : com.fs.util.container.repo.ObjectRepository
class[7]            : com.fs.starfarer.campaign.StarSystem
class[8]            : com.fs.starfarer.campaign.CampaignPlanet
class[9]            : com.fs.starfarer.campaign.CircularOrbit
class[10]           : com.fs.starfarer.api.impl.campaign.fleets.RouteManager$RouteSegment
class[11]           : com.fs.starfarer.api.impl.campaign.fleets.RouteManager$RouteData
class[12]           : com.fs.starfarer.api.impl.campaign.fleets.RouteManager
class[13]           : com.fs.starfarer.campaign.fleet.CampaignFleet
class[14]           : com.fs.starfarer.campaign.ai.NavigationModule$AvoidData
class[15]           : com.fs.starfarer.api.util.TimeoutTracker$ItemData
class[16]           : com.fs.starfarer.api.util.TimeoutTracker
class[17]           : com.fs.starfarer.campaign.ai.NavigationModule
class[18]           : com.fs.starfarer.campaign.ai.ModularFleetAI
class[19]           : com.fs.starfarer.loading.specs.FactionProduction
class[20]           : com.fs.starfarer.campaign.Faction
class[21]           : com.fs.starfarer.campaign.econ.reach.ReachEconomy
class[22]           : com.fs.starfarer.campaign.econ.reach.ReachEconomyStepper
class[23]           : com.fs.starfarer.campaign.econ.Economy
class[24]           : com.fs.starfarer.campaign.StarSystem$UpdateFromHyperspaceLocation
class[25]           : com.fs.starfarer.campaign.BaseLocation$LocationToken
class[26]           : com.fs.starfarer.campaign.Hyperspace
class[27]           : com.fs.starfarer.campaign.CampaignEngine
converter-type[2]   : com.fs.starfarer.campaign.save.I
version             : not available

[close]

plugins.drgSvarogMarketPlugin is the submarket plugin. It doesn't add any data to a save beyond whatever the base submarket plugins do.

[Alex]

Thanks alex!

I didn't see anything in the changelog, what does "hist1t" do for wings in wing_data tag?

It means the historian you meet at the bar will offer the location of this wing, potentially, as a at tier 1 (hence t1). There are 3 tiers as you give him more credits for research. So, hist1t, hist2t, and hist3t.

This is a bit of a weird one- hotfixes are breaking my modded saves, but not my vanilla ones. The error log indicates that it's my custom submarket (I think), but I have no issues loading saves otherwise. Not a big deal at the end of the day, but since this is the first update I've experienced, I'm wondering if it's simply a consequence of how savefiles work or if it's something I can fix. This only happens with saves from a previous hotfix version, starting a new save in the most current hotfix allows me to save and load the new save without issues.

cause-exception     : com.thoughtworks.xstream.mapper.CannotResolveClassException

The bolded part would indicate to me that this is an issue with the game not being able to find that class. I don't *think* it's hotfix-related.

[theDragn]

The bolded part would indicate to me that this is an issue with the game not being able to find that class. I don't *think* it's hotfix-related.

After some discussion on the modding discord, the issue appears to be that some objects in my custom market plugin (instances of WeightedRandomPicker<ShipHullSpecAPI>) were getting serialized and stored in saves, and then when the version changed, the serialization of the obfuscated class changed and the game failed to find a class with the same data members. Marking them as transient has resolved the issue.

[Alex]

Ah, ok, that makes sense. Definitely not a good idea to store that kind of thing in savefiles, so: probably a good thing it crashed

[Originem]

In 0.95
The cargo picker still not have a scroll bar...
Could that area not only be text panel but CustomPanelAPI?

BTW, I mentioned that the nebula particles(or others?) seems use something like Tex/4 to locate the Sprite texture(I think that's something like Atlas sheet)
So, If I use sprites like that, combine several images into one image, will there be appearent performance improvement?

[Alex]

In 0.95
The cargo picker still not have a scroll bar...
Could that area not only be text panel but CustomPanelAPI?

I can take a look at some point, but honestly, right now there's a lot of other stuff I need to focus on

BTW, I mentioned that the nebula particles(or others?) seems use something like Tex/4 to locate the Sprite texture(I think that's something like Atlas sheet)
So, If I use sprites like that, combine several images into one image, will there be appearent performance improvement?

Right, yeah. If you do this for particle effects it can be helpful. Basically, binding a texture has a performance cost - higher for larger textures, too. So if you *can* bind a texture atlas before doing all your drawing, it can help. It helps more if you do a lot of drawing, like for a particle effect. I wouldn't worry about it too much unless you're really drawing a lot of things.