Print

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

[xenoargh]

...nope.

Hit another one, and this time, there's no Codex crash to clue me in.  Happens right after I load in from my save, too; guess this test-game's over.  I'll see if I can find another way to detect the issue.

[xenoargh]

And another one, seemingly at random. 

Is there any way to search all the .variants and check them for more than 5 Groups at runtime?

[Alex]

Hmm - SettingsAPI: List<String> getAllVariantIds(); and go from there? But this doesn't look like a "more than 5 weapon groups" issue, I don't think, at least based on that stack trace. This is more likely to be an invalid slot ID in a variant.

[xenoargh]

Got it:

Code

		List<String> theVariants = Global.getSettings().getAllVariantIds();
		for(String variantID : theVariants){
			ShipVariantAPI thisVariant = Global.getSettings().getVariant(variantID);
			List<WeaponGroupSpec> groupSpec = thisVariant.getWeaponGroups();
			if(groupSpec.size() > 4){
				Global.getLogger(SS_Al_ModPlugin.class).log(Level.ERROR,"ERROR: Variant: " + variantID + " has more than allowed weapon groups.");
			} else {
				Global.getLogger(SS_Al_ModPlugin.class).log(Level.ERROR,"The Variant: " + variantID + " is fine.");
			}
		}	

[xenoargh]

I found at least one Variant with > 5 Groups already. 

Methinks append struck again, but we'll see.  Need to go see what the "bad" ones look like.

[xenoargh]

Hmmmm....

Here's my dominator_Assault.  4 Weapon Groups.

Spoiler

Code

{
  "displayName": "Assault",
  "fluxCapacitors": 5,
  "fluxVents": 29,
  "goalVariant": true,
  "hullId": "dominator",
  "hullMods": [
    "heavyarmor",
    "solar_shielding",
    "stabilizedshieldemitter",
    "targetingunit",
    "autorepair"
  ],
  "permaMods": [],
  
  "variantId": "dominator_Assault",
  "weaponGroups": [
    {
      "autofire": false,
      "mode": "LINKED",
      "weapons": {
        "WS 012": "mark9",
        "WS 013": "hephag"
      }
    },
    {
      "autofire": false,
      "mode": "ALTERNATING",
      "weapons": {
        "WS 014": "typhoon",
        "WS 015": "typhoon",
        "WS 016": "typhoon"
      }
    },
    {
      "autofire": true,
      "mode": "LINKED",
      "weapons": {
        "WS 010": "flak",
        "WS 011": "flak"
      }
    },
    {
      "autofire": true,
      "mode": "LINKED",
      "weapons": {
        "WS 001": "vulcan",
        "WS 002": "vulcan",
        "WS 003": "vulcan",
        "WS 004": "vulcan",
        "WS 005": "vulcan",
        "WS 006": "vulcan",
        "WS 007": "vulcan",
        "WS 008": "vulcan",
        "WS 009": "vulcan"
      }
    }
  ],
  
}

[close]

Soooooo, yeah, if it's appending rather than replacing that section of the JSON, boom.

[xenoargh]

The "good" news is that, since these are variants to support the AI... it's OK to just stick everything in one Group (well, at least with my AI).  The bad news is that end-users will find it confusing as all get out, if they capture one.

The alternative is to use replace, but I don't think that allows for wildcards or path-level wildcards, and it's a few hundred unique strings.  Ouch.

Hmm.  I don't suppose the Variants can get edited at run-time to delete the junk?  This is mighty inconvenient, to say the least.

[Morrokain]

The alternative is to use replace, but I don't think that allows for wildcards or path-level wildcards, and it's a few hundred unique strings.  Ouch.

You mean the replace array in mod_info?

I've done some of that work for you already, if you need to try that. I'll update it with the full replace array I have now (I think I added more things).

Removing everything you don't need is way easier than adding them all.

https://fractalsoftworks.com/forum/index.php?topic=14684.msg239156#msg239156

