Fractal Softworks Forum

Please login or register.

Login with username, password and session length
Advanced search  

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.

Messages - Wispborne

Pages: [1] 2 3 ... 8
Mods / Re: [0.9.1a] Gates Awakened (updated 2021-01-12)
« on: January 12, 2021, 08:53:33 AM »

- Save-compatible back to 2.0.0
- Fixes crash when using gates with no orbit, such as one in Interstellar Imperium (thanks to @Freetimez on Discord for the report)

General Discussion / Re: Xss?
« on: December 13, 2020, 11:21:58 AM »
Xss is stack size, and in 99.9% of cases you should never change it.

It has nothing to do with vram allocation, that is totally automatic determined by the video card driver and hardware present.

Thank you.
I did search it up in the forums and found a few people with different values than the number I have.
Any idea why that is ?

They've changed it manually most likely, or perhaps older versions of Starsector used a different number.

The reason you'd want to change it is when your game crashed with a StackOverflowException and you don't think it was caused by a buggy mod. If the savegame has things nested sufficiently deeply, it can cause a stack overflow when reading/writing.

I wrote up a description of xss a few months ago:

You know Inception, where they go into a dream from a dream from a dream?
That concept is common in programming; you call/invoke functions from other functions, which puts the calling function on pause until the "inner" one finishes
Stack size is how many layers deep you can go
In Inception, they went what, 3 layers deep?
Xss is the max limit, and if it goes over that limit, you get a StackOverflowException
and that's why increasing the limit fixed it
The limit exists because most of the time, when a program goes over the limit, it's because there's a mistake in the code, eg function A invokes function B, which invokes function A, which invokes function B, which invokes function A, which invokes function B.....etc. It's an infinite loop.
And since you don't want that runaway code to eat tons of resources, a "reasonable limit" is put on it; the stack size (xss).

Modding / Re: VRAM Usage Estimator 1.6.0
« on: November 22, 2020, 06:26:26 PM »
- Prompt for GraphicsLib settings on each run.

I suspect that many users did not realize that the default was to assume GraphicsLib was fully enabled, which meant that this tool over greatly overestimate VRAM usage if GraphicsLib was disabled.
If GraphicsLib is not enabled at the mod level, the user is not prompted.

Announcements / Re: Starsector is now on the Nexus
« on: November 15, 2020, 02:10:26 PM »
I don't see any change. There's a good subset of the forums mods on there at

Modding / Re: Modding-wise, what is most exciting about 0.9.5a?
« on: November 02, 2020, 09:40:46 AM »
For me, the tools to make quest content.

- Story points act as both quest rewards and something you can use during a quest ("Force the guard to see things your way (1SP)")
- The new API methods for writing quests should make them easier to write, read, and maintain, while also lowering the (currently very high) barrier to entry.

Mods / Re: [0.9.1a] Gates Awakened (updated 2020-11-01)
« on: November 01, 2020, 07:53:05 PM »
2.1.0 (2020-11-1)

Save-compatible back to 2.0.0 (as in, you may update from 2.0.0 and later)

- Added sound and visual effects to gate use. Sounds created by MesoTroniK.
- Inactive, discovered gates are now displayed as intel.
    - This may be toggled off by selecting the intel.
- The third quest will now always trigger if prereqs are met (previously 33% chance).
- The GatesAwakenedViewInfo console command will now show what is missing for the second and third quests to trigger.

Mods / Re: [0.9.1a] Stellar Logistics - courier services
« on: October 30, 2020, 02:28:26 PM »
Done & done, "allowTransfer" boolean in "data/config/settings.json" will hide all transfer buttons.

Super cool, thanks!

Mods / Re: [0.9.1a] Stellar Logistics - courier services
« on: October 29, 2020, 08:50:12 AM »
I just discovered this and love the look of it.

Would you consider adding a config option to make this a "readonly" mod, essentially disabling the courier part of the mod but leaving the storage display and filtering?

