
Grognak's Mod Manager v1.7 (Updated March 6, 2013!)
-
- Posts: 808
- Joined: Mon Sep 17, 2012 11:42 pm
Re: Grognak's Mod Manager v1.4.1 (Updated Nov 9 2012!)
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.

Forum janitor — If you spot spam, PM me the URL and/or the username of the spammer.
I have powers, moderator powers. I am not keen on using them, but will do so if needed.
I have powers, moderator powers. I am not keen on using them, but will do so if needed.
-
- Posts: 9
- Joined: Sun Nov 11, 2012 12:41 pm
Re: Grognak's Mod Manager v1.4.1 (Updated Nov 9 2012!)
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?
-
- Posts: 1
- Joined: Sun Nov 11, 2012 1:36 pm
Re: Grognak's Mod Manager v1.4.1 (Updated Nov 9 2012!)
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?
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?
-
- Posts: 8
- Joined: Tue Nov 06, 2012 5:03 pm
Re: Grognak's Mod Manager v1.4.1 (Updated Nov 9 2012!)
Still getting this error in 1.4.1 for Linux:Grognak wrote:Version 1.4.1 released with hopefully working Mac/Linux support (thanks for the commit.)
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'
-
- Posts: 172
- Joined: Tue Sep 18, 2012 9:42 pm
Re: Grognak's Mod Manager v1.4.1 (Updated Nov 9 2012!)
@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.
@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.
-
- Posts: 9
- Joined: Sun Nov 11, 2012 12:41 pm
Re: Grognak's Mod Manager v1.4.1 (Updated Nov 9 2012!)
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:@Parzival, try redownloading and trying again.
-
- Posts: 8
- Joined: Tue Nov 06, 2012 5:03 pm
Re: Grognak's Mod Manager v1.4.1 (Updated Nov 9 2012!)
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).Grognak wrote:@Ken, please make sure you moved the latest .ini file to the correct folder.
Code: Select all
FTL
├── data
│ ├── amd64
│ │ ├── bin
│ │ │ └── FTL
│ │ └── lib
│ │ ├── libbassmix.so
│ │ ├── libbass.so
│ │ ├── libfreetype.so.6
│ │ ├── libIL.so.1
│ │ ├── libILU.so.1
│ │ ├── libILUT.so.1
│ │ ├── libpng12.so.0
│ │ ├── libSDL-1.2.so.0
│ │ ├── libstdc++.so.6
│ │ └── libz.so.1
│ ├── exe_icon.bmp
│ ├── FTL
│ ├── licenses
│ │ ├── LGPL.txt
│ │ ├── README-DevIL.txt
│ │ ├── README-FreeType.txt
│ │ ├── README-RapidXML.txt
│ │ ├── README-SDL.txt
│ │ └── README-zlib.txt
│ ├── modman.exe
│ ├── modman.ini
│ ├── mods
│ │ ├── Beginning Scrap Advantage.ftl
│ │ └── readme.txt
│ ├── readme.txt
│ ├── resources
│ │ ├── data.dat
│ │ └── resource.dat
│ ├── src
│ │ ├── ftldat.py
│ │ ├── ftldat.pyc
│ │ ├── __init__.py
│ │ ├── license.txt
│ │ ├── main.py
│ │ └── readme.txt
│ └── x86
│ ├── bin
│ │ └── FTL
│ └── lib
│ ├── libbassmix.so
│ ├── libbass.so
│ ├── libfreetype.so.6
│ ├── libIL.so.1
│ ├── libILU.so.1
│ ├── libILUT.so.1
│ ├── libpng12.so.0
│ ├── libSDL-1.2.so.0
│ ├── libstdc++.so.6
│ └── libz.so.1
├── FTL
└── FTL_README.html
-
- Posts: 6
- Joined: Mon Nov 12, 2012 5:57 pm
Re: Grognak's Mod Manager v1.4.1 (Updated Nov 9 2012!)
Hi,ken oh wrote:Still getting this error in 1.4.1 for Linux:Grognak wrote:Version 1.4.1 released with hopefully working Mac/Linux support (thanks for the commit.)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'
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:
Code: Select all
cfg.read("modman.ini")
Code: Select all
cfg.read(os.path.join(dir_root, "modman.ini"))
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.
-
- Posts: 8
- Joined: Tue Nov 06, 2012 5:03 pm
Re: Grognak's Mod Manager v1.4.1 (Updated Nov 9 2012!)
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.jocelyn wrote:Code: Select all
cfg.read("/Applications/FTL.app/Contents/modman.ini")
-
- Posts: 184
- Joined: Sun Sep 30, 2012 2:24 pm
Re: Grognak's Mod Manager v1.4.1 (Updated Nov 9 2012!)
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?
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?
Many years ago I created the FTL Starcraft mod: 18 new challenging ships to fly through the FTL universe!, and wrote a tutorial on creating your own FTL ships. They haven't been updated for AE though.