(Keep in mind I have this formatted to only work on windows operating systems until the next official release, so if you aren't using that you may have to change the path deliminator in some cases)

[xenoargh]

Oh, now that's freakishly useful-looking for doing serious hackery, lol.  Thank you!

The problem arising though is:  without explicit control over mod loading orders, this might not be a plays-well-with-others approach.

The current idea here is that JSON will now allow append operations and proper inheritance.  

That's actually really good, in a variety of cases, like when you just want to add <some little thing> to <some bit of core game data>.

The bad side of this is when the expected behavior is that we're replacing X with Y, rather than appending and arriving at XY.  

This stuff with variants is just another case of the same issue with the appending concept; while append is super-great for some things, in this case, it's crash-city just by including a few .variant files.  Dunno what JSON handler Alex is using; this seems like something where maybe we could use <some special characters> to tell the game to Append This To Inherited Data or Replace This JSONObject / JSONArray With My Version.

[Morrokain]

Hmm - SettingsAPI: List<String> getAllVariantIds(); and go from there? But this doesn't look like a "more than 5 weapon groups" issue, I don't think, at least based on that stack trace. This is more likely to be an invalid slot ID in a variant.

That is likely the end cause. The root cause could be related to file merging issues, though, if the mod tries and edits both the ship and the variant file simultaneously and there is a merge conflict. I ran into null pointer errors with variants too before I had sorted out the replace array.

I am definitely not certain, but it seems to happen especially if weapon slots between the base game ship and a mod ship share roughly the same location in the ship file. Or at the time I thought it could be that sharing the same weaponslot id doesn't override with the mod loaded ship's definition of that id, and the game can't decide which one to use when it uses a variant to populate that slot with a weapon.

The other slot is sill there in the editor, though, so I guess it is technically merged. It just can't equip a weapon at the same time as the other slot occupying the same space. It will override whatever was in the other slot if you select a weapon for the unused slot. The only time I got to see that behavior, though, was if it didn't crash upon viewing the variant in the first place.

[Morrokain]

Oh, now that's freakishly useful-looking for doing serious hackery, lol.  Thank you!

The problem arising though is:  without explicit control over mod loading orders, this might not be a plays-well-with-others approach.

The current idea here is that JSON will now allow append operations and proper inheritance.  

That's actually really good, in a variety of cases, like when you just want to add <some little thing> to <some bit of core game data>.

The bad side of this is when the expected behavior is that we're replacing X with Y, rather than appending and arriving at XY.  

This stuff with variants is just another case of the same issue with the appending concept; while append is super-great for some things, in this case, it's crash-city just by including a few .variant files.  Dunno what JSON handler Alex is using; this seems like something where maybe we could use <some special characters> to tell the game to Append This To Inherited Data or Replace This JSONObject / JSONArray With My Version.

Yeah it definitely wouldn't be friendly to other mods trying to do small edits, true. Luckily for me that isn't my use case so I don't have to be careful about what I replace.

On special characters, as long as I don't have to edit every one of my files to include them, and can just replace away, then great! lol Otherwise that would be a real pain for me, but meh I'd get over it.

[Alex]

I am definitely not certain, but it seems to happen especially if weapon slots between the base game ship and a mod ship share roughly the same location in the ship file. Or at the time I thought it could be that sharing the same weaponslot id doesn't override with the mod loaded ship's definition of that id, and the game can't decide which one to use when it uses a variant to populate that slot with a weapon.

The other slot is sill there in the editor, though, so I guess it is technically merged. It just can't equip a weapon at the same time as the other slot occupying the same space. It will override whatever was in the other slot if you select a weapon for the unused slot. The only time I got to see that behavior, though, was if it didn't crash upon viewing the variant in the first place.

Yeah, if you have multiple slots with the same ID - which you would, since slots in a .ship file are an json array, and therefore json merging will append one to the other - then things will get weird.

The way merging works, basically, is going top-down through the json and seeing: is this a jsonarray? if so, append. Is this a json object? If so, replace based on its keys. That misses a bunch of details but is roughly how it works.

It does mean that the .ship file format is not very suited to modifying without outright replacing; if I had to do it over I'd probably have weaponSlots be a json object keyed on slot ids instead of being an array as it is now.

[xenoargh]

...and another one, after using replace to literally replace every single Variant in Vanilla.  99.9% of them aren't even modified, other than the ones that needed explicit fixes because of weapon references being borked.

I've just checked the log, to see if my little code snippet caught any >5 Group things.  Nope.

I'll go through all the Variants to look for the issues, but frankly, I think that there's something borked going on here, when the Factions are building new ships for campaign fleets.  Given what's the root cause here, I'm a little mystified why this just happens with modded Vanilla data, rather than all over the place.

Also, there are Variants that aren't in the /variants directory- stuff like Sunder2, etc.; what are those?

[xenoargh]

Aha, found the crash.  When I converted the Shrike, it had a slight difference in Weapon Slot naming conventions.  The only way to find  the error in a way that I could see what happened was to click on all the Codex entries until the game crashed, lol.  I'll write some more code to attempt to find things like this before I run into them playtesting...