Having a version (or config) that serves only as a way to view what stuff you have and where would be a pure QoL mod without affecting the balance of exploration, serving a different niche with, I think, fairly minor coding effort (basically just need to hide some buttons?).

Great mod, between this and Hyperspace Network, I'm really looking forward to diving back into my game.

9 is spamming the log file at line 78, the weapon checks. Recommend commenting out info logging before releasing.

I've attached an user's log (not mine) as an example.

Code: java
"Check weapon name: " + stats.getVariant().getWeaponSpec(slot).getWeaponName());
        spec = stats.getVariant().getWeaponSpec(slot);
        checkForManufacturers = false;
        for(String manufacturer: YRXPModPlugin.APPROVED_MANUFACTURERS) {"Check manifacturers for " + spec.getWeaponName() + "::" + spec.getManufacturer() +" vs " + manufacturer);
if(spec.getManufacturer().compareToIgnoreCase(manufacturer) == 0) {
//"Setting ammo from " + Math.round(weapon.getAmmo()) + " to " + Math.round(weapon.getAmmo() * YRXPModPlugin.YRXP_MISSILE_AMMO_MULT));"found approved manufacturer");
// weapon.setMaxAmmo(Math.round(weapon.getAmmo() * YRXPModPlugin.YRXP_MISSILE_AMMO_MULT));
checkForManufacturers = true;
    if(!checkForManufacturers) {
    hasFoundUnstandardWeapon = true;"Found substandard weapon: " + spec.getWeaponName() + "::" + spec.getManufacturer());

Modding / Re: Additional mod_info flags / mod version stuff
« on: October 27, 2020, 11:13:19 AM »
Well - primarily the system is there for managing mod dependencies and it's based on what version checker was already using...

Edit: what I'm trying to say is that it's not really *required* to version it to provide the most accurate save compatibility message.  Whether it's a "might not load" or "likely to not load" message, there's still room for either outcome.

Semantic versioning is a way to conflate versioning and compatibility, but makes major version ticks unexciting if it's just a breaking bugfix.
The 0.9.5a system conflates versioning and a vague compatibility, like "lots of stuff changed, maybe your save will work, maybe not", even if the author knows for certain that it won't break saves.

I think that's why Tartiflette is talking about a separate number for it, to give mod authors the option to be express about what is save-breaking.

If I'm a user and I see an update, I'm probably not going to update if I see "this may or may not break your save game", even if it's a very low chance.

Similar to Tartiflette's example, major new content in my mod has been save-compatible. My preference is to make breaking changes without any new features.

Modding / Re: Additional mod_info flags / mod version stuff
« on: October 26, 2020, 05:36:46 PM »
Yeah - this is largely due to having version dependency checking for mods in the launcher, which, kind of need to choose a specific scheme (any scheme, really, point being that one has to be chosen) for that to work. And if that same scheme works for estimating save compatibility, too...

Thanks, sounds like a great change! Easy to implement*, consistent, and user-friendly.

* including ignoring it by always bumping the major version

edit: I guess I am still a little disappointed the only way to indicate to an user than a mod update is compatible will be to go from to (assuming they aren't reading patch notes/forum page). Ah well.

Modding / Re: Additional mod_info flags / mod version stuff
« on: October 26, 2020, 05:18:07 PM »
Ah - the way it works in 0.95a is the tooltip will show whether it's a minor or major mismatch, based on what part of the version changed, so e.g. -> = minor warning ("it might not work"), while ->  = major warning ("it probably won't work, expect it not to load").

Interesting. So, are you taking an opinionated approach to versioning - or can the mod itself decide what to show in the tooltip?

I ask because a minority of us use Semantic Versioning, where only the major (first) number change reflects incompatibility. The second number is a feature update bump, and the third is for bugfixes. So, in that case, going from 1.1.1 -> 1.2.2 should always be compatible.

If you're saying, "this is the way that mods should version from now on", then that's totally cool. Honestly I'd be happy to see more consistent versioning, even if it's not what I personally favor (edit: which is arguably not a great fit for mods anyway).

Modding / Re: Additional mod_info flags / mod version stuff
« on: October 26, 2020, 04:07:28 PM »
ha, Morrokain beat me to explaining it.

What are the odds of having a `beforeGameLoad` hook added to `ModPlugin`?

The use case I'm thinking of is detecting save-breaking mod updates and showing an user-friendly message before the save file is deserialized and blows up.

The game already shows a "mod compatibility warning" when you try to load the game (I'm not 100% sure if this is in 0.9.1a, actually), and will also show the saved with/current versions for all the mods involved in the save game's tooltip, so I think this should be covered?

It is in 0.9.1a, yeah.

The difference between what's there now and my suggestion is that the present way show any version difference, regardless of whether or not it's save-compatible.
Users often have no idea what is a save-breaking update or not, due to not reading warnings on the mod page, and install multiple save-compatible updates before ending up an incompatible one that require help to diagnose.

That's an ok state of affairs, modding being fairly at-your-own-risk, but having an express way to show a helpful message when we know for sure that the user is about to get a tricky crash, or worse, would be useful.

Modding / Additional mod_info flags / mod version stuff
« on: October 26, 2020, 12:53:01 PM »
What are the odds of having a `beforeGameLoad` hook added to `ModPlugin`?

The use case I'm thinking of is detecting save-breaking mod updates and showing an user-friendly message before the save file is deserialized and blows up.

Potential method signature:

Code: java
/* SaveDescriptor could be a representation of descriptor.xml (btw, syntax highlighter doesn't like double-slash comments, it comments out the rest of the code block */
abstract void beforeGameLoad(SaveDescriptor saveDescriptor);
/* or, more simply */
abstract void beforeGameLoad(String lastSavedModVersion);

The code I'm imagining using it for would look something like:

Code: java
void beforeGameLoad(String lastSavedModVersion) {
  /* is left as an exercise to the reader */
  Version oldVer = Version.parse(lastSavedModVersion);
  Version currentVer = Version.parse(Global.getSettings().getModManager().getModSpec("myMod").getVersion());

  if(oldVer.getMajor() < currentVer.getMajor()) {
    throw new RuntimeException("Updating from version " + oldVer.toString() + " of MyMod to version " + currentVer.toString() + " requires a new game. Please downgrade MyMod to " + oldVer.toString() + "  or start a new game to continue.");

Announcements / Re: Starsector is now on the Nexus
« on: October 13, 2020, 10:10:03 AM »

I have done some work on the Vortex extension for Starsector that allows it to read from mod_info.json.
Mods that are installed manually (not from NexusMods) will now display their version and author in Vortex, with this extension update.

Only newly installed mods will have the additional info displayed.

It is available from within the Extensions section of Vortex, named "Starsector Support" version 1.1.
Or you can see it here, but it still needs to be installed via Vortex:

Includes support for mod version and author(s) for mods installed from file, rather than from NexusMods.

This extension will read mod_info.json, stripping out comments that use the '#' sign, and extract the mod version and mod author(s) from the file, allowing Vortex to display this useful information, which is normally limited only to mods that are downloaded from NexusMods.

The displayed mod name will be unchanged (if downloaded from NexusMods) or the name of the mod's archive (if installed manually).
This is due to some mod authors releasing multiple iterations of a mod with
the same version, with the only difference being in the filename.
For example, "" and "" often both have a version of 3.0.0. Since the beta number is important information, it should not be replaced by the name in the mod_info.json file, which may simply be "Mod Name".

When submitting this to NexusMods, they mentioned that they are iteratively removing baked-in, official Vortex support of less-popular games in favor of user-managed extensions.
What this means is that, most likely, Starsector will not be supported out of the box by Vortex (nothing changes on the NexusMods site), but support can be easily added by using the in-app extension browser to find and enable a (the) Starsector extension.

The purpose is for them to spend less dev time verifying support for less-popular games, which also means less turnaround time between updating an extension and the changes going live.

tldr; The Starsector support in Vortex is going to switch to an user mod for Vortex, rather than having the NexusMods team seal of quality.

Pages: [1] 2 3 ... 8