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

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.

31

Mods / Re: [0.9.1a] Vayra's Sector v.2.3.0b (Dev build available 2019-06-18)

« on: June 23, 2019, 09:11:44 PM »

having the same issue with the communist clouds hullmods thing. updated to newest version. deleted previous varyas mod folder before installing. checked the version number in the folder, it is v2.3.ob. im guessing this isnt savegame compatible? would i need to delete both this and nexrelin and the reapply them?

You would need to start a new game I think, sorry.

I have now 3 'La Revolutionnaire' Starbases around one of my system. I believe one is added each time I load a saved game.

How can I destroy them, they can't be captured?

Can you take a screenshot? I'm not 100% sure I understand what's going on here.

Docked at L'Interstellaire, had to take a break cause I started laughing too hard

  <3

I can confirm the multiple instances of L'Interstellaire stations floating around in hyperspace. When I was playing the other day I was surprised to discover a second L'Interstellaire station on my way to eliminating a random pirate base. Out of curiosity, I used the console commands to enter DevMode and hit CTRL-Z to reveal the entire hyperspace map. It revealed several more instances of the station (I think there were like five or six total), all with the same name. Oddly, the faction directory ('Z' from Nexerelin) only listed the Persean Democratic People's Revolutionary Council as having "1 hidden market" despite all of the stations. I should mention that this was with v2.3.0a (and my fake "communist_clouds" hullmod fix I mentioned previously) and I no longer have that save file to get any screenshots. And I've got the Popular Front disabled in my latest campaign, so I can't say whether it's still an issue with v2.3.0b. (I'd seen mention of a save file bloat issue, and disabled that particular feature thinking whatever was spawning more and more stations might be part of the problem...)

On a side note, I nearly did a spit-take on my monitor the first time I heard the communist_clouds theme...

32

Mods / Re: [0.9.1a] Shadowyards Reconstruction Authority 0.8.7rc2(05/15/19)

« on: June 17, 2019, 08:24:19 AM »

The Red Guard are variants of ships used by the "Persean Democratic People's Revolutionary Council" (a.k.a "communist_clouds") faction in the Kadur Remnant/Vayra's Sector mod. Basically, they are repainted versions of vanilla ships like the Hammerhead, Lasher, etc used only by that faction. Those ship variants are included in the Vayra's Sector mod.

However, in a collaborative effort, several of the Shadowyard ships were also given new skins for use with that "Revolutionary Council" faction in the Vayra's Sector mod. Those special repainted versions of the Clade, Enlil, etc. can be identified with the (RC) appended to their hull name (Clade (RC), Enlil (RC), etc.) - similar to how you can find pirate versions of some of those ships like the Clade (P). All of these special Shadowyard ship skins are included in the Shadowyards mod.

In other words, both mods contain Red Guard/Revolutionary Council ships...

33

Mods / Re: [0.9.1a] Vayra's Sector v.2.3.0a (Dev build available 2019-06-10)

« on: June 17, 2019, 07:41:04 AM »

The Red Guard is the variant name used by the "Persean Democratic People's Revolutionary Council" (i.e. the "communist_clouds") faction's ships. Their fleets frequently consist of ship variants like the Red Guard Hammerhead - which is basically a normal Hammerhead with a new red paint job. The faction itself is one of the colonial competitors that occasionally sends out fleets to colonize other planets. The colonial competitors feature is optional though, so you have to enable it for a chance to see them and their Red Guard ships. (And that feature was disabled by default in older builds of this mod, so you might have never seen them before...)

With that being said, I'm not sure the "Red Guard" name is actually used anywhere other than in the ship variant's name, so I probably should have called them "Revolutionary Council ships" for clarity. Sorry for any confusion...

34

Mods / Re: [0.9.1a] Vayra's Sector v.2.3.0a (Dev build available 2019-06-10)

« on: June 15, 2019, 07:51:58 AM »

Hi Vayra! Long time lurker, first time poster.

I ran into this problem that caused a crash every time I mouse over a communist cloud fleet.

Spoiler

579973 [Thread-4] ERROR com.fs.starfarer.combat.CombatMain  - java.lang.RuntimeException: Hullmod communist_clouds not found!
java.lang.RuntimeException: Hullmod communist_clouds not found!
   at com.fs.starfarer.loading.specs.HullVariantSpec.getAllMods(Unknown Source)
   at com.fs.starfarer.prototype.Utils.o00000(Unknown Source)
   at com.fs.starfarer.settings.StarfarerSettings$1.computeNumFighterBays(Unknown Source)
   at com.fs.starfarer.api.plugins.impl.CoreAutofitPlugin.fitFighters(CoreAutofitPlugin.java:918)
   at com.fs.starfarer.api.plugins.impl.CoreAutofitPlugin.doFit(CoreAutofitPlugin.java:363)
   at com.fs.starfarer.api.impl.campaign.fleets.DefaultFleetInflater.inflate(DefaultFleetInflater.java:406)
   at com.fs.starfarer.campaign.fleet.CampaignFleet.inflateIfNeeded(Unknown Source)
   at com.fs.starfarer.ui.impl.StandardTooltipV2.createFleetTooltip(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)

[close]

yeah both the java and the entry in the hull_mods.csv is missing for that one, i guess it was simply missed 

I'm sure Vayra will have it fixed in no time, but until then just add an entry to the hull_mods.csv for that to point to, (you can just copy/paste another mod and change the ID)

From looking at the code, I think it's designed to add a faction-specific hullmod to Red Guard ships created by other game mods. For example, it would add something like the built-in People's Armada hullmod to the special Red Guard variants added by the Shadowyards mod. Unfortunately, the "communist_clouds" hullmod it attempts to add doesn't actually exist so the game crashes. Anyway, I can confirm that the temporary workaround mentioned above will prevent the crash if you just copy/paste the existing "People's Armada" entry and change the id from "vayra_red_army" to "communist_clouds" in the copied version.

I should probably note that this workaround doesn't seem to actually add the "People's Armada" hullmod to Shadowyards-based hulls as I expected though - not sure what's up with that...

35

Mods / Re: [0.9.1a] Vayra's Sector v.2.3.0 (Dev build available 2019-06-09)

« on: June 10, 2019, 07:44:34 AM »

After a few battles of cursing at my Sphinx allies for repeatedly ignoring my retreat orders, I decided to watch one of them more closely in the next fight. What I discovered is that they constantly fire their drive system while attempting to retreat. While this is a perfectly valid tactic when doing a direct retreat facing away from the enemy, it is a fatal strategy when trying to do a tactical retreat with the ship's frontal shields facing towards the enemy. (Basically, the ship just keeps charging back towards the enemy ships faster than it can back away...)

Out of curiosity, I glanced at the AI logic in Kadur_RamJetsAI.java and I think I've discovered the cause - while the retreating AI correctly checks the direction the ship is facing before activating the drive system, it doesn't exit to prevent any other checks from potentially activating the system when facing the wrong direction. My proposed solution is to simply add a return statement after the AI has determined the ship is facing the wrong way:

Spoiler

Code: java

        if (assignment != null && assignment.getType() == CombatAssignmentType.RETREAT) {
            if (ship.getOwner() == 0 || (ship.getOwner() == 1 && engine.getFleetManager(FleetSide.PLAYER).getGoal() == FleetGoal.ESCAPE)) {
                targetLocation = new Vector2f(ship.getLocation().x, ship.getLocation().y + 500f);
            } else {
                targetLocation = new Vector2f(ship.getLocation().x, ship.getLocation().y - 500f);
            }
            if (rightDirection(ship, targetLocation)) {
                ship.useSystem();
                return;  // This line can be safely removed after adding the new line below
            }

            return;  // ADD THIS LINE - prevents the AI from activating the ship's system while retreating and facing the wrong direction
        } 

[close]

This should drastically increase the Sphinx's chance of surviving a tactical retreat...

36

Mods / Re: [0.9.1a] Starship Legends 1.1.8 - Personality for Your Ships and Crew

« on: May 28, 2019, 07:52:24 AM »

According to the patch notes, that missing method was added in Starsector 0.9.1a RC8:

-Added to CombatEngineAPI:
    -boolean isEnemyInFullRetreat();

In other words, it looks like the latest version of Starship Legends requires the most recent Starsector hotfix...

37

Modding / Re: Decided to make a personal-use mod from my settings tweaks, but it won't show up

« on: May 15, 2019, 09:15:59 PM »

The name of the version label should be "gameVersion" (lower-case g, upper-case V) rather than "GameVersion" (upper-case G, upper-case V). I think your mod should show up correctly in the launcher if you change that string. Also, you definitely shouldn't have those extra brackets in settings.json - they may screw up the parser.

38

General Discussion / Re: What sector age to you usually play with?

« on: March 25, 2019, 06:38:16 AM »

I switched to using Old Sector in 0.9 because it's supposed to increase the number of habitable planets. Based on my experience so far, this option does give me the best chance of having a few useful systems (relatively) close together to create my budding star empire.

39

Mods / Re: [0.9a] Nexerelin v0.9.1b "Double-Zero Agent" (update+fix 2019-03-03)

« on: March 06, 2019, 03:49:07 PM »

Euphytose, a common cause of wonky ship/weapon availability (both in the marketplace and in generated fleets) is the dreaded empty array in a mod's faction files. The Starsector wiki goes into some details about what actually happens (https://starsector.fandom.com/wiki/0.9a_Compatibility), but basically having an empty array - denoted by [] in the various *.faction files - can be really, really bad.

Unfortunately, about the only way to find the culprit is to go searching through the "\data\world\factions" subfolders of all your installed mods looking for the [] character combination. If you find any empty arrays, and they aren't on lines that are commented out with the # character, then they could be the source of this issue. It'll be a bit of work, but at least in this case you could limit yourself to just the tritachyon.faction files.

40

Mods / Re: [0.9a] Kadur Remnant v2.2.2 (updated Jan 23rd 2019) - More than a Faction Mod

« on: March 04, 2019, 04:42:54 PM »

For the record, the frequency may not be quite as bad as I originally thought - I just went through most of cycle 210 without any new expeditions until the Warhawks finally launched one in December. Previously, I must have just had multiple successful rolls on the lower end of that 30-60 day range so the factions managed to get several expeditions going simultaneously. (At least one of the expeditions was 100+ days long, so the RNG could have theoretically made three other success rolls while it was active.)

And, as if to highlight the flaws with my partial survey suggestion, the Warhawks targeted a REDACTED system where I didn't manage to fully survey all the planets because I, umm, "strategically retreated." Regardless, adding a "red planet" check and some distance weighting should address most of my concerns anyway. The only other problem I could foresee would be colonization of special planets/systems from other mods. The survey idea was also my attempt at creating a generic check that would prevent (or at least limit) expeditions to systems like those overrun/claimed by mod factions (like the Blade Breakers, the Sanguinary Anarchistic Defectors, or the IXth Battlegroups for example). Oh well, back to the drawing board on that one.

The sanity checks you've proposed sound great - that should take care of any other oddities I experienced with the expeditions. I can't explain the "population" check failing though - I colonized the planet several weeks before the expedition arrived in the hopes of completing the patrol HQ to get help defending the planet. Of course, it never produced any patrols in the brief time between its completion and their arrival, but it seemed like a good idea at the time...

41

Mods / Re: [0.9a] Kadur Remnant v2.2.2 (updated Jan 23rd 2019) - More than a Faction Mod

« on: March 02, 2019, 03:46:43 PM »

I've been playing around a bit with the colonial competitors and I think they're a pretty cool addition. They basically do for the outer systems what Nexerelin does for the core in terms of making the sector feel more dynamic and alive. Given that this feature is still in its relative infancy, I wanted to offer up a few questions/observations/suggestions:

How frequently are these events supposed to occur? I've literally had factions launch a second colonial expedition before their first one arrived at its destination. And I'm only a few months into cycle 210 and they've launched almost a dozen total (with an 8 of 11 success rate). It seems like this is a bit too often and should be limited to 2-3 per cycle (like how vanilla's expeditions are getting limited in 0.9.1a). At the very least, each specific faction should probably be limited to a single active expedition.

