Print

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

[Adraius]

Hi, I've noticed that when spawning allied ships to do a multi-ship simulation, if allies are added after any opponents have been added, they spawn without their weapons - or very occasionally, with the wrong weapons. (I've only seen that on one ship so far, but it consistently spawns with the same incorrect loadout) Adding the allies first causes them to spawn normally, and this doesn't seem to effect opponents.

I'm playing with the Simulator Overhaul mod (and SS+, as I understand there's some interactions between the two).

[CrashToDesktop]

Since you're using mods, this isn't exactly the best place to post about it.  Try the mod threads instead of the official game bugs section.

[Alex]

Hmm. Is this something you can reproduce in vanilla, by taking more or less the same steps you do in the modded game?

[Adraius]

Simulator Overhaul is pretty simple, and SS+ makes it even simpler, so I suspect this is a core game bug.  When I get home, though, I'll disable all my mods and see if it reoccurs. (I don't have the game with me at the moment and I wanted to get this out there before I forget to bring it up)

[LazyWizard]

If it happens in the first wave of allied ships you send out, it's probably a vanilla bug. Sim Overhaul doesn't touch the player ships until the reserve numbers change.

Edit: I just tested Sim Overhaul with standard and player-made variants and wasn't able to replicate this bug. What's the loadout you were using? Are the ships causing problems some of SS+'s dynamically generated variants?

[LazyWizard]

Okay, tracked it down. It is indeed a bug with the second wave of allies in Simulator Overhaul, caused by some strange behavior with Starsector's variants.

If you create a variant, the getSpecId()/getVariant().getgetHullVariantId() methods in FleetMemberAPI still return whatever variant you originally modified it from; in other words, take a tarsus_Standard, swap everything out for needlers and rename it to "BADIDEA", getSpecId() still returns "tarsus_Standard". If you created a variant from an empty hull I presume it returns "tarsus_Hull". You have to save and reload the variant for it to be "exported####tarsus<whatever>". Not sure if this is actually a bug or just how SS handles unsaved variants.

[Adraius]

Okay, it took me five reads, but I think I understand that. =P I don't get how that causes the bug, though - all the ships I was loading are saved variants.

[LazyWizard]

It wouldn't be fixed by them being saved, but by them being loaded from your list of saved variants. That seems to be what triggers the change to the new internal variant ID so the mod knows to spawn the proper variant.

Moved to Modding, though I'm not sure if the underlying issue with IDs not changing w/o manually loading the variant is a vanilla bug or not.

[Alex]

If I'm understanding this right, I *think* this is an issue with how the API is being used.

ShipVariantAPI has a clone() method if you want to make a copy to modify from, which is what needs to be done to have it work right and not affect existing ships with that variant. You would then .setHullVariantId() to something unique (UUID.randomUUID().toString()?) on that copy.

Or am I missing something?

[LazyWizard]

Basically, one of the changes in the simulator overhaul mod makes it so the instant you send in a ship in the simulator (whether enemy or allied), an identical ship is added to the reserves so the simlist can't be exhausted. The problem is it kept track of/spawned ships using their variant ID, which doesn't seem to change for customized ships unless they were loaded from an exported variant (it returns the base variant ID instead). This didn't matter for enemy ships as the sim list only includes stock variants, but for the player side it'd spawn old/empty variants instead of the ship you selected if you had customized your loadout.

However, it shouldn't matter anymore. I just rewrote how the mod handles regenerating reserves to bypass the issue.

[Alex]

Ah, gotcha. To be perfectly honest, I'm not thinking straight enough right now to figure out what the issue was, and that part of the code was always a bit tricky. So if you say it's not an issue anymore I'm happy to let it go