Hard Light Productions Forums
Hosted Projects - FS2 Required => Blue Planet => Topic started by: electrojustin on August 06, 2014, 11:21:55 pm
-
Received this error message attempting to play BluePlanet. fs2_open.log is attached.
Any ideas?
[attachment kidnapped by pirates]
-
You need the 2014 MediaVPs. They can be installed with the FSO installer (http://scp.indiegames.us/fsoinstaller/FreeSpaceOpenInstaller.jar) or manually from this thread (http://www.hard-light.net/forums/index.php?topic=86475.0).
-
Used the FSO installer for everything. I've got the 2014 Media VPs, was just using them to play the main campaign a few minutes ago.
-
Blue Planet expects to find them in /home/justin/gaming_misc/Freespace 2/mediavps_2014/ but isn't finding them. If you have them in some other folder, please make sure to move them to this path.
-
So I was playing with wxLauncher.
Command line enabling 2014 MediaVPs mod: /home/justin/gaming_misc/Freespace 2/fs2_open_3.7.2_RC3 -mod MediaVPs_2014
Command line enabling Blue Planet: /home/justin/gaming_misc/Freespace 2/fs2_open_3.7.2_RC3 -mod blueplanet,mediavps_2014
Seriously? Seriously?!
wxLauncher/FSO installer folks,
LINUX FILESYSTEMS ARE CASE SENSITIVE
-
gah - this is a case-sensitive filesystem issue :( The installer installs to MediaVPs_2014 (and that location is controlled by the FSU/mediavpvs team) and Blueplanet is configured to use mediavps_2014. This doesn't matter except on Linux. So either do what Jeff said and rename it to all lowercase, or change the blueplanet[2]/mod.ini files to reference the upper-case name. Longer term I don't know what the better decision will be.
(and having just seen your most recent post, I need to re-iterate that it's actually the FSU/mediavps and Blueplanet teams that control the filename case here)
-
Although FSO really should be able to take a -mod mediavps_2014 commandline and locate a MediaVPs_2014 folder, seeing as how most of its file operations are case-insensitive, even on case-sensitive filesystems.
-
Although FSO really should be able to take a -mod mediavps_2014 commandline and locate a MediaVPs_2014 folder, seeing as how most of its file operations are case-insensitive, even on case-sensitive filesystems.
Maybe internally case doesn't matter, but I don't know how FSO would magically divine the correct capitalization of MediaVPs_2014 when it goes to make the sys calls to load a file from that path.
This doesn't matter except on Linux.
I think this might effect Mac and BSD users as well, I always thought UNIX based operating systems had case sensitive files.
that location is controlled by the FSU/mediavpvs team
My apologies to the wxLauncher and FSO installer teams then.
How about setting a convention of some sort for the future :p?
A note to all modders and the FSU team then: ALWAYS USER LOWER CASE. Or at least make sure the mod ini is consistent. Also, as long as I'm ranting about filesystem differences, don't include slashes, forward or otherwise. I dunno what / does in windows, but in Linux paths it indicates going into a subdirectory, like \ does in windows. And spaces, quotation marks, and single quotes are a pain, because you sometimes have to escape those in some filesystems (like ext).
-
There should be a way in Linux to mark a tree of subdirectories as case-insensitive. =P that would be great.
Edit
I suppose FSO could do a case-insensitive grep to get the correct case and then use that?
-
Although FSO really should be able to take a -mod mediavps_2014 commandline and locate a MediaVPs_2014 folder, seeing as how most of its file operations are case-insensitive, even on case-sensitive filesystems.
Maybe internally case doesn't matter, but I don't know how FSO would magically divine the correct capitalization of MediaVPs_2014 when it goes to make the sys calls to load a file from that path.
It doesn't need to "divine" anything; if there's more than one folder that matches, case-insensitively, then load all of them. It's not like FSO is unused to loading data from multiple directories.
There should be a way in Linux to mark a tree of subdirectories as case-insensitive. =P that would be great.
Well, you can always mount a FAT32 filesystem there.
-
Loading multiple locations is fine, loading them in the correct order would be more problematic.
Now, even though I kinda pointed the finger at the modders earlier I'm starting to think that was a bit unfair (sorry guys), after all you can practically only mod on Windows anyway and it's a bit unreasonable to expect a modder to know about the case sensitive Linux/BSD filesystem (since OSX I believe uses a case-preserving filesystem). So maybe FSO could be changed to lookup the dir names insensitively (since it already does that inside VPs), or maybe the installer could convert all extracted dirs to lowercase, and maybe change the contents of all mod.ini primarylist & secondarylist lines to lowercase (for Linux/BSD only).
-
Loading multiple locations is fine, loading them in the correct order would be more problematic.
What correct order? If they were all meant to be in the same folder, they shouldn't be trying to override each other anyway.
-
maybe the installer could convert all extracted dirs to lowercase
this
after all you can practically only mod on Windows
Why exactly is that? This sounds like something I should work towards rectifying if at all possible.
Well, you can always mount a FAT32 filesystem there.
eww
Linux has NTFS modules that come pre-installed with most distros if you want to go that route. It's journaling at least, but still oh god the fragmentation.
-
after all you can practically only mod on Windows
Why exactly is that? This sounds like something I should work towards rectifying if at all possible.
FRED2_Open is Windows-only. If you know any C/C++, wxFRED could always use more help (I've been meaning to take a look at the code myself one of these days, but I haven't found the time).
-
FRED2_Open is Windows-only. If you know any C/C++, wxFRED could always use more help
Really? wxFRED compiles and runs under Linux. No Makefiles though... :(
-
FRED2_Open and wxFRED are entirely separate projects.
-
FRED2_Open and wxFRED are entirely separate projects.
Oh. So wxFRED works for Linux but is just bad to the point of unusable?
-
FRED2_Open and wxFRED are entirely separate projects.
Oh. So wxFRED works for Linux but is just bad to the point of unusable?
It's incomplete to the point of being literally unusable; last I heard, none of the GUI elements were coded to actually do anything yet.
-
Loading multiple locations is fine, loading them in the correct order would be more problematic.
What correct order? If they were all meant to be in the same folder, they shouldn't be trying to override each other anyway.
Ah... :nervous: you are probably correct :D I should try that with the mediavps_3612 since I know that their current installer setup results in two dirs with VPs in each :)
after all you can practically only mod on Windows
Why exactly is that? This sounds like something I should work towards rectifying if at all possible.
In addition to the FRED2/wxFRED issues that AdmiralRalwood mentioned, PCS2 is also quite unreliable on Linux. It compiles and runs OK sometimes but crashes frequently. And to make it more ~fun~, it's random. Sometimes a model will open fine, other times the same model will crash on load. And then when I ran it in a debugger, it didn't crash at all :sigh:
-
And then when I ran it in a debugger, it didn't crash at all :sigh:
GDB disables ASLR (Address Stack Layout Randomization, or something like that. It's a security "feature" to make stack smashing harder). This sounds like the kind of randomness that comes with buffer overflows. Have you tried running valgrind or memcheck on it to see if it turns up with anything?
Edit: In case you were curious, the reason ASLR is important is because AFAIK it's implemented as just some random stack pushes. So a buffer overflow might result in junk data being overwritten or something important like the saved instruction pointer being overwritten, resulting in the crash. Has running it from the command line ever resulted in an error message along the lines of "stack smashing detected"?
Also, Valgrind might make the program run pretty slow, so it could be worth looking into compiling it with gcc stack protection to see where/when the buffer overflows actually occur. But I digress quite a bit, this is probably a discussion for a proper bug report somewhere other than the BluePlanet subforum.
It's incomplete to the point of being literally unusable; last I heard, none of the GUI elements were coded to actually do anything yet.
This. I just checked the source and everything in the editors directory is like 10 lines of code, so I'm guess it was all just framework and placeholder code. Running the application doesn't even result in a blank mission, it just tiles my GTK default background and gives me some buttons to push, which of course don't do anything.
-
And then when I ran it in a debugger, it didn't crash at all :sigh:
GDB disables ASLR (Address Stack Layout Randomization, or something like that. It's a security "feature" to make stack smashing harder). This sounds like the kind of randomness that comes with buffer overflows. Have you tried running valgrind or memcheck on it to see if it turns up with anything?
Edit: In case you were curious, the reason ASLR is important is because AFAIK it's implemented as just some random stack pushes. So a buffer overflow might result in junk data being overwritten or something important like the saved instruction pointer being overwritten, resulting in the crash. Has running it from the command line ever resulted in an error message along the lines of "stack smashing detected"?
Also, Valgrind might make the program run pretty slow, so it could be worth looking into compiling it with gcc stack protection to see where/when the buffer overflows actually occur. But I digress quite a bit, this is probably a discussion for a proper bug report somewhere other than the BluePlanet subforum.
It was many months ago, but my memory says I was just getting segmentation faults. Yes, some sort of buffer overflows seem likely, I just haven't spent the time yet to track it down any further.
FYI - in case you're interested, the source is here: http://sourceforge.net/p/alliance/pcs2/ci/master/tree/
It's incomplete to the point of being literally unusable; last I heard, none of the GUI elements were coded to actually do anything yet.
This. I just checked the source and everything in the editors directory is like 10 lines of code, so I'm guess it was all just framework and placeholder code. Running the application doesn't even result in a blank mission, it just tiles my GTK default background and gives me some buttons to push, which of course don't do anything.
Not entirely true - some of the buttons cause errors to appear! :D