Should the fledgling factions be limited to surveyed planets for their targets? I wouldn't send a colony group to some random desert planet 50ly away without knowing what's there, and they probably shouldn't either. At the very least, they could be limited to planets with preliminary surveys (so that sneaky players don't go around leaving every <125% hazard planet they find only partially surveyed). I think this would make their expansion feel a bit more organic as they expand outward from the core into recently surveyed systems rather than randomly targeting systems at the far edge of the sector. Plus, this should reduce their chances of settling special worlds that they really shouldn't be able to colonize - like ones completely surrounded by REDACTED forces. For that matter, could they currently grab the red planet and break that quest?

Shouldn't there be more reasons for the expedition to fail aside from the player simply destroying their fleet? For example, in one instance I captured the staging market for the expedition before it spawned but it still gathered two weeks later anyway. For that matter, would saturation bombing the staging market stop them? I admit I haven't tried this, so I don't know if it would or not. As for other things I have actually tried, the planet already being colonized (and possessing a couple of completed buildings) by the time they arrive at their destination should definitely stop them. Instead, they just magically "colonized" right over the top of my existing colony resulting in a buggy state where the planet still appeared in my colony list but I couldn't edit the colony and the spaceport/patrol HQ I'd previously built were gone. Needless to say, I reloaded a previous save and "properly" prevented them from taking my planet.

