Why do...
WeaponSlotAPI.setArc(float arc);
WeaponSlotAPI.setAngle(float angle);
...apply to the visuals, but don't update the behavior?
Hmm - at a guess, this might be because by the time you're calling these, the ship is already created and deployed.
Hello all, I am looking for some guidance to solve an issue that has come up with Hiver Swarm. They show up as a target for missions given in the bar such as having one of their planets a trade target destination. Today I received a message from a player who said they were doing the red planet missions that the 2nd guy you have to talk to after the old spacer was on a Hiver world. Since they are hostile to all factions it would make those missions not completable.
Histidine was kind enough to point me in the direction of a command I did find on the SS API website, market.setInvalidMissionTarget(true) so if I understand it correctly then that *should* effect vanilla missions but there are so many files that effect a faction's market I am unsure where that would go in the Hiver faction market creation process. Any help would be appreciated, thank you.
Red Planet is not actually checking for isInvalidMissionTarget(), though it should be - fixed this up. It *is* checking for market.isHidden(), though, so you might try that.
You'd want to do this in code somewhere - possibly in your ModPlugin.onNewGameAfterEconomyLoad()
Is it safe to save instances of BaseIntelPlugin in persistent data? What about a planet's custom data? I thought it would be safe to do so since BaseIntelPlugin does not reference any other UI elements, but I'm told it can still cause issues. Thanks for any help!
If I'm understanding the question correctly, for BaseIntelPlugin it should be fine - the vanilla game does this all the time. "A planet's custom data" I'm not 100% sure what you mean - could you clarify?
Edit for more context:
I have good reason to believe that my newest mod has caused save corruption for a user. They're sometimes getting this error when saving:
I can't think of anything that would cause something like that other than an endless recursion loop caused by trying to save a looping reference.
Looping references should be fine - this is, again, something that happens all the time and is handled by xstream. It's very weird that it's writing bytebuffers into the savefile, though. It might help to see more of it, if you have it - could you email it to me?
At a guess, rather than being a recursion loop issue, it may just be an issue with the data structure itself going very deep for some reason - not infinite, but deep enough to cause a stack overflow. So the question is what is this actually rooted in and what's getting into the savefile that shouldn't be. Though, if my guess is right, the issue isn't just that it's getting into the savefile, but also with it growing to the extent that it's a problem, too.
Edit: to be clear, it would be really helpful (well,
probably) to see where this stuff *starts* in the save. Or better, the whole save.
Edit #2: seeing a "next" element in there makes me think it's some kind of linked list or perhaps linked hashmap that gets added to in an unbounded fashion. That would explain the stack overflow exception, too - when a long linked list is serialized by xstream, chances are it would happen depth-first.