Subset Games Forum

Don't sweat it. Everyone is not competent at some point and about some subjects, what matters is learning and improving. Besides, frankly, this is one of the reasons many experienced users hate the fact that Windows hides file extension by default, and change that setting as soon as they log in to Windows. This has been the source of many problems.

Hey, I was curious what I'm doing wrong here. I got GMM, extracted it, and then moved the files to the FTL folder. I enabled Begining Scrap Advantage and ran FTL, but I got a white box on a black screen. The only fix I can find is reinstalling. I bought the game on steam. Can anyone point out a fix?

I'm not sure what I did wrong. I followed the Mac install instructions, but when patching mods I got this:

Added Beginning Scrap Advantage.ftl
Added Infinite Space_0.2.3.ftl
Nov 11 13:35:47 Ryans-MacBook-Pro.local Python[877] <Error>: kCGErrorInvalidConnection: CGSGetWindowTags: Invalid connection
Nov 11 13:35:47 Ryans-MacBook-Pro.local Python[877] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
Nov 11 13:36:04 Ryans-MacBook-Pro.local Python[877] <Error>: kCGErrorInvalidConnection: CGSGetWindowTags: Invalid connection
Nov 11 13:37:41 Ryans-MacBook-Pro.local Python[877] <Error>: kCGErrorInvalidConnection: CGSGetWindowTags: Invalid connection

What does that mean?

Grognak wrote:Version 1.4.1 released with hopefully working Mac/Linux support (thanks for the commit.)

Still getting this error in 1.4.1 for Linux:

@Parzival, try redownloading and trying again.

@Bats, that error is completely unfamiliar to me. Please try reinstalling the latest version of python 2.x

@Ken, please make sure you moved the latest .ini file to the correct folder.

Grognak wrote:@Parzival, try redownloading and trying again.

I tried re-downloading, but the same thing happened. By the way, it worked fine before I added GMM, and a reinstall fixes it, but it crashes with GMM installed.

Grognak wrote:@Ken, please make sure you moved the latest .ini file to the correct folder.

I've tried every combination of moving the whole folder "Grognaks Mod Manager v1.4.1" and just its contents that I can think of. Below is what my best guess from the instructions (fyi, the instructions "Linux: in which FTL resides." isn't the most helpful since, as you can see, there are 4 files named FTL).

ken oh wrote:

Grognak wrote:Version 1.4.1 released with hopefully working Mac/Linux support (thanks for the commit.)

Still getting this error in 1.4.1 for Linux:

Code: Select all

Traceback (most recent call last):
  File "main.py", line 417, in <module>
    allowzip = cfg.getboolean("settings", "allowzip")
  File "/usr/lib/python2.7/ConfigParser.py", line 368, in getboolean
    v = self.get(section, option)
  File "/usr/lib/python2.7/ConfigParser.py", line 607, in get
    raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'settings'

Hi,

I just discovered mod manager last night and ran into the same error on OSX, and thankfully it's a simple fix. The script is simply searching for "modman.ini" in whatever directory it was run from, but it doesn't make sure that it's using the fully qualified path to find the file, so if you run from terminal, without changing into the right directory first, it will fail.

The easiest way to fix this is to change line 415 in main.py from: to the following: EDIT: Below is the old method I used in case the new fix doesn't work.

The following example are from OSX, non-steam installation, but should work with linux, just make sure to use the right path/directory.

For example, before you run main.py from terminal, you need to cd into the FTL.app/contents directory:
[code]cd /Applications/FTL.app/Contents/[/code]
then launch the script
[code]python main.py[/code]
Or for the alternate solution, change the path on line 415 in main.py from:
[code]cfg.read("modman.ini")[/code]
to whatever directory it's stored in, the following is mine:
[code]cfg.read("/Applications/FTL.app/Contents/modman.ini")[/code]
Anyway, I hope this helps, I know there's likely a more elegant way to handle this, I just don't know python to be able to help.

jocelyn wrote:

Code: Select all

cfg.read("/Applications/FTL.app/Contents/modman.ini")

This got me somewhere (of course, my path is different at /home/kenoh/games/FTL/src/modman.ini), but now it'll bring a Tkinter window up saying that it needs to be in the correct directory. If anyone can look at my tree above and confirm I'm not actually messing this up, that would be awesome.

I have a suggestion for Grognak. I'm not sure if it might disappear in the torrent of tech support requests, but I figure it's worth a go.

As a mod author, the .append setup is a great improvement on having to completely overwrite the XML files. But it's a bit annoying sometimes when mods interact. In particular, clashes can and do occur in situations like this:

Mod A: Wants to change <weaponBlueprint name="Weapon_X"> to adjust its cooldown and power req (but leave everything else the same)
Mod B: Wants to change <weaponBlueprint name="Weapon_X"> to adjust its name and description (but leave everything else the same)

The natural end result is clear: we'd like Weapon_X to have the values from the base game, but with the cooldown and power req specified in Mod A, and the text from Mod B. But there's no way to produce this end result using the .append format. When we change the stats for a <weaponBlueprint>, we have to include all the old data in it even if we're not going to change most of it.

It'd be great if there was a way to write our mods to play nicely with each other like this.

One possible solution would be to make GMM understand a second suffix, not just blueprints.xml.append but also something like blueprints.xml.update. In a .update file, only XML tags with attributes precisely matching existing XML tags in the corresponding file would be recognised. The contents of those tags would be appended within the existing XML tag, but the original contents from the base file would still be there as well.

With this format, Mod A could have blueprints.xml.update saying:
<weaponBlueprint name="Weapon_X"><cooldown>5</cooldown><power>1</power></weaponBlueprint>
and Mod B could have blueprints.xml.update saying:
<weaponBlueprint name="Weapon_X"><title>Death Ray</title><desc>Fires pure death.</desc></weaponBlueprint>

They no longer conflict because they're not required to copypaste the power, cooldown, title, and desc from the original XML file. The mod manager can clearly tell which operations to perform on the base game's version of <weaponBlueprint name="Weapon_X">, and the result is what we want.

So, Grognak, do you think it's feasible to make GMM handle some kind of syntax like this, or some other way to avoid this kind of conflict?