Print

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

[Histidine]

Solution here

My setup:

Spoiler

I dual boot Windows 7 Home Premium 32-bit and Ubuntu 14.04 LTS (Trusty Tahr) 64-bit.

On Windows, I have a normal Starsector install on an NTFS partition (at D:\Program Files\Fractal Softworks\Starsector)
On Linux, I have an install at home/histidine/Programs/Starsector-linux. I symlink the mods and saves folder to the ones in the Windows install.
Both installations are using their own local copy of the Java 7 JRE (32-bit on Win, 64-bit on Linux).

[close]

My problem:
I've made some code changes to the Nexerelin mod and recompiled the .jar. These changes are reflected when I play on Windows, but not on Linux.
This occurs even after having NetBeans clean and rebuild the .jar in either Windows or Linux (and the .jar is indeed replaced). Unmounting and re-mounting the NTFS partition in Linux didn't help; neither did recreating the symlink. Changing the Linux install's starsector.sh to use the system Java instead of local copy didn't help either.

Java Cache Viewer shows no entries, and telling it to clear it anyway does nothing.

If I delete the .jar outright and try to play the game, it does crash.

Any ideas?

[Alex]

Upgrade to Windows 10 and see if it helps?

<ducks> (My plan here is you'll be so busy dealing with the fallout from that you'll forget all about the original issue.)

Seriously, though, hmm. This sounds like it could be a filesystem caching issue. Have you tried doing "touch <jar filename>" from Linux? And from Windows? I mean, you'd think re-mounting the partition and recreating the symlink might also do the trick, but since they haven't...

Another (remote) possibility is ending up with duplicate entries in the jarfile somehow, and windows uses the new set while linux uses the old, for some reason. I've seen it happen once (at least, the duplicate entry issue, not the "different OSes using different entries", which is a whole other level of weird), but no idea what might cause it. Looking at the jarfile manually (i.e. with winzip, jar -tvf, or some other such) might be worth a shot.

Also, finally - and perhaps this might be the first thing to try, if you haven't already - a hard reboot?

[Histidine]

> Try various things, none work
> Get fed up and dispense with the symlink, just physically copy Nexerelin and LazyLib to the Linux install folder
>> Now it works
> Restore the symlink and start the game up again with only Nexerelin and LazyLib selected from mod list
>> Still works
> Turn on all the mods I had earlier
>> Still works
> Be thoroughly confused

EDIT: Okay, it doesn't actually work, I just got it to reflect some (but not all?!) of the changes to the code.

EDIT2: Okay, this is beyond screwed in the head. Physically copied all the mods to the Linux folder, started the game again, now it's using the old code again. I don't even.

Other things I tried that did nothing:

• Rename .jar (and change mod_info reference accordingly
• Rename mod folder
• Change mod version
• Touch .jar in Linux
• Manually clear Java cache folder (there was some stuff in a folder named 6.0)
• Disable Java temporary files
• Several restarts

Cursory inspection of the .jar contents with Archive Manager indicated no duplicate files.

Oddly, other people's mods did get their changes reflected when I updated them.

[Alex]

Hmm. Have you tried a clean reinstall of the game?

Some possibilities: the classpath in the .sh file pointing somewhere unexpected, .java files in the scripts folder being used before the jar (though iirc they shouldn't be - but if they got compiled into .class files somehow and live there, they *might* take precedence).


Finally, are you 100% certain you can tell whether something is using the new/old code? I've had cases myself where I thought something was using old code where instead it was some unexpected conditional causing the new code to behave like the old...

Another suggestion: running jvisualvm to take a look at the classpath, just to be certain. Might be able to see where particular classes are loaded from, too, though I'm not sure if you can/how to do that using that tool.

[Histidine]

Another suggestion: running jvisualvm to take a look at the classpath, just to be certain. Might be able to see where particular classes are loaded from, too, though I'm not sure if you can/how to do that using that tool.

Thanks; I didn't figure out how to do it in jvisualvm, but this was the clue I needed. At some point Google's autocomplete helpfully pointed me to this code, which led me to this:

Spoiler

[close]

(I think I accidentally let NetBeans put the library files there while compiling THI modifications)

Trashed those extra libraries and everything works fine now. Though I don't understand why SS loaded the .jar from there instead of the one actually referenced in any modinfo json...

[Alex]

Fun stuff.

Hmm. If you're running the game from the IDE, and the IDE considered this a library location, then that might happen, I think? Seems like it'd be tough to set up by accident, but as you'd set Netbeans to put the library at that location at some point, that seems like a possibility.

[Histidine]

(I only ever ran the game from the shell script, not the IDE)