Subset Games Forum

Posted: **Fri Nov 29, 2013 4:59 am**

To fellow developers:

Writing to VirtualStore can be disabled by including a manifest in exes that sets "requestedExecutionLevel". Apparently just having a manifest that mentions the "trustinfo" section is enough to tell the OS that it's not a legacy app which needs that sort of 'help'. When a user's privileges are insufficient, they'll get a "denied" error instead.

Reading might still be fooled even then, if a phantom copy already exists. Not sure.

Article: Making Your Application UAC Aware
Article: StackOverflow - How to disable VirtualStore

launch4j can do this with the <manifest>myapp.manifest</manifest> tag (or "Wrapper Manifest" in the GUI).
Dunno if LF line-endings in a manifest are acceptable, but I use CRLF to be safe.

Posted: **Mon Dec 02, 2013 3:19 am**

I am using the Mac/Linux version of SMM on Linux and the button for "Re-Scan /mods" Is grayed out and I can't click it. Help?

Posted: **Mon Dec 02, 2013 10:24 am**

GotNinja101 wrote:"Re-Scan /mods" is grayed out and I can't click it.

It's normally disabled while a scan is in progress, either the one on startup or when Re-Scan was clicked once already. After the scan, a signal is sent to re-enable it.

Sounds like the startup-scan is taking an unexpectedly long time (stalled?), or it did finish but there was a problem signalling completion...

Paste the contents of "modman-log.txt" in a reply, between [ code ] tags, so I can tell which it might be.

Posted: **Tue Dec 03, 2013 12:54 am**

Vhati wrote:Paste the contents of "modman-log.txt" in a reply, between [ code ] tags, so I can tell which it might be.

I'm assuming that modman-log.txt is supposed to be in the folder where the .jar is? I can't find it in there

Posted: **Tue Dec 03, 2013 2:05 pm**

GotNinja101 wrote:"Re-Scan /mods" is grayed out and I can't click it.

So the main window does show up...
By that point "modman-log.txt" and "modman.cfg" should be created in SMM's folder.

GotNinja101 wrote:I'm assuming that modman-log.txt is supposed to be in the folder where the .jar is? I can't find it in there

If Slipstream thinks it's in some other folder (home?) and can't find mods/, that'd explain why it isn't scanning properly.

The thing is: double-clicking "modman.command" should be making sure that doesn't happen (it cd's to the script's location, then runs the jar).

You aren't double-clicking the jar itself are you?

Posted: **Tue Dec 03, 2013 11:09 pm**

Thanks for all the hard work that went into this. I appreciate it both as an FTL fan and as a programmer.