Anyway, this is just some food for thought and I look forward to seeing how this feature evolves over time.

42

Bug Reports & Support (modded) / Re: Empty Cryovolcanic Worlds

« on: February 22, 2019, 06:56:10 AM »

This definitely sounds like a much more powerful approach than simply changing the condition_gen_data.csv header row as I originally proposed. It would give modders the ability to truly customize the conditions of some of their more unique planet types.

As for the problematic custom lava/cryovolcanic planets, I believe this approach can be greatly simplified since all you're trying to do is give them the exact same conditions as the original lava/cryovolcanic worlds. If I'm understanding correctly, you would still use the cat_lava/cat_cryovolcanic category types in planet_gen_data.csv as you did originally, and then do something like this in onApplicationLoad():

Code

    float value = 0f;
    for (Object o : Global.getSettings().getAllSpecs(ConditionGenDataSpec.class)) {  
          ConditionGenDataSpec spec = (ConditionGenDataSpec) o;  
          if (spec.hasMultiplier("cryovolcanic"))
          {  
             value = spec.getMultiplier("cyrovolcanic");
             spec.getMultipliers().put("fds_cryovolcanic", value);  
          }  
          if (spec.hasMultiplier("lava"))
          {  
             value = spec.getMultiplier("lava");
             spec.getMultipliers().put("fds_lava", value);  
          }  
       }  

Theoretically, this should give your custom planets the exact same chance of getting a specific condition that their vanilla equivalent has.

Disclaimer - I am "coding" this in the forum post editor (which makes for a remarkably bad IDE), so it may require some tweaking before it will compile...  

43

Bug Reports & Support (modded) / Re: Empty Cryovolcanic Worlds

« on: February 21, 2019, 08:36:04 AM »

I don't know if Alex would necessarily classify it as a game bug because vanilla works as designed. I was planning on putting something in the Suggestions forum about adding columns for all of the base planet categories to condition_gen_data.csv, but I haven't had the chance yet. It might even be possible to just simply replace the specific planet types (lava, cryovolcanic, terran, etc.) with their corresponding category types wherever there's only a single planet with that category (terran is the only cat_hab4, for example) and then both vanilla and custom mod planets would theoretically work. Something like this, for example:

Code

id,group,rank,order,hazard,reqSurvey,xpMult,requiresAll,requiresAny,requiresNotAny,cat_giant,cat_barren,rocky_unstable,rocky_ice,cat_hab1,cat_lava,lava_minor,cat_frozen,cat_cryovolcanic,cat_irradiated,cat_toxic,toxic_cold,cat_hab4,cat_hab3,terran-eccentric,jungle,water,arid,tundra,cat_hab2,multipliers >>>,tectonic_activity,extreme_tectonic_activity,low_gravity,high_gravity,hot,very_hot,cold,very_cold,dense_atmosphere,water_surface,mild_climate,extreme_weather,poor_light,inimical_biosphere,pollution