Has anyone suggested being able to include an image thumbnail in the metadata in addition to the text description? What made me think of it are all the Captain's Edition skins for humans/engi/robots/etc. It's a giant pain to easily just go through and see the ones you like and check those. If each mod included a thumbnail of what the skin looked like (in this case it wouldn't be a thumbnail so much as a full image since the icons are so small). For ship mods, it'd be a thumbnail of the ship(s).

You could put a limit on the filesize/dimensions if you're worried about people bloating their mods with giant images.

On an unrelated topic, I'm sure it's been suggested before that SMM remember which mods you had checked the last time you patched, right? Could you humor me an explain why it doesn't, if there was some showstopper?

Posted: **Wed Dec 04, 2013 1:36 am**

Vhati wrote:
GotNinja101 wrote:"Re-Scan /mods" is grayed out and I can't click it.
So the main window does show up...
By that point "modman-log.txt" and "modman.cfg" should be created in SMM's folder.

GotNinja101 wrote:I'm assuming that modman-log.txt is supposed to be in the folder where the .jar is? I can't find it in there
If Slipstream thinks it's in some other folder (home?) and can't find mods/, that'd explain why it isn't scanning properly.

The thing is: double-clicking "modman.command" should be making sure that doesn't happen (it cd's to the script's location, then runs the jar).

You aren't double-clicking the jar itself are you?

I got the .command to work. Double clicking doesn't work, but going to the console and using that works just fine. It really is a pain to not be able to just double click the .command or the .jar, but oh well.

EDIT: I actually ran into another problem. I have the mods directory set up and all, and I have the program running, but when I click patch, it gives this error message:

Code: Select all

 Patching failed: java.io.EOFException

Log:

Code: Select all

18:43:20.489 [AWT-EventQueue-0] INFO  net.vhati.modmanager.ui.ManagerFrame - Patching...
18:43:20.489 [AWT-EventQueue-0] INFO  net.vhati.modmanager.ui.ManagerFrame - 
18:43:20.491 [Thread-4] INFO  net.vhati.modmanager.core.ModPatchThread - Restoring vanilla "data.dat"...
18:43:20.493 [Thread-4] INFO  net.vhati.modmanager.core.ModPatchThread - Restoring vanilla "resource.dat"...
18:43:20.539 [Thread-4] ERROR net.vhati.modmanager.core.ModPatchThread - Patching failed. java.io.EOFException
	at java.io.RandomAccessFile.readFully(RandomAccessFile.java:446)
	at net.vhati.ftldat.FTLDat$FTLPack.readLittleUInt(FTLDat.java:475)
	at net.vhati.ftldat.FTLDat$FTLPack.readIndex(FTLDat.java:572)
	at net.vhati.ftldat.FTLDat$FTLPack.<init>(FTLDat.java:461)
	at net.vhati.ftldat.FTLDat$FTLPack.<init>(FTLDat.java:451)
	at net.vhati.modmanager.core.ModPatchThread.patch(ModPatchThread.java:160)
	at net.vhati.modmanager.core.ModPatchThread.run(ModPatchThread.java:88)

Posted: **Wed Dec 04, 2013 11:25 am**

jep wrote:an image thumbnail in the metadata in addition to the text description? [...] a thumbnail of what the skin looked like (in this case it wouldn't be a thumbnail so much as a full image since the icons are so small).

A large collage image? Where would that go?

jep wrote:It's a giant pain to easily just go through and see the ones you like and check those.

The metadata currently includes a link to bring up each mod's forum thread, which often has images and verbose description. I doubt an author who didn't do that would put effort into composing an embedded image.

jep wrote:I'm sure it's been suggested before that SMM remember which mods you had checked the last time you patched, right? Could you humor me an explain why it doesn't, if there was some showstopper?

It can't look at the game's resources and recognize what mods, if any, where mixed into it.
If Slipstream started up with checkboxes pre-ticked, it'd give the impression to users that the checkboxes represent the current state of the game. But other tools, FTL reinstalls, etc. can change the dats without SMM's knowledge.

Every time you click the patch button, the resources get overwritten with a clean copy of vanilla dats, then any selected mods are added.

Technically, a menu item could re-tick the list to whatever was chosen last time Slipstream patched...

Posted: **Wed Dec 04, 2013 12:03 pm**

GotNinja101 wrote:when I click patch, it gives this error message:
Code: Select all
 Patching failed: java.io.EOFException 

FTL's resources (and SMM's backups) are corrupt. See the readme for how to resolve that.

The resource.dat is claiming to be larger than it is, and SMM crashes when it tries to read the whole thing and hits the end prematurely.

GotNinja101 wrote:I got the .command to work. Double clicking doesn't work, but going to the console and using that works just fine. It really is a pain to not be able to just double click the .command or the .jar, but oh well.

Someone with Ubuntu's Nautilus filemanager reported a similar problem. I suspect it's got a bug in how it treats double-clicked *.command files that have paths with spaces. Sounded like it wasn't quoting: treating everything up to the first space as a non-existent file to execute, and everything after as args.

I tweaked my script a little for the next version (you may need to chmod this to make it executable), but if the problem is in Nautilus' file-type associations it's happening to far upstream for me to fix it.

Posted: **Wed Dec 04, 2013 3:25 pm**

Vhati wrote:A large collage image? Where would that go?

Well, for the People skins example I gave, it'd really only need to be one thumbnail of the last image in the collage. The way the CE People mods work, each mod is a separate individual. Examples:
CEPM Human Militia Black Female.ftl
CEPM Human Militia Black Male.ftl
CEPM Human Militia White Female.ftl
CEPM Human Militia White Male.ftl
etc.

For a mod that includes several ships or weapons or whatever, the author could make a collage. Would it help if I mocked it up?

But SMM wouldn't really need to be concerned with the specifics. That would be up to the mod author (just like the existing description text is). It could just be done as a standard name and filetype, say thumbnail.png in the mod-appendix folder. Another option would be base64 encoding and including in the metadata.xml, but that seems like it would deter people from doing it because of the hassle.

Vhati wrote:The metadata currently includes a link to bring up each mod's forum thread, which often has images and verbose description. I doubt an author who didn't do that would put effort into composing an embedded image.

But couldn't you say the same thing about the existing metadata? Why bother including text at all when you could just include only a link and have them go to that forum page? For me, it's about convenience. I don't want to have to jump back and forth to easily see what each ship/skin/etc. looks like. Have you ever used the captain's mod People pack or use a lot of ships?

Vhati wrote:It can't look at the game's resources and recognize what mods, if any, where mixed into it.
If Slipstream started up with checkboxes pre-ticked, it'd give the impression to users that the checkboxes represent the current state of the game. But other tools, FTL reinstalls, etc. can change the dats without SMM's knowledge.

Every time you click the patch button, the resources get overwritten with a clean copy of vanilla dats, then any selected mods are added.

Technically, a menu item could re-tick the list to whatever was chosen last time Slipstream patched...

I understand the limitations and the concern. But much in the same way SMM remembers the mod order, even though it can't guarantee that that was really the mod order in the last patch. I think it's just mainly a usability issue. People who are modding are generally going to patch using SMM, then maybe come back later and add a mod/disable a mod/reorder to try to fix problems. I think they can be trusted to understand the limitations and it would help out a lot. I know it just wound up with me having to move a bunch of mods out (see the People pack above) so I ONLY had the mods I was using in the mods folder. Which defeats the whole purpose of being able to check some but not all of them when patching.

If you REALLY wanted to add a "power feature", you could support multiple "patch set" configurations which could be flipped between.

Subset Games Forum

Slipstream Mod Manager v1.9.1 (2018-01-07)

Re: Slipstream Mod Manager v1.4 (2013-09-20)

Re: Slipstream Mod Manager v1.4 (2013-09-20)

Re: Slipstream Mod Manager v1.4 (2013-09-20)

Re: Slipstream Mod Manager v1.4 (2013-09-20)

Re: Slipstream Mod Manager v1.4 (2013-09-20)

Re: Slipstream Mod Manager v1.4 (2013-09-20)

Re: Slipstream Mod Manager v1.4 (2013-09-20)

Re: Slipstream Mod Manager v1.4 (2013-09-20)

Re: Slipstream Mod Manager v1.4 (2013-09-20)

Re: Slipstream Mod Manager v1.4 (2013-09-20)