Meanwhile, as a workaround in FDS, I was going to recommend doing something like what was done in Unknown Skies (i.e. use "cat_toxic" for "fds_lava" planets and "cat_frozen" for "fds_cryovolcanic" planets). It wouldn't give you completely accurate conditions, but it should ensure that the planets aren't empty. However, adjusting the planets so they have zero chance to spawn during sector generation works too.

44

Bug Reports & Support (modded) / Re: Empty Cryovolcanic Worlds

« on: February 20, 2019, 09:21:28 PM »

Yep, I'd say that's almost certainly the culprit. From what I can tell, the code performs two look-ups when putting together its list of potential conditions for a particular planet.  First, it searches for a column matching the planet type (so "fds_cryovolcanic" in this case). If that fails, then it attempts to find a column matching the planet category (i.e. "cat_cryovolcanic"). Since neither of those are one of the column header names in vanilla's condition_gen_data.csv, it doesn't add anything to its list and generates the empty world as a result.

This also explains why, as Alex said earlier, the vanilla cryovolcanic worlds work fine. Their planet type is simply "cryovolcanic" so they pass the first check and correctly use the "cryovolcanic" column to generate their conditions without even checking for their "cat_cryovolcanic" planet category. It's really too bad that the column isn't named "cat_cryovolcanic" because it looks like that would have worked in both cases.

45

Bug Reports & Support (modded) / Re: Empty Cryovolcanic Worlds

« on: February 20, 2019, 02:40:04 PM »

I don't know if this is related to the problem, but it's one of those things that I look at and go "hmm, this looks odd...":

Code

id,group,rank,order,hazard,reqSurvey,xpMult,requiresAll,requiresAny,requiresNotAny,cat_giant,cat_barren,rocky_unstable,rocky_ice,barren-desert,lava,lava_minor,cat_frozen,cryovolcanic,irradiated,cat_toxic,toxic_cold,terran,cat_hab3,terran-eccentric,jungle,water,arid,tundra,cat_hab2,multipliers >>>,tectonic_activity,extreme_tectonic_activity,low_gravity,high_gravity,hot,very_hot,cold,very_cold,dense_atmosphere,water_surface,mild_climate,extreme_weather,poor_light,inimical_biosphere,pollution

This is the header row for Starsector's condition_gen_data.csv file. What looks odd to me is that there are several cat_XXX planet category entries (cat_giant, cat_barren, cat_frozen, etc.) but the "cryovolcanic" one is missing the "cat_" prefix. Now, this list also contains specific planet ids (jungle, water, etc.) for planet types that share the same category (like cat_hab3 for jungle, water, etc.), but in cryovolcanic's case there is only one cat_cryovolcanic entry in planet_gen_data.csv. Should that column header be "cat_cryovolcanic" instead? For that matter, should "lava" be "cat_lava"? I can't help but wonder if that would have avoided the original problem with the custom lava/volcanic planet types...