Hi Please consider this ebuild for Portage. FreeSpace2 is a popular free space dogfight simulation classic (www.freespace2.com). Some time ago Volition (the developer company) released the sources to the engine and some people created The Source Code Project arround this sources to continue maintenance of the codes. "fs2open" is the result of their work, a very enhanched freespace2 engine (it works to play the original campaigns with it too). I have some questions regarding this ebuild: - the license, I have commented in the ebuild (which creates the "Copyright" command not found messages on install), I am not very sure how to name it, I said maybe "FS2"; the license text is included with the tarball in the file COPYING which I have attached here - media files; SCP (the source code project) also develops enhanched media files to take advantage of their engine new features (new high-poly models and high definition textures, etc); they distribute their files from this URL: "http://scp.indiegames.us/download.php?view.57"; I have no idea how to use that download location to have the ebuild download the media files (on an USE flag for example) Thanks!
Created attachment 69159 [details] The FS2 code license
Created attachment 69160 [details] fs2_open 3.6.7 ebuild file
The ebuild says to me, that I have to copy the game to /etc/portage/profile. That can't be right, can it? I tried to copy the game to /opt/fs2_open, where ist installed the binary, but then it complains that the gamedata is not in the right place. So where should I put it?
Created attachment 70968 [details] fs2_open-3.6.7.ebuild There were several problems with the previous ebuild and I've fixed them here. The commented license was NOT the reason for the error, you had accidently uncommented the first line of the file. Putting USE flags in IUSE also doesn't just magically make things happen. I wasn't actually able to test the game since I only have FreeSpace 1. I was hoping to play this using fsport but that still needs the FreeSpace 2 files. I will update the ebuild for the icculus.org port instead.
Created attachment 70970 [details] fs2_open-3.6.7.ebuild Realised I could make it even shorter.
The ebuild I initially posted was tested on my computer first and worked, I cannot exaplain how it got here a non-working one... Thanks for fixing it, I dont have time currently to work on this stuff (and anyways considering the gentoo team answers me with an average 3-4 months in between messages I don't think I should hurry up either:( ).
Created attachment 75391 [details] fs2_open-3.6.7.ebuild Here is a tidied ebuild. Installation instructions are at http://forums.gentoo.org/viewtopic-p-2977565.html
Created attachment 75412 [details] fs2_open-3.6.7.ebuild Handling the zpack download has forced me to use wget within src_install(), since "request.php?148" results in a download named "mv_zpack.zip", which breaks the normal unpacking. This ebuild works, although it will not cache the zpack file.
(In reply to comment #8) This ebuild has been verified to work correctly on AMD64 without modifications. I'm suggesting to add the amd64 keyword.
Works great for me (fs2_open-3.6.7.ebuild). Although, I had to add amd64 keyword first...
Bumping to say it works for me too, on AMD64. Does anything else need done to this before it can make the tree?
There's no way it's going in with a wget in the src_install. that needs to be fixed first. I'm also not a fan of the "copy the datafiles from your windows install". Isn't there a native-linux method to extract the files?
I don't think the extracting is the problem, it's the patching. It's an rtpatch. I found a Linux client for rtpatch but it was closed source and I am unsure of the distribution rights. I actually tried to contact the rtpatch people several times to ask them but they never returned my calls. Might try again soon. The alternative would be for someone to make a binary patch from a Windows installation that we could use. The problem is that I think there are mulitple versions out there so we may end up having to make patches for all the versions we find. As I said above, I don't own a copy of the game myself (yet).
Created attachment 85478 [details] fs2_open-3.6.7.ebuild Wget showed where the php redirects for the zpack files go, so here's an ebuild with nice SRC_URI entries and no nasty wgets. However, it also naughtily brings in the "nightly" source code, to patch the 3.6.7 source code to fix a compilation error with newer versions of openal that I've just experienced, which is also mentioned at: http://scp.indiegames.us/forum_viewtopic.php?11.298.25
Created attachment 87169 [details] fs2_open-9999.ebuild For even more eye-candy, here's a CVS ebuild with the latest MediaVP mods.
The Freespace Wiki also has this http://www.hard-light.net/wiki/index.php/Fs2_open_on_Linux Not not sure if it help here though.
Created attachment 90110 [details] fs2_open-9999.ebuild Updated to the "3.6.8 Zeta" MediaVP files. http://www.hard-light.net/forums/index.php/topic,39905.0.html
http://en.wikipedia.org/wiki/Descent:_FreeSpace#FreeSpace_2_License_Agreement With this is mind, would it be possible to distribute a legal tarball containing the needed files?
I think not, based on the "friends and acquaintances" bit. I also think it would be a good idea to split this into engine and data ebuilds. I might try calling rtpatch again. I had no luck earlier this year.
http://www.hard-light.net/wiki/index.php/Fs2_open_on_Linux From the looks of this, rtpatch isn't needed. Also, I've played FS2 fine with no RTPatch action isn't enough. Its just a matter of using unshield to get the data files. Shouldn't be too hard, I was gonna give it a go myself.
Hmm that looks promising but I was mentioning rtpatch for the people who may not have the latest version. They don't seem to mention versions at all on that page. I've now created data-only ebuilds for FS1 and Silent Threat but these are primarily for use with the other engine in bug #50612. I still don't have FS2 myself so I can't try fs2_open just yet.
iirc, the rtpatch isn't required for fs2open, just icculus.org freespace. We'd be grateful for your data ebuilds whenever you can post them :D I can test them.
I've CC'd you to the other bug, Mike. The new ebuilds are posted there. I've seen several sources that say that the game does need to be patched to 1.2 - even on that very same wiki. The Home Of The Underdogs version is already patched, which may be why they forgot to mention it on that particular page. I am going to create a freespace2-demo-data ebuild and was hoping to try it with both the icculus version and fs2_open but I gather that fs2_open doesn't support the demo so it looks like it'll only be for the icculus version.
Comment on attachment 85478 [details] fs2_open-3.6.7.ebuild The openal patch is no longer available.
Created attachment 115624 [details] freespace2-data-1.0.ebuild Freespace 2 Data ebuild. Modelled on the Quake/Unreal data ebuilds, installs and extracts the needed files from the CDROM. If I'm correct, this and the following ebuilds might actually allow this game to make it into portage? I'm interested in feedback and fixing the ebuilds so they can get into portage.
Created attachment 115627 [details] freespace2-mediavps-3.6.9.ebuild The MediaVPs for the latest version, available as a mod.
Created attachment 115629 [details] fs2_open-3.6.9.ebuild Freespace Open engine ebuild. Integrates with my other two ebuilds and adds videos.
Created attachment 115630 [details] Volition Freespace 2 Data license
Created attachment 115631 [details] Freespace 2 Source Code Project license
Created attachment 115634 [details] fs2_open-3.6.9.ebuild New version that adds a desktop entry. No icon yet, but working on that issue with upstream.
Created attachment 115996 [details] fs2_open-3.6.9.ebuild Small dependency fixes
Created attachment 117475 [details] freespace2-mediavps-3.6.9.ebuild freespace2-mediavps-3.6.9.ebuild Fixed line 30: 'app-app/unrar"' to 'app-arch/unrar"'
Also, where I might look to see what the differences are between USE=cell and USE=adveffects in freespace2-mediavps-3.6.9 and why they are mutually exclusive?
mediavps adds shiny new effects. adveffects adds the really large textures and effects suitable only for high-end computers. cell uses cell shading and is not compatible with the other effects.
I'd suggest moving the download/install of the FS2OGGcutscenepack.vp to the data-ebuild and not including freespace2-data in $RDEPEND. Reason for this is that the engine is used as a basis for three good mods with more to come. These are TBP (The Babylon Project), Wing Commander Saga and Beyond The Red Line (Battlestar Galactica). For people who do not own the original game this will be the main reason to install the fs2-ebuild. For as long as this ebuild is not included in the main tree it means you have to download the whole vid-package just to get a valid checksum for portage.
errors with. ted -Wno-char-subscripts -I../lua -march=nocona -O2 -pipe -MT hudartillery.o -MD -MP -MF ".deps/hudartillery.Tpo" -c -o hudartillery.o `test -f 'hud/hudartillery.cpp' || echo './'`hud/hudartillery.cpp; \ then mv -f ".deps/hudartillery.Tpo" ".deps/hudartillery.Po"; else rm -f ".deps/hudartillery.Tpo"; exit 1; fi graphics/gropengltexture.cpp: In function 'int opengl_check_framebuffer()': graphics/gropengltexture.cpp:1819: error: 'GL_FRAMEBUFFER_INCOMPLETE_DUPLICATE_ATTACHMENT_EXT' was not declared in this scope make[1]: *** [gropengltexture.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory `/var/tmp/portage/games-action/fs2_open-3.6.9/work/fs2_open-3.6.9/code' make: *** [all-recursive] Error 1 * * ERROR: games-action/fs2_open-3.6.9 failed.
Created attachment 170227 [details, diff] patch to remove the need for GL_FRAMEBUFFER_INCOMPLETE_DUPLICATE_ATTACHMENT_EXT Patch to remove GL_FRAMEBUFFER_INCOMPLETE_DUPLICATE_ATTACHMENT_EXT from the code base. This extension has apparently been removed since and shouldn't be needed here anyway.
fails to compile for me aswell, very early into the merge on GCC 4.3.2, AMD64 ai/aiturret.cpp: In function ‘void dcf_use_parent_target()’: ai/aiturret.cpp:828: warning: deprecated conversion from string constant to ‘char*’ ai/aiturret.cpp:828: warning: deprecated conversion from string constant to ‘char*’ ai/aiturret.cpp: At global scope: ai/aiturret.cpp:1077: warning: deprecated conversion from string constant to ‘char*’ ai/aiturret.cpp:1077: warning: deprecated conversion from string constant to ‘char*’ ai/aiturret.cpp: In function ‘void ai_fire_from_turret(ship*, ship_subsys*, int)’: ai/aiturret.cpp:1876: error: ‘INT_MAX’ was not declared in this scope make[1]: *** [aiturret.o] Error 1 could this be due to -funroll-loops in its CFLAGS? I don't see anything good coming from hardcoding this into the build :/ Also, -march=athlon64 and -Os are hardcoded aswell, but will get overridden by user's march and -O level
I ran into the same compilation error that haarp did. I am also running Gentoo on an AMD64 architecture with GCC 4.3.2-r3. Reproducible: always Steps to reproduce: 1. emerge fs2_open-3.6.9 Actual results: ai/aiturret.cpp: At global scope: ai/aiturret.cpp:1077: warning: deprecated conversion from string constant to ‘char*’ ai/aiturret.cpp:1077: warning: deprecated conversion from string constant to ‘char*’ ai/aiturret.cpp: In function ‘void ai_fire_from_turret(ship*, ship_subsys*, int)’: ai/aiturret.cpp:1876: error: ‘INT_MAX’ was not declared in this scope make[1]: *** [aiturret.o] Error 1 make[1]: *** Waiting for unfinished jobs.... ai/aicode.cpp: In function ‘int ai_fire_secondary_weapon(object*, int, int)’: ai/aicode.cpp:6951: warning: array subscript is below array bounds make[1]: Leaving directory `/var/tmp/portage/games-action/fs2_open-3.6.9/work/fs2_open-3.6.9/code' make: *** [all-recursive] Error 1 I have GCC 4.1.2 installed too and tried compiling fs2_open with that version. I did not run into any compilation errors except the GL_FRAMEBUFFER_INCOMPLETE_DUPLICATE_ATTACHMENT_EXT error which is easily patched. Once compiled the game ran fine except for one thing: the mouse does not work and I also tested a joystick controller and that did not work either. THe in game cursor is just stuck in the middle of the screen. SO the game is pretty unplayable because there is no input functionality. If anyone knows why there is no input/mouse available. Lastly, after browsing the fs2_open forums (http://www.hard-light.net/forums/index.php/board,50.0.html) I found out there is a QT based launcher for fs2_open call yal (yet another launcher). I have tried to download it but the tarball source destination is not reachable. If anyone can get a copy of the source so that we can make an ebuild that would be great because apparently the launcher is very useful in configuring fs2_open. Best regards, Shane
Hi Same error on x86 with gcc-4.3.2-r3. How can i force the use of e certain version of gcc in the ebuild? Francesco
3.6.10 is finally out. http://www.hard-light.net/forums/index.php/topic,64520.0.html
had some problems with the 3.6.9 ebuilds. some errors like: "missing space by parenthesis: '(h'" I solved it with changing line from: "mediavps? (=games-action/freespace2-mediavps-${PV})" to "mediavps? ( =games-action/freespace2-mediavps-${PV} )" now it works for me!
(In reply to comment #39) > GL_FRAMEBUFFER_INCOMPLETE_DUPLICATE_ATTACHMENT_EXT error which is easily > patched. I have added to ebuild these lines: " src_unpack() { if [ "${A}" != "" ]; then unpack ${A} fi epatch "${FILESDIR}/fs2_open-3.6.9-bugzilla.patch" } " where fs2_open-3.6.9-bugzilla.patch is patch here located. But I got aiturret error. Please could you (somebody) told me how it have to be patched?
Created attachment 232121 [details] New ebuilds for mediavps from freespace2 and TBP and fs2_open.3.6.10 and launcher Can't find icon for launcher (there is a .ico file but no .png) I couldn't find a way for having several mods installed because config files on home dir; fs2_open ebuild will force 1 mod install (but you could install all mediavps and launcher) Please test it.
When trying to install fs_open I got first the following error: >>> Verifying ebuild manifests !!! A file listed in the Manifest could not be found: /usr/local/portage/games-action/fs2_open/fs2_open-3.6.9.ebuild I copy the ebuild from this bug report to the mentioned directory and get the following error: >>> Verifying ebuild manifests !!! Digest verification failed: !!! /usr/local/portage/games-action/fs2_open/fs2_open-3.6.9.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 1205 !!! Expected: 1335 Should I do a digest of the ebuild or is the Manifest in fs2_open.tar.bz2 simply wrong and shouldn't contain the reference to fs2_open-3.6.9.ebuild? Thanks for bringing this game to portage.
(In reply to comment #45) > Should I do a digest of the ebuild or is the Manifest in fs2_open.tar.bz2 > simply wrong and shouldn't contain the reference to fs2_open-3.6.9.ebuild? > > > Thanks for bringing this game to portage. > I uploaded manifest trying to avoid doing manifest yourself (because requires downloading all huge files, not matter your userflags) please do a digest # ebuild fs2_open-3.6.10.ebuild digest maybe you needing doing it too for mediavps,... ebuilds too hope it helps
After performing a digest on all ebuilds, emerge is able to install everything, but when I start the launcher, I am not able to choose the location of the fs2_open executable. I suppose this is what you are refering to in your comment with the last ebuild. In addition I am not able to start the babylon MOD, see below. -------------------------------------------------------------------------------- My emerge --info: Portage 2.1.8.3 (default/linux/amd64/10.0, gcc-4.3.4, glibc-2.11.2-r2, 2.6.34-gentoo-r6 x86_64) ================================================================= System uname: Linux-2.6.34-gentoo-r6-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_5200+-with-gentoo-1.12.13 Timestamp of tree: Sat, 30 Oct 2010 13:00:20 +0000 app-shells/bash: 4.1_p7 dev-java/java-config: 2.1.11 dev-lang/python: 2.6.5-r3, 3.1.2-r4 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 2.3-r1 sys-devel/autoconf: 2.13, 2.65-r1 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.3.4, 4.4.4-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=athlon64 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests collision-protect distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="fr_BE" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en_GB fr" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/sunrise /usr/portage/local/layman/Spring /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowext S3TC X a52 acl aiglx alsa amd amd64 apm automount avi bash-completion be berkdb binary-drivers bitmap-fonts bootsplash bzip2 ccache cdda cddb cdparanoia cdr consolekit cracklib crypt cups cxx dbus dhcp directfb dlloader dmi dmx dri dvd dvdr emacs encode evolution fam fbcon ffmpeg flac font-server fortran gdbm gif gimp glut gpm graphviz gstreamer gtk gtk2 hal iconv imap jabber joystick jpeg kde libg++ mad matroska mikmod mime mmx mng modules mp3 mpeg mpeg2 mudflap multilib ncurses nls nptl nptlonly nsplugin nvidia ogg openal opengl openmp pam pdf pdflib png policykit ppds pppd python qt3support quicktime readline reflection sdl session spell sql sqlite sqlite3 sse sse2 ssl svg sysfs tcpd theora truetype truetype-fonts type1-fonts udev unicode usb vorbis webkit wma wmf xml xorg xscreensaver xulrunner xv zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_GB fr" PHP_TARGETS="php5-2" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia nv vesa vga" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS -------------------------------------------------------------------------------- When I start the launcher I got a pop up window with the following text: "The launcher must be in the same directory as the binary you are trying to use. Trying to find binary in the launcher directory instead." In the edit bar at the top of the main window, the path to the babylon MOD is already set and I can't change it. When I try to start the MOD I got the following errors: Unrecognized command line parameter "-jpgtga". Ignoring... *** buffer overflow detected ***: /opt/babylon/fs2_open terminated ======= Backtrace: ========= /lib/libc.so.6(__fortify_fail+0x37)[0x7f23a598b427] /lib/libc.so.6(+0xe8150)[0x7f23a5989150] /lib/libc.so.6(+0xe6f3d)[0x7f23a5987f3d] /opt/babylon/fs2_open[0x6c35cc] /opt/babylon/fs2_open[0x6c4d73] /opt/babylon/fs2_open[0x6c5608] /opt/babylon/fs2_open[0x6c8942] /opt/babylon/fs2_open[0x410fca] /opt/babylon/fs2_open[0x412ed5] /opt/babylon/fs2_open[0x413271] /lib/libc.so.6(__libc_start_main+0xe6)[0x7f23a58bfba6] /opt/babylon/fs2_open[0x409d89] ======= Memory map: ======== 00400000-0087f000 r-xp 00000000 08:03 8224770 /usr/share/games/fs2_open/fs2_open 00a7e000-00a7f000 r--p 0047e000 08:03 8224770 /usr/share/games/fs2_open/fs2_open 00a7f000-00aa3000 rw-p 0047f000 08:03 8224770 /usr/share/games/fs2_open/fs2_open 00aa3000-023b3000 rw-p 00000000 00:00 0 [heap] 40b75000-40bd4000 rw-p 00000000 00:0d 3481 /dev/zero 41514000-41516000 rwxp 00000000 00:0d 3481 /dev/zero 7f239f94d000-7f239fb4d000 rw-s 79491000 00:0d 8304 /dev/nvidia0 7f239fb4d000-7f239fc4d000 rw-s 62bd5000 00:0d 8304 /dev/nvidia0 7f239fc4d000-7f239fc4e000 rw-s fac08000 00:0d 8304 /dev/nvidia0 7f239fc4e000-7f239fc8e000 rw-s 794de000 00:0d 8304 /dev/nvidia0 7f239fc8e000-7f239fcf3000 rw-p 00000000 00:00 0 7f239fcf3000-7f239fcf8000 r-xp 00000000 08:03 2736184 /usr/lib64/libXfixes.so.3.1.0 7f239fcf8000-7f239fef7000 ---p 00005000 08:03 2736184 /usr/lib64/libXfixes.so.3.1.0 7f239fef7000-7f239fef8000 r--p 00004000 08:03 2736184 /usr/lib64/libXfixes.so.3.1.0 7f239fef8000-7f239fef9000 rw-p 00005000 08:03 2736184 /usr/lib64/libXfixes.so.3.1.0 7f239fef9000-7f239ff02000 r-xp 00000000 08:03 2737816 /usr/lib64/libXcursor.so.1.0.2 7f239ff02000-7f23a0102000 ---p 00009000 08:03 2737816 /usr/lib64/libXcursor.so.1.0.2 7f23a0102000-7f23a0103000 r--p 00009000 08:03 2737816 /usr/lib64/libXcursor.so.1.0.2 7f23a0103000-7f23a0104000 rw-p 0000a000 08:03 2737816 /usr/lib64/libXcursor.so.1.0.2 7f23a0104000-7f23a02f3000 r--p 00000000 08:03 2802035 /usr/lib64/locale/locale-archive 7f23a02f3000-7f23a02fb000 r-xp 00000000 08:03 2737620 /usr/lib64/libXrandr.so.2.2.0 7f23a02fb000-7f23a04fa000 ---p 00008000 08:03 2737620 /usr/lib64/libXrandr.so.2.2.0 7f23a04fa000-7f23a04fb000 r--p 00007000 08:03 2737620 /usr/lib64/libXrandr.so.2.2.0 7f23a04fb000-7f23a04fc000 rw-p 00008000 08:03 2737620 /usr/lib64/libXrandr.so.2.2.0 7f23a04fc000-7f23a0505000 r-xp 00000000 08:03 2737959 /usr/lib64/libXrender.so.1.3.0 7f23a0505000-7f23a0704000 ---p 00009000 08:03 2737959 /usr/lib64/libXrender.so.1.3.0 7f23a0704000-7f23a0705000 r--p 00008000 08:03 2737959 /usr/lib64/libXrender.so.1.3.0 7f23a0705000-7f23a0706000 rw-p 00009000 08:03 2737959 /usr/lib64/libXrender.so.1.3.0 7f23a0706000-7f23a0707000 ---p 00000000 00:00 0 7f23a0707000-7f23a0f07000 rwxp 00000000 00:00 0 7f23a0f07000-7f23a0f08000 ---p 00000000 00:00 0 7f23a0f08000-7f23a1708000 rwxp 00000000 00:00 0 7f23a1708000-7f23a1713000 r-xp 00000000 08:03 8437814 /lib64/libnss_files-2.11.2.so 7f23a1713000-7f23a1913000 ---p 0000b000 08:03 8437814 /lib64/libnss_files-2.11.2.so 7f23a1913000-7f23a1914000 r--p 0000b000 08:03 8437814 /lib64/libnss_files-2.11.2.so 7f23a1914000-7f23a1915000 rw-p 0000c000 08:03 8437814 /lib64/libnss_files-2.11.2.so 7f23a1915000-7f23a191f000 r-xp 00000000 08:03 8437872 /lib64/libnss_nis-2.11.2.so 7f23a191f000-7f23a1b1e000 ---p 0000a000 08:03 8437872 /lib64/libnss_nis-2.11.2.so 7f23a1b1e000-7f23a1b1f000 r--p 00009000 08:03 8437872 /lib64/libnss_nis-2.11.2.so 7f23a1b1f000-7f23a1b20000 rw-p 0000a000 08:03 8437872 /lib64/libnss_nis-2.11.2.so 7f23a1b20000-7f23a1b35000 r-xp 00000000 08:03 8437810 /lib64/libnsl-2.11.2.so 7f23a1b35000-7f23a1d34000 ---p 00015000 08:03 8437810 /lib64/libnsl-2.11.2.so 7f23a1d34000-7f23a1d35000 r--p 00014000 08:03 8437810 /lib64/libnsl-2.11.2.so 7f23a1d35000-7f23a1d36000 rw-p 00015000 08:03 8437810 /lib64/libnsl-2.11.2.so 7f23a1d36000-7f23a1d38000 rw-p 00000000 00:00 0 7f23a1d38000-7f23a1d3f000 r-xp 00000000 08:03 8437873 /lib64/libnss_compat-2.11.2.so 7f23a1d3f000-7f23a1f3e000 ---p 00007000 08:03 8437873 /lib64/libnss_compat-2.11.2.so 7f23a1f3e000-7f23a1f3f000 r--p 00006000 08:03 8437873 /lib64/libnss_compat-2.11.2.so 7f23a1f3f000-7f23a1f40000 rw-p 00007000 08:03 8437873 /lib64/libnss_compat-2.11.2.so 7f23a1f73000-7f23a20e5000 rw-p 00000000 00:00 0 7f23a20e5000-7f23a21ae000 r-xp 00000000 08:03 2737466 /usr/lib64/libasound.so.2.0.0 7f23a21ae000-7f23a23ad000 ---p 000c9000 08:03 2737466 /usr/lib64/libasound.so.2.0.0 7f23a23ad000-7f23a23b3000 r--p 000c8000 08:03 2737466 /usr/lib64/libasound.so.2.0.0 7f23a23b3000-7f23a23b5000 rw-p 000ce000 08:03 2737466 /usr/lib64/libasound.so.2.0.0 7f23a23b5000-7f23a23ba000 r-xp 00000000 08:03 2737562 /usr/lib64/libXdmcp.so.6.0.0 7f23a23ba000-7f23a25b9000 ---p 00005000 08:03 2737562 /usr/lib64/libXdmcp.so.6.0.0 7f23a25b9000-7f23a25ba000 r--p 00004000 08:03 2737562 /usr/lib64/libXdmcp.so.6.0.0 7f23a25ba000-7f23a25bb000 rw-p 00005000 08:03 2737562 /usr/lib64/libXdmcp.so.6.0.0 7f23a25bb000-7f23a25bd000 r-xp 00000000 08:03 2737678 /usr/lib64/libXau.so.6.0.0 7f23a25bd000-7f23a27bd000 ---p 00002000 08:03 2737678 /usr/lib64/libXau.so.6.0.0 7f23a27bd000-7f23a27be000 r--p 00002000 08:03 2737678 /usr/lib64/libXau.so.6.0.0 7f23a27be000-7f23a27bf000 rw-p 00003000 08:03 2737678 /usr/lib64/libXau.so.6.0.0 7f23a27bf000-7f23a27dc000 r-xp 00000000 08:03 2738931 /usr/lib64/libxcb.so.1.1.0 *** Additionaly, I got the following messages in the console when starting the launcher: AL lib: alcConfig.c:149: config parse error: option without a value: "(define" AL lib: alcConfig.c:149: config parse error: option without a value: "(define" AL lib: alcConfig.c:149: config parse error: option without a value: "(define" gamedir: /opt/babylon Below is the packages installed with the USE flags: dragon ~ # emerge -av fs2_open These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] app-arch/unrar-3.9.7 138 kB [0] [ebuild N ] games-action/fs2_launcher-152 USE="babylon -freespace2" 0 kB [1] [ebuild N ] games-action/babylon-mediavps-3.4.2 USE="campaigns yal" 1,549,187 kB [1] [ebuild N ] games-action/fs2_open-3.6.10 USE="babylon inferno speech -freespace2" 11,027 kB [1]
(In reply to comment #47) > After performing a digest on all ebuilds, emerge is able to install everything, > but when I start the launcher, I am not able to choose the location of the > fs2_open executable. fs2_open link was in /opt/<mod>/ browse with yal and select fs2_open link for mod you selected (/opt/babylon/fs2_open for babylon) -writing by hand on yal could work- Configure mod (select babylon mod and video settings) with yal as you want and hit 'Apply->Run' for the first time. If all worked, next time you want to play could launch the game from the gnome menu or from command line like this, $ fs2_open ($ denotes linux user shell) Yal it's used for the first time you setup a mod or want to change something. =>Unrecognized command line parameter "-jpgtga". Ignoring... // Ignore this =>The launcher must be in the same directory as the binary you are trying to use. Trying to find binary in the launcher directory instead. // Ignore this too hope it helps, if you start a server maybe could play a little :) i'm testing 3D sound form time to time (sorry for my very bad english)
(In reply to comment #48) > (In reply to comment #47) > > After performing a digest on all ebuilds, emerge is able to install everything, > > but when I start the launcher, I am not able to choose the location of the > > fs2_open executable. > > fs2_open link was in /opt/<mod>/ > browse with yal and select fs2_open link for mod you selected > (/opt/babylon/fs2_open for babylon) -writing by hand on yal could work- > Configure mod (select babylon mod and video settings) with yal as you want and > hit 'Apply->Run' for the first time. > This is what I do and leads me to the buffer overflow message shown in my comment. Beside I am not able to change the edit bar content. For the record, I am using KDE and my graphic chipset is an NVIDIA GeForce 8800 GTX. > If all worked, next time you want to play could launch the game from the gnome > menu or from command line like this, > $ fs2_open > ($ denotes linux user shell) > > Yal it's used for the first time you setup a mod or want to change something. > > =>Unrecognized command line parameter "-jpgtga". Ignoring... // Ignore this > =>The launcher must be in the same directory as the binary you are trying to > use. Trying to find binary in the launcher directory instead. // Ignore this > too > > hope it helps, if you start a server maybe could play a little :) > i'm testing 3D sound form time to time (sorry for my very bad english) >
(In reply to comment #44) > Created an attachment (id=232121) [details] > New ebuilds for mediavps from freespace2 and TBP and fs2_open.3.6.10 and > launcher > > Can't find icon for launcher (there is a .ico file but no .png) I couldn't find > a way for having several mods installed because config files on home dir; > fs2_open ebuild will force 1 mod install (but you could install all mediavps > and launcher) > Please test it. > May I do a few suggestion: 1. Create the following package hierarchy: - freespace_open-meta --> will install everything related to freespace open in the same way as does gnom-meta and kde-meta for gnome and KDE and depends on the following packages in that order of build: a. fso-core --> the source code to create the binary. no dependency on any mod b. fso-launcher --> the launcher c. other packages that provides tools for freespace d. one package for each mod 2. Install all MODs into /opt/freespace_open/mod/ easier to find them. That would give the following directory structure: /opt/freespace_open/mod/babylon/ /opt/freespace_open/mod/<mod2>/ /opt/freespace_open/mod/<mod3>/ etc. 3. Provide a script that will allow users in the games group to create the symlink to all the installed mods in directory ~/.fs2_open/. Of course there is maybe dependencies and constraints that I am not aware of and maybe some suggestions must be adapted or are totally impossible. Hope this will help.
(In reply to comment #50) Changes you proposed requires updating all ebuilds, i only added babylon ebuild, in the line of freespace ebuild (which takes mediavps from original cds of the game -complex ebuild if I remember well-) But you could test your setup if own such game cds. > 3. Provide a script that will allow users in the games group to create the > symlink to all the installed mods in directory ~/.fs2_open/. > > > Of course there is maybe dependencies and constraints that I am not aware of > and maybe some suggestions must be adapted or are totally impossible. > > Hope this will help. > There is no way (at fs2_open-3.6.10 date) for setting up severals mod working together, this is because config file on ~/.fs2_open is shared for all mods. Yal developer suggest me register here (http://www.hard-light.net/forums/index.php?topic=68413.20) to contribute ideas, but I can't post to that forum. I'm using gnome peacefully over nvidia geforce 6200. Are you using oficial nvidia drivers? I'm using x11-drivers/nvidia-drivers-195.36.31 have you tried another game using opengl? (like jag or zaz)
Nice, my little project (YAL) is getting it's way to gentoo :-) Anyway, I was pointed to this bug by fs2_open forums. Shortly about the issue: Yes, ~/.fs2_open is hardcoded into the binary. For years I've patched fs2_open builds used for different TC's I played to use a different dir. Same with YAL, different builds. But on the other hand I've never installed fs2_open to /usr hierarchy. I'll have a detailed look at this thread when I get from work and comment some more. I was going to sit to YAL and apply some little suggestions I got recently anyway. This issue might as well be the kick to do that. One short note, you seem to call things like Babylon Project mods. That's misleading and improper. Mod is something that gets installed inside freespace and is selected by -mod switch (or with YAL for that matter). The Babylon Project is a total conversion and it got mods by its own. It does not uses assets from fs2_open. Same with Wing Commander saga, Beyond the Red Line demo or Diaspora (when it gets released). Mods are usually just new missions based on the assets of the current game. Taking this into consideration the only thing you could actually put into freespace core would be the binary. Because that's the _only_ thing TBP and fs2_open have in common. And seeing that some TC's like to put some specific requirements for fs2_open versions it might be wiser to just create completely separate packages for fs2_open, TBP, diaspora etc. The last one for instance is going to have some custom engine modifications that are going to be released for Diaspora then for fs2_open. So having common binary in this case might not work at all. And this would solve the ~/.fs2_open problem as well cause every binary could be patched to use a different directory.
Errata: "The last one for instance is going to have some custom engine modifications that are going to be released for Diaspora _earlier_ then for fs2_open."
As both a linux user running gentoo on my server, and the head of the SCP, maybe I can offer some assistance here? I wasn't aware there was a Freespace ebuild in portage. I'm sure there's some mutual benefit to be gained here as we have a serious dearth of coders experienced with Linux. Also, I finally got around to uploading the 3.6.12 source code export from the 3.6.12 branch. http://swc.fs2downloads.com/builds/fs2_open_3_6_12_src.tgz If there's any questions I can answer please ask away.
(In reply to comment #51) > (In reply to comment #50) > Changes you proposed requires updating all ebuilds, i only added babylon > ebuild, in the line of freespace ebuild (which takes mediavps from original cds > of the game -complex ebuild if I remember well-) But you could test your setup > if own such game cds. > > > 3. Provide a script that will allow users in the games group to create the > > symlink to all the installed mods in directory ~/.fs2_open/. > > > > > > Of course there is maybe dependencies and constraints that I am not aware of > > and maybe some suggestions must be adapted or are totally impossible. > > > > Hope this will help. > > > There is no way (at fs2_open-3.6.10 date) for setting up severals mod working > together, this is because config file on ~/.fs2_open is shared for all mods. > Yal developer suggest me register here > (http://www.hard-light.net/forums/index.php?topic=68413.20) to contribute > ideas, but I can't post to that forum. > > I'm using gnome peacefully over nvidia geforce 6200. Are you using oficial > nvidia drivers? I'm using x11-drivers/nvidia-drivers-195.36.31 > have you tried another game using opengl? (like jag or zaz) > I am using the same version as you and I have several games using openGL like quake: Enemy Territory or Warzone 2100.
(In reply to comment #52) > Nice, my little project (YAL) is getting it's way to gentoo :-) > > Anyway, I was pointed to this bug by fs2_open forums. Shortly about the issue: > > Yes, ~/.fs2_open is hardcoded into the binary. For years I've patched fs2_open > builds used for different TC's I played to use a different dir. Same with YAL, > different builds. But on the other hand I've never installed fs2_open to /usr > hierarchy. I'll have a detailed look at this thread when I get from work and > comment some more. > Now it is clearer, thanks for the explanation. > I was going to sit to YAL and apply some little suggestions I got recently > anyway. This issue might as well be the kick to do that. > > One short note, you seem to call things like Babylon Project mods. That's > misleading and improper. Mod is something that gets installed inside freespace > and is selected by -mod switch (or with YAL for that matter). > The Babylon Project is a total conversion and it got mods by its own. It does > not uses assets from fs2_open. Same with Wing Commander saga, Beyond the Red > Line demo or Diaspora (when it gets released). Mods are usually just new > missions based on the assets of the current game. > > Taking this into consideration the only thing you could actually put into > freespace core would be the binary. Because that's the _only_ thing TBP and > fs2_open have in common. And seeing that some TC's like to put some specific > requirements for fs2_open versions it might be wiser to just create completely > separate packages for fs2_open, TBP, diaspora etc. The last one for instance is > going to have some custom engine modifications that are going to be released > for Diaspora then for fs2_open. So having common binary in this case might not > work at all. And this would solve the ~/.fs2_open problem as well cause every > binary could be patched to use a different directory. >
I will try to summarize my problem so far After installing fs2_open, with all the use flag except freespace2 (I can't find those damn CDs :'( ), When I start TBP with the launcher or by running the command fs2_open I got the following error (only the first lines are showed see comment #47 for a complete log): *** buffer overflow detected ***: /opt/babylon/fs2_open terminated ======= Backtrace: ========= /lib/libc.so.6(__fortify_fail+0x37)[0x7f23a598b427] /lib/libc.so.6(+0xe8150)[0x7f23a5989150] /lib/libc.so.6(+0xe6f3d)[0x7f23a5987f3d] Concerning this problem should I better see with the TBP maintainers or could you help me M. Gordon? After some investigation I have noted the following: - The path to the babylon directory seems to be hardcoded in YAL, modifying launcher6.ini change nothing in the interface :(. Aditionally I can't change anything in the edit bar of the GUI. - The executable /usr/games/bin/fs2_launcher is a link to /opt/babylon/fs2_launcher. - There is an fs2_open executable both in /opt/babylon and in /usr/games/bin/ Is it really wise to do things that way? If I am correct inferno is a MOD but also a set of patches to improve fs2_open, does the use flag only concerns the patches or does the MOD installed also? If the MOD is installed too where are the data and how to start it?
(In reply to comment #57) > *** buffer overflow detected ***: /opt/babylon/fs2_open terminated > ======= Backtrace: ========= > /lib/libc.so.6(__fortify_fail+0x37)[0x7f23a598b427] > /lib/libc.so.6(+0xe8150)[0x7f23a5989150] > /lib/libc.so.6(+0xe6f3d)[0x7f23a5987f3d] No idea about this (I'm packager only) would you like to check your fs2_open Manifest with mine? (maybe code was changed and needing patches) But I get it working on x86 (no amd64 as you) Please could you told me if your amd64 setup is 'pure' or 32bit compliant? I remember there is two ways of setting up a 64bit system. > After some investigation I have noted the following: > > - The path to the babylon directory seems to be hardcoded in YAL, modifying > launcher6.ini change nothing in the interface :(. Aditionally I can't change > anything in the edit bar of the GUI. > > - The executable /usr/games/bin/fs2_launcher is a link to > /opt/babylon/fs2_launcher. > > - There is an fs2_open executable both in /opt/babylon and in /usr/games/bin/ fs2_open on /opt/babylon is a link to bin on /usr/games/bin > Is it really wise to do things that way? > Please feel free to update ebuild, I only could get it working like this :) ANd worked freespace2 and TBP, I'm thinking Wing Commander Saga could be added to this setup. > If I am correct inferno is a MOD but also a set of patches to improve fs2_open, TBP take advantage on inferno (as SCP people told me time ago) > does the use flag only concerns the patches or does the MOD installed also? inferno if a configure option on fs2_open (no idea if are patches only)
(In reply to comment #54) > As both a linux user running gentoo on my server, and the head of the SCP, > maybe I can offer some assistance here? Please, could you told me if fs2_open could be built on 64bits system? > Also, I finally got around to uploading the 3.6.12 source code export from the > 3.6.12 branch. > > http://swc.fs2downloads.com/builds/fs2_open_3_6_12_src.tgz > Nice :) thanks you! Next time I rebuild my system will look for mediavps and I giving it a try.
Nice to see you again Mr. Havner ;)
(In reply to comment #58) > (In reply to comment #57) > > *** buffer overflow detected ***: /opt/babylon/fs2_open terminated > > ======= Backtrace: ========= > > /lib/libc.so.6(__fortify_fail+0x37)[0x7f23a598b427] > > /lib/libc.so.6(+0xe8150)[0x7f23a5989150] > > /lib/libc.so.6(+0xe6f3d)[0x7f23a5987f3d] > > No idea about this (I'm packager only) would you like to check your fs2_open > Manifest with mine? (maybe code was changed and needing patches) > But I get it working on x86 (no amd64 as you) Please could you told me if your > amd64 setup is 'pure' or 32bit compliant? I remember there is two ways of > setting up a 64bit system. > Here is the content of my Manifest for fs2_open after the digest, as you can see it misses some entry from the orignal one you provide: DIST fs2_open_3_6_10.tgz 11291429 RMD160 a154571dcfd7e962f94e84c293e43d18181778b3 SHA1 ae54a9f5bf83cd89268f4f9a5e8031d9084cf0d3 SHA256 cf1533c566f4476cb6bfc15d3e657fd29fdb0bbba7423d804d73063d1e9a5248 EBUILD fs2_open-3.6.10.ebuild 2718 RMD160 3e5498be63c9ef8d89a22fa9fe39a21b0ae755c3 SHA1 40ce535f0302757ade05e514510574d13db409a8 SHA256 356ee452d53ead335cc7c2b4e125b7053377556f241119514d2b667c867b12d3 Concerning the 64 bit stuff, some application are compile in 32 bit due to some compatibility issues (I remind of firefox due to some plugins), else all the other applications are normally build in 64 bit mode. > > After some investigation I have noted the following: > > > > - The path to the babylon directory seems to be hardcoded in YAL, modifying > > launcher6.ini change nothing in the interface :(. Aditionally I can't change > > anything in the edit bar of the GUI. > > > > - The executable /usr/games/bin/fs2_launcher is a link to > > /opt/babylon/fs2_launcher. > > > > - There is an fs2_open executable both in /opt/babylon and in /usr/games/bin/ > > fs2_open on /opt/babylon is a link to bin on /usr/games/bin > > > Is it really wise to do things that way? > > > Please feel free to update ebuild, I only could get it working like this :) > ANd worked freespace2 and TBP, I'm thinking Wing Commander Saga could be added > to this setup. > > > If I am correct inferno is a MOD but also a set of patches to improve fs2_open, > > TBP take advantage on inferno (as SCP people told me time ago) > > > does the use flag only concerns the patches or does the MOD installed also? > > inferno if a configure option on fs2_open (no idea if are patches only) > Then I guess it is the patch only as far as I have read on the FSO site.
(In reply to comment #59) > (In reply to comment #54) > > As both a linux user running gentoo on my server, and the head of the SCP, > > maybe I can offer some assistance here? > > Please, could you told me if fs2_open could be built on 64bits system? > > > Also, I finally got around to uploading the 3.6.12 source code export from the > > 3.6.12 branch. > > > > http://swc.fs2downloads.com/builds/fs2_open_3_6_12_src.tgz > > > > Nice :) thanks you! Next time I rebuild my system will look for mediavps and I > giving it a try. > M. Dominguez, M. Pawelczyk advise to include the SCP sources with each Total Conversion to avoid source code conflict and allow having multiple instances of fs2_open running on the machine. did you plan for the next ebuilds to apply that suggestion? I will check if that can be easily done with the current version of fs2_open.
Good news, with the freespace2 useflag instead of the babylon one, I am able to play and the freespace2-data ebuild is working just fine. I have played a few mission of the campaign so far without any problem. Anyway during my tests, I notice that player's profiles and stats are deleted when unmerging fs2_open. Shouldn't those data normally located in ~/.fs2_open?
(In reply to comment #63) > Good news, with the freespace2 useflag instead of the babylon one, I am able to > play and the freespace2-data ebuild is working just fine. I have played a few > mission of the campaign so far without any problem. > > Anyway during my tests, I notice that player's profiles and stats are deleted > when unmerging fs2_open. Shouldn't those data normally located in ~/.fs2_open? Should be. Is on Mac at least (well, ~/Library/FS2_Open/). Also, I'd like to point out that there is an initiative to revamp some chunks of the engine to make them more cross-platform and multiple-TC friendly. IssMneur and kkmic on the forums have been working on a cross platform launcher/installer to replace the various ones that have been written up to this point. One of the first things to do is get Windows to start using proper data storage locations, eliminate any writing to the binary or game data folders, allow the binary to be installed separately from the game data and not have to be run with the CWD set to the game data, etc. Once we have the launcher/installer, it will be the recommended means to install the data on most platforms, although I don't necessarily want to eliminate support for installing various things from the various package managers on Gentoo, Ubuntu, etc. Ensuring that the two behaved together then would be necessary. The idea would be something similar to Steam (no DRM of course!) without all the bloat, just a way to install the various mods, campaigns, track dependencies, etc across various platforms. This will of course be the biggest help to Windows and OS X but we'd like for it to function on Linux as well. We're also looking into supporting Solaris x86 and Sparc64, which might mean we could get Linux/Sparc64 support as well, if there's any interest. Anyway, if anyone has any interest in tinkering with the codebase in ways that should make it more *nix friendly, please don't keep them to just Gentoo. Feel free to drop by and make some comments/suggestions at our Cross Platform forum http://www.hard-light.net/forums/index.php?board=113.0
Hi, I am Iss Mneur from the HLP board. @Roland Everaert: According to the 'full' log that you linked to, your issue is caused by you having the flag '-jpgtga' in your cmdline_fso.cfg file (it is in TC/data and/or $HOME/.fs2_open/data/cmdline_fso.cfg). It should be cleared by any of the launchers but not every launcher checks, sets, and/or clears both (mostly because they don't realize that FSO *will* check both). Also, every time FSO dumps a stack trace it will write to the console why it just had to bail. If it doesn't compile the build 'autogen.sh --enable-debug' and the reason is written to fs2_open.log, if it doesn't make sense you can post on the HLP support board http://www.hard-light.net/forums/index.php?board=151.0 ------------------ Regarding TBP specificly, the version that is publicly available *will not* work with current (3.6.10 and 3.6.12) binaries because of changes in the way FSO parses and otherwise handles the data. This means in order to use a new binary you need to have the Zarthas mod installed, what it is and how it works can be found here http://www.hard-light.net/forums/index.php?topic=71789.0 Yes this is a bad state of affairs, but I am not going to discuss it here, if you want to know the gory details of this arrangement you can look in TBP board on HLP. ---------------------------- I would like to expand on what Cliff Gordon had to say about wxLauncher. The launcher/installer that he describes is still in the drawing board stage, you can read more about what is planned here http://www.hard-light.net/forums/index.php?topic=69016.0 ---------------------------- In light of how long it will take wxLauncher and FSO to be what you need, I suggest that the best (less trouble, based on my experience with the platform code) way to support multiple TCs at this time is have customized(1) copies of both the launcher and the FSO binary that you install into the TC data directory. The reason for this is that FSO really hasn't shed (all of) its windows legacy (we are working on it, but it will take time as FSO makes a lot of assumptions regarding where the binary is in relation to the data). I would suggest that you use YAL at this time because it makes the suggest install pattern more straight forward, wxLauncher (even in it current, simple form) complicates what you are trying to do. 1) The customization that I am referring to is changing the $HOME subdirectory in both the binary and the launcher, as we previously suggested. According to Havner on HLP how to customize YAL to work with a custom FSO is in the YAL readme, apparently different qmake options. To customize FSO for this arrangement, look in osregistry_unix.cpp (though I would suggest just grepping for '.fs2_open' and change them all because the directory is referred to at least once in a user visible message). Remember that a modified YAL requires a modifed FSO for this to actually work correctly.
(In reply to comment #65) > Regarding TBP specificly, the version that is publicly available *will not* > work with current (3.6.10 and 3.6.12) binaries because of changes in the way > FSO parses and otherwise handles the data. This means in order to use a new > binary you need to have the Zarthas mod installed, what it is and how it works > can be found here http://www.hard-light.net/forums/index.php?topic=71789.0 Zarthas its included in current babylon ebuild :) > 1) The customization that I am referring to is changing the $HOME subdirectory > in both the binary and the launcher, as we previously suggested. According to > Havner on HLP how to customize YAL to work with a custom FSO is in the YAL > readme, apparently different qmake options. To customize FSO for this > arrangement, look in osregistry_unix.cpp (though I would suggest just grepping > for '.fs2_open' and change them all because the directory is referred to at > least once in a user visible message). Remember that a modified YAL requires a > modifed FSO for this to actually work correctly. Please is the file you talking about this? fs2_open_3_6_10/code/osapi/osregistry_unix.cpp grep output: char *Osreg_user_dir = ".fs2_open"; It's very easy patching that line on sources to any value before compiling (I can't find same file in compiled game) @Havner,@CLiff: Maybe we could use a environment variable which could be filled with correct value from YAL (fixed when selecting mod)? like this: char *Osreg_user_dir = ".$fs2_open_mod"; ?
Env variable could be used (getenv() is actually used for that, $ in C code wont achieve that) but that would provide problems when you actually run the game binary by hand (without a launcher) and this is a thing that can't get broken. I still think that patching the launcher and a binary is the simplest solution when you should have them separate for each TC anyway.
(In reply to comment #66) > (In reply to comment #65) > > Regarding TBP specificly, the version that is publicly available *will not* > > work with current (3.6.10 and 3.6.12) binaries because of changes in the way > > FSO parses and otherwise handles the data. This means in order to use a new > > binary you need to have the Zarthas mod installed, what it is and how it works > > can be found here http://www.hard-light.net/forums/index.php?topic=71789.0 > > Zarthas its included in current babylon ebuild :) > > > 1) The customization that I am referring to is changing the $HOME subdirectory > > in both the binary and the launcher, as we previously suggested. According to > > Havner on HLP how to customize YAL to work with a custom FSO is in the YAL > > readme, apparently different qmake options. To customize FSO for this > > arrangement, look in osregistry_unix.cpp (though I would suggest just grepping > > for '.fs2_open' and change them all because the directory is referred to at > > least once in a user visible message). Remember that a modified YAL requires a > > modifed FSO for this to actually work correctly. > Please is the file you talking about this? > fs2_open_3_6_10/code/osapi/osregistry_unix.cpp > > grep output: char *Osreg_user_dir = ".fs2_open"; > > It's very easy patching that line on sources to any value before compiling (I > can't find same file in compiled game) > I have also found this in version 3.6.10 and 3.6.12: code/freespace2/freespace.cpp: fprintf(stderr, "(edit ~/.fs2_open/fs2_open.ini to change from default resolution)\n"); I will try to modify the ebuild I am working on for TBP to modify those 2 lines and modify YAL. > @Havner,@CLiff: Maybe we could use a environment variable which could be filled > with correct value from YAL (fixed when selecting mod)? > > like this: char *Osreg_user_dir = ".$fs2_open_mod"; ? >
(In reply to comment #68) > (In reply to comment #66) > > (In reply to comment #65) > > > Regarding TBP specificly, the version that is publicly available *will not* > > > work with current (3.6.10 and 3.6.12) binaries because of changes in the way > > > FSO parses and otherwise handles the data. This means in order to use a new > > > binary you need to have the Zarthas mod installed, what it is and how it works > > > can be found here http://www.hard-light.net/forums/index.php?topic=71789.0 > > > > Zarthas its included in current babylon ebuild :) Oh, okay. I haven't actually read the ebuilds. > > > > > 1) The customization that I am referring to is changing the $HOME subdirectory > > > in both the binary and the launcher, as we previously suggested. According to > > > Havner on HLP how to customize YAL to work with a custom FSO is in the YAL > > > readme, apparently different qmake options. To customize FSO for this > > > arrangement, look in osregistry_unix.cpp (though I would suggest just grepping > > > for '.fs2_open' and change them all because the directory is referred to at > > > least once in a user visible message). Remember that a modified YAL requires a > > > modifed FSO for this to actually work correctly. > > Please is the file you talking about this? > > fs2_open_3_6_10/code/osapi/osregistry_unix.cpp > > > > grep output: char *Osreg_user_dir = ".fs2_open"; > > > > It's very easy patching that line on sources to any value before compiling (I > > can't find same file in compiled game) > > > > I have also found this in version 3.6.10 and 3.6.12: > > code/freespace2/freespace.cpp: fprintf(stderr, "(edit > ~/.fs2_open/fs2_open.ini to change from default resolution)\n"); > > I will try to modify the ebuild I am working on for TBP to modify those 2 lines > and modify YAL. Yes, that appears to be it, I thought there were more instances of '.fs2_open' in the code, we may have fixed them to use "Osreg_user_dir". > > > @Havner,@CLiff: Maybe we could use a environment variable which could be filled > > with correct value from YAL (fixed when selecting mod)? > > > > like this: char *Osreg_user_dir = ".$fs2_open_mod"; ? > > > I agree with Lukasz, while using an environment variable would be great, it will prevent FSO from being run without the launcher, so way that will require the least amount of modification of FSO's documentation would be to just provide the customized binary for each TC.
(In reply to comment #69) > I agree with Lukasz, while using an environment variable would be great, it > will prevent FSO from being run without the launcher, so way that will require > the least amount of modification of FSO's documentation would be to just > provide the customized binary for each TC. Currently, games-action/fs2_open-3.6.10 having babylon and freespace2 useflags, and install this file /usr/games/bin/fs2_open which it's a script for launching fs2_open binary (/usr/share/games/fs2_open/fs2_open currently) this script could be customized in postinstall time (I think) for setting up env variables for each mod. Each mod would be called differently: fs2_open_babylon and fs2_open_freespace2 so this setup could work. Actual script is: (merged with babylon useflag enabled) YAL would setup him env variable when selecting mod. Script is like this --- #!/bin/sh cd "/opt/babylon" if [ -n "" ] ; then if [ "${LD_LIBRARY_PATH+set}" = "set" ] ; then export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:" else export LD_LIBRARY_PATH="" fi fi exec /usr/share/games/fs2_open/fs2_open "$@" -- So could share one binary patching this script. Please what do you thing about this approach?
I don't get why are you try to stick to the idea of one binary that much. A situation taken from life: Original TBP, shipped with SCP 3.6.9, works great. 3.6.10 is released, try to use it on TBP, one mission becomes impossible to finish. It had a bug that did not trigger on 3.6.9, it did on 3.6.10 (it had stricter mission file checks). Zathras was not released at this point. Future situation (take from HLP forums, this might be inacurate now, but still, is not impossible): Diaspora is supposed to be release with some build inbetween 3.6.12 and 3.6.14. You'd need this build to be able to use all its features. Are you going to force FS2_open users to use the same build? Which may have other issues that were not tested at this point with FS2 data? I'd do this this way, listing packages: tbp-3.6.12 (R: >= tbp-zathras-2.0) tbp-data-4.3b tbp-zathras-2.0 tbp-yal-0.13 fs2_open-3.6.12 fs2_open-data (either stub or requires windows during emerge data) fs2_open-mediavps-3.6.12 fs2_open-yal-0.13 etc...
I haven't get into fs2_open yet (only played FS1 using the icculus port) but if different mods work better with particular versions, maybe slotting would be a good idea.
Slotting packages that on some occasions come from the same version of source? Misleading in my opinion. Unleashed you can slot by some tag, not a number, but never seen that in gentoo.
I meant "unless", sorry mobile dictionary.
(In reply to comment #71) > I don't get why are you try to stick to the idea of one binary that much. There is no problem with fs2_3.6.9 and fs2_3.6.10 on same system, because gentoo portage does support multislot (which I have no experience) But I think it's a bad thing patching same version for several mods, maybe with several ebuilds for same software version? (anybody would port TBP to 3.6.1x?) With your setup, it needing a meta-ebuild (like Roland Everaert proposed) for multislot fs2_open. In all the ways if diaspora and freespace2 could use same version of fs2_open we would fall in same inconsistence :S (I think) Maybe it would be better speaking this with a portage commiter (there is gentoo ebuild writing standards) if we want to see this ebuild on portage :S
Maybe I missed something, I didn't think there would be the same version from different sources. I believe you can put text into the SLOT variable (repoman doesn't complain) but I think the ebuilds would have to have different -r versions because obviously they can't have exactly the same filename. But if we're talking about different sources as well, it sounds very few mods (are there many?) share an engine, which would make this a bit pointless.
During some time from now on you can have a situation where at some point all the TCs will use the same version, one will use different and every one of those will use a different. Sorry, I don't see how slotting can solve that without some complicated mechanism that will choose a best version based on something. Meta packages are fine, don't see why you have problems with them. And keeping everything as separate as possible is cleaner, you see exactly what version of what component you have. It's also easier to maintain and update. And with different components coming from different groups it's a must if you ask me. That's how it's done in Linux distros.
(In reply to comment #77) > I don't see how slotting can solve that > without some complicated mechanism that will choose a best version based on > something. fs2_meta[babylon,freespace2,WCS] babylon->fs2_open-3.6.9 (required version) patched for using ~/.babylon (SLOT 1) ->mediavps for that fs version freespace2->fs2_open-3.6.10 (SLOT 2) ->mediavps for that WCS ->fs2_open-3.6.10? (I think we can't make SLOT 3 for same fs2_open version) Please, do you understand what I try to say? http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1 "With Portage different versions of a single package can coexist on a system. While other distributions tend to name their package to those versions (like freetype and freetype2) Portage uses a technology called SLOTs. An ebuild declares a certain SLOT for its version. Ebuilds with different SLOTs can coexist on the same system. For instance, the freetype package has ebuilds with SLOT="1" and SLOT="2". "
(In reply to comment #78) > (In reply to comment #77) > > I don't see how slotting can solve that > > without some complicated mechanism that will choose a best version based on > > something. > > fs2_meta[babylon,freespace2,WCS] > babylon->fs2_open-3.6.9 (required version) patched for using ~/.babylon (SLOT > 1) > ->mediavps for that fs version > > freespace2->fs2_open-3.6.10 (SLOT 2) > ->mediavps for that > > WCS ->fs2_open-3.6.10? (I think we can't make SLOT 3 for same fs2_open > version) > Please, do you understand what I try to say? > http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1 > "With Portage different versions of a single package can coexist on a system. > While other distributions tend to name their package to those versions (like > freetype and freetype2) Portage uses a technology called SLOTs. An ebuild > declares a certain SLOT for its version. Ebuilds with different SLOTs can > coexist on the same system. For instance, the freetype package has ebuilds with > SLOT="1" and SLOT="2". " > I am agreeing with the M. Pawelczyk, even if appeling, SLOTs seems to me a mystake, your example with freespace2 and WCS show, if at some point WCS needs some additional patches, you will have to resort on exclusive use flags for that version of fs2_open, download different packages and ensure that the right sources are compile correctly and that the executable is named and copied at the right place. From my point of view, this will be a big mess. Using different packages will ensure that each freespace2 open source instance get the right treatment to be able to play the related TC. Additionally as pointed by M. Gordon and Iss Mneur, the reason we are building the package that way will fade away in the end, so lets keep things simple until FSO is made more cross-platform friendly and a proper launcher is available. Actually, I have created the following packages for TBP: babylon-meta babylon-core-3.4.2 babylon-yal-3.4.2 babylon-mediavps I am finalizing the package for yal. I think I will use the naming scheme of M. Pawelczyk, because mine is misleading. The binary is still not working for me though, but I hope that someone will be able to look deeply at the ebuilds I will submit and find whats wrong. I have tried without the flag -jpgtga but still same result. Hope I can post the ebuilds today.
(In reply to comment #79) Please talk with some gentoo packager here about irc://gentoo/gentoo-sunrise more info here http://www.gentoo.org/proj/en/sunrise/ a gentoo developer would check your ebuild prior comminting to portage post problems you having, maybe somebody could help you a little
(In reply to comment #76) > Maybe I missed something, I didn't think there would be the same version from > different sources. I believe you can put text into the SLOT variable (repoman > doesn't complain) but I think the ebuilds would have to have different -r > versions because obviously they can't have exactly the same filename. But if > we're talking about different sources as well, it sounds very few mods (are > there many?) share an engine, which would make this a bit pointless. > There are two things. 1) Strictly speaking they are all sharing the same engine (WCS, TBP, FS2, and Dispora), but the issue is because a Linux binary (or OSX binary for that matter) uses a directory in $HOME to store config data and the pilot files (among other things), each TC *needs* to have a custom binary that if nothing else changes the value of Osapi_user_dir. 2) The issue outlined above does *not* apply to windows because it stores its data in the games data directory (on windows FSO also requires that the binary is located *in* the game data directory). This means that an officially released binary from the SCP for windows can (normally) be dropped into the TC's data directory and work just fine (except for data parsing differences). The result of the above two issues, it is best to just treat all TCs as separate games (which they are) and not bother trying to share the engine. Because the developers of all the FSO TCs are mostly or entirely Windows users, everything that surrounds FSO is designed that way. Is this an optimal arrangement? No. Will this work well the short term? Yes. Is this discrepancy going to be fixed? Yes, I am working on fixing it because these differences make writing wxLauncher more difficult (especially a wxLauncher that can install and update the game data). Will wxLauncher support this layout when wxLauncher finally gains its ability to install the games? Yes, because treating the TCs as separate games is how it is done on windows, where the majority of our users are, so that layout will automatically be supported. (In reply to comment #79) > The binary is still not working for me though, but I hope that someone will be > able to look deeply at the ebuilds I will submit and find whats wrong. I have > tried without the flag -jpgtga but still same result. It is likely giving you a different error message though (even if the stack trace is the same). Please read the SCP support FAQ (particularly the part about the fs2_open.log): http://www.hard-light.net/forums/index.php?topic=56279.0 If that doesn't resolve the problem, please post in our support board where our "support ninjas" will be able to help you resolve the issue: http://www.hard-light.net/forums/index.php?board=151.0
(In reply to comment #81) > 1) Strictly speaking they are all sharing the same engine (WCS, TBP, FS2, and > Dispora), but the issue is because a Linux binary (or OSX binary for that > matter) uses a directory in $HOME to store config data and the pilot files > (among other things), each TC *needs* to have a custom binary that if nothing > else changes the value of Osapi_user_dir. This has probably been suggested but isn't it easy enough to use some "name" property from each mod to work out a path like ~/.<insert mod name here> ? If there is no such property, maybe use the last part of the data directory path or something?
(In reply to comment #82) > (In reply to comment #81) > > 1) Strictly speaking they are all sharing the same engine (WCS, TBP, FS2, and > > Dispora), but the issue is because a Linux binary (or OSX binary for that > > matter) uses a directory in $HOME to store config data and the pilot files > > (among other things), each TC *needs* to have a custom binary that if nothing > > else changes the value of Osapi_user_dir. > > This has probably been suggested but isn't it easy enough to use some "name" > property from each mod to work out a path like ~/.<insert mod name here> ? If > there is no such property, maybe use the last part of the data directory path > or something? > Sort of. The problem with basing it on the -mod line is that a MOD (normally) should use the same user directory as the full TC (even if there is potential for pilot file corruption (which we are ironing out the fix for)). Also the -mod line does not give the engine any indication of which is the actually current mod just a list of MODs that the engine is using data from. Basing it on the TCs directory could work, but is totally arbitrary (ie. which directory in the path do we use). It also would require some sort of script or launcher to change the working directory of the binary to the TC directory, though on Linux this is required anyway becuase the binary will not do it by itself.
Ok, so if you wanted to use one binary for different TCs, and have it use different .configdata folders for those, and be able to exist outside of the main game data folder, you would have to tell the game somehow where to start right? Now, it could default to .fs2_open, and looking in CWD for the game data, as it currently does, no problem. Let's say you want to support something else besides CWD though. Instead of an ENV var, why not a command line option? A launcher could easily configure the binary that way, no changes to the ENV required, and only a simple script would need to be included that does that for you for a command line solution. Now as far as when to switch to a different .data folder, why not give TCs the ability to somehow tell the engine to use a different folder than the default? Something like mod.ini but that the engine itself actually cares about. A table might be a good place for something like this, or some other file in the /data folder for the game. This would both maintain previous compatibility with fs2_open and allow TCs still being updated to define their own config if they want. Another thing I'd like to do is have the ability to define where mods are located. I'd like to be able to put them in a mods subfolder, or perhaps manage them in a different location altogether. I think wxLauncher could benefit from that, and it would make complicated mod setups better separated from the rest of the data, especially on Windows and even OS X.
(In reply to comment #68) > I will try to modify the ebuild I am working on for TBP to modify those 2 lines > and modify YAL. I'm thinking about and maybe we could patch fs2_open binary post-build? grep showing me 4 occurrences of .fs2_open n fs2_open binary, but with nano editor only find 2. A linux command could do it post build and so we only needing changing end part of current fs2_open ebuild (patch and copu to folder mod as needed) This don't solve several versions of fs2_open installed on current system, but could be done with SLOTing (meta ebuild requires a fs2_open compilation for each mod as I understand; and this make no sense here, I think)
(In reply to comment #85) > (In reply to comment #68) > > > I will try to modify the ebuild I am working on for TBP to modify those 2 lines > > and modify YAL. > I'm thinking about and maybe we could patch fs2_open binary post-build? grep > showing me 4 occurrences of .fs2_open n fs2_open binary, but with nano editor > only find 2. A linux command could do it post build and so we only needing > changing end part of current fs2_open ebuild (patch and copu to folder mod as > needed) I don't get what you are trying to say. Modifying the binary after building it seems rather counter intuitive to me, because if you have the source for the binary why not change the source before you build? > This don't solve several versions of fs2_open installed on current system, but > could be done with SLOTing (meta ebuild requires a fs2_open compilation for > each mod as I understand; and this make no sense here, I think) > But if you are modifying the binary it is no longer a Freespace binary and is now (for example) a Babylon Project binary. They they can't be identical (because of the value of Osapi_user_dir should be changed for each TC). I am not sure why there is this fixation of making FSO share the binaries between the TCs, especially when FSO is *clearly* (from the SCP point of view) not designed for this type of usage. I understand that sharing the binary is the *nix way of doing things, but FSO isn't exactly a *nix optimized program. Of course, you guys can do what ever you want, but we (the SCP) really don't recommend you sharing your FSO binaries between TCs. I just thought of what would be a good use for the SLOT system is, to allow both a 3.6.12 and 3.6.13 (trunk based) binary if they need to troubleshoot something. Possibly having 3.6.10 could also be useful to have around so that if 3.6.12 breaks any MODs then the user would be able to use the older binary to work around the issue.
(In reply to comment #86) > (In reply to comment #85) > > (In reply to comment #68) > > > > > I will try to modify the ebuild I am working on for TBP to modify those 2 lines > > > and modify YAL. > > I'm thinking about and maybe we could patch fs2_open binary post-build? grep > > showing me 4 occurrences of .fs2_open n fs2_open binary, but with nano editor > > only find 2. A linux command could do it post build and so we only needing > > changing end part of current fs2_open ebuild (patch and copu to folder mod as > > needed) > I don't get what you are trying to say. Modifying the binary after building it > seems rather counter intuitive to me, because if you have the source for the > binary why not change the source before you build? > > > This don't solve several versions of fs2_open installed on current system, but > > could be done with SLOTing (meta ebuild requires a fs2_open compilation for > > each mod as I understand; and this make no sense here, I think) > > > But if you are modifying the binary it is no longer a Freespace binary and is > now (for example) a Babylon Project binary. They they can't be identical > (because of the value of Osapi_user_dir should be changed for each TC). > > I am not sure why there is this fixation of making FSO share the binaries > between the TCs, especially when FSO is *clearly* (from the SCP point of view) > not designed for this type of usage. I understand that sharing the binary is > the *nix way of doing things, but FSO isn't exactly a *nix optimized program. > Of course, you guys can do what ever you want, but we (the SCP) really don't > recommend you sharing your FSO binaries between TCs. You're right that we've never been able to recommend that before, but I think my suggestion would just about cover that problem. It's definitely the windows way to have multiple binaries installed, but there's no reason we couldn't move to a common binary shared between various TCs. I think using a config in the TC folder and telling the binary where the TC is located via command line arg like -gamedata would work, and gamedata could default to CWD like it does now. No changes to existing behavior, but would support a whole slew of new behavior. > > I just thought of what would be a good use for the SLOT system is, to allow > both a 3.6.12 and 3.6.13 (trunk based) binary if they need to troubleshoot > something. Possibly having 3.6.10 could also be useful to have around so that > if 3.6.12 breaks any MODs then the user would be able to use the older binary > to work around the issue. That's exactly the purpose of the SLOT system, we could install various SLOT versions, and the TC could specify which ones it is compatible with. This is something I was hoping wxLauncher could do, but I think Portage could handle it in the meantime fairly well.
(In reply to comment #86) > But if you are modifying the binary it is no longer a Freespace binary and is > now (for example) a Babylon Project binary. They they can't be identical > (because of the value of Osapi_user_dir should be changed for each TC). Ebuild I working on allow us setting up one custom binary for each TC, when TCs being able to share binary, few modifications will be done to ebuild. This is a quick and dirty solution for testing several TCs together. Hardcoding over binary allow me changing dir for each TC (without examining source code at all, and avoiding 'sorry I forgot this occurrence') Now babylon takes ~/.babylon2 and freespace2 takes ~/.freespc2 (o character legth name) Hardcoding avoid compiling several times fs2_open binary. One compilation only required, custom binaries was placed on /usr/games/bin/ hardcoded each. > I am not sure why there is this fixation of making FSO share the binaries > between the TCs, especially when FSO is *clearly* (from the SCP point of view) > not designed for this type of usage. This approach don't share binaries until command line parameter added. > I understand that sharing the binary is > the *nix way of doing things, but FSO isn't exactly a *nix optimized program. Could be done with command line as another user has posted. When those time arrives, I will switch back to shared binary. I hope you understand my poor english. > Of course, you guys can do what ever you want, but we (the SCP) really don't > recommend you sharing your FSO binaries between TCs. On windows you copy because normal user can't compile sourcecode, but gentoo don't work like this. On gentoo there is no binaries, and compiling takes time. Several binaries doing same thing is a waste and I totally opposed how gentoo works.
(In reply to comment #77) > I don't see how slotting can solve that without some complicated mechanism that will choose a best version based on something. SLOTs allow us joining two ebuilds based on its version, example: TBP-2.3.0 with fs2_open-3.6.10 and WCS-1.0 with fs2_open-3.6.9. Two compilations are required on fs2_open but about different ebuilds. > Meta packages are fine, don't see why you have problems with them. And keeping > everything as separate as possible is cleaner, you see exactly what version of > what component you have. It's also easier to maintain and update. On gentoo there is a very few meta packages (check it) Only very big components. If you have read last post, you know I'm working custom binaries for each TC. One problem appear now, hardcoded YAL making this directories (I think it's YAL) .babylon2.babylon2.ini/ and .freespc2.freespc2.ini/ And games become disconfigured, how could be corrected? Could you change YAL for using .freespc2 OR .babylon2 based on selected TC? Another workaround? Only one occurrence of .fs2_open was replaced on hardcoding, I don't understand this behavior now. Please, could you teach me how YAL works?
I think you've sufficiently made your case to keep them separate. Although the directory issue could easily be rectified, other issues could potentially make a shared setup awkward at least. It's not like the TCs are minor modifications either, they're worthy of a separate build.
(In reply to comment #90) > I think you've sufficiently made your case to keep them separate. Although the > directory issue could easily be rectified, other issues could potentially make > a shared setup awkward at least. It's not like the TCs are minor modifications > either, they're worthy of a separate build. Not really, we've been encouraging TCs to pick a particular stable release to tie their release to. We don't want TCs to have to go out of their way to make a custom build. I still believe a shared binary setup would benefit in the long run once under the umbrella of an install manager like wxLauncher on all platforms, and I also believe that Portage is more than capable of handling that functionality as is right now. As we've pointed out, there are really only two differences to be taken into account. Where the game data would be, and where the config directory would be. I pointed out suggestions to handle that earlier using one binary, but haven't really seen much a comment to those suggestions in particular. Obviously you _could_ install each TC completely independently, perhaps even have a different launcher for each, but if you don't need to do that, then why do it? And by don't need to, I mean if my suggestions were implemented, not as it is this exact moment.
In an attempt to solve my problem to make TBP working I have opened a thread on HLP forum to get support. The E. ask me to use 3.6.12 instead of 3.6.10 because that release is too old. When using 3.6.12, I got a compilation error. The E. find the problem and provide me 2 option. 1. applying a patch to fix that problem --> can someone gives me a procedure to do that please? 2. strip compilation commands from the -O option that could lead to other potential problem. Can someone explain me how to strip it for the ebuild itself and not system wide? Here is the related thread: http://www.hard-light.net/forums/index.php?topic=72615.new;topicseen#new
(In reply to comment #92) > In an attempt to solve my problem to make TBP working I have opened a thread on > HLP forum to get support. The E. ask me to use 3.6.12 instead of 3.6.10 because > that release is too old. > > When using 3.6.12, I got a compilation error. The E. find the problem and > provide me 2 option. > > 1. applying a patch to fix that problem --> can someone gives me a procedure to > do that please? Please post here The_E patch, I will commit it when 3.6.12 ebuild was done and zathras-2 added to babylon-medivps ebuild. If you want to try, see patch fs2_open_remove_deprecated_duplicate_attachment_gl_ext.patch and read here http://devmanual.gentoo.org/ebuild-writing/functions/src_prepare/epatch/index.html
(In reply to comment #89) > (In reply to comment #77) After testing hardcoded YAL, all was working on not shared setup copying config files from .babylon2.babylon2.ini/* to .babylon2/ If Mr Havner posting a patch o alternate solution for YAL, we could get working short time a no shared setup. Freespace2 worked fine too and separated. meta package will wait to i examine how SLOTs are implemented on ebuilds (next weekend I hope)
Ok, TBH I got a little bit lost in what the behavior is going to be. I still don't like common binary from the reasons I explained earlier but as you prefer. Just please explain me what do you expect of YAL in terms of data dir and config dir and I'll make necessary changes. Cmd line switch or what?
(In reply to comment #95) > Ok, TBH I got a little bit lost in what the behavior is going to be. I still > don't like common binary from the reasons I explained earlier but as you > prefer. Just please explain me what do you expect of YAL in terms of data dir > and config dir and I'll make necessary changes. Cmd line switch or what? > I suppose the biggest difficulty for YAL as a common binary would be how to find where the games are installed. What if you had something like ~/.yal/games/<TCname> text files, that each contained a path to game data? Each TC ebuild could accept a 'yal' USE flag that tells the ebuild to create that file on an emerge. Then, we'd just need to be able to pick a TC like we pick a mod, or run YAL with a command line option that tells it which TC folder you want to use like I want to do with the FSO binary itself. This would all be replaced by the wxLauncher at some point as it will track its installations itself, but YAL is what we have in the meantime. If YAL allowed command line specification of what game data dir to use, the emerge could also either create run scripts for each TC or perhaps shortcuts on a user's desktop or run menu if possible, register it with some sort of Linux game manager, etc. One binary, with just different run scripts to tell it what TC to run. Is that feasible?
This is merely a suggestion but if you don't like the idea of environment variables or command-line arguments, there is a third option. Assuming all the TCs are located in some common place that may be defined at compile-time (like /usr/share/games/fs2_open/tcs) then you could just create symlinks to the fs2_open binary but name them according to the TC. For example, the symlink could be named foobar, so fs2_open would look in /usr/share/games/fs2_open/foobar. You can get this name with something like... arg0 = strdup(argc[0]); name = basename(arg0); free(arg0);
Sorry, that should have been /usr/share/games/fs2_open/tcs/foobar.
(In reply to comment #97) > This is merely a suggestion but if you don't like the idea of environment > variables or command-line arguments, there is a third option. Assuming all the > TCs are located in some common place that may be defined at compile-time (like > /usr/share/games/fs2_open/tcs) then you could just create symlinks to the > fs2_open binary but name them according to the TC. For example, the symlink > could be named foobar, so fs2_open would look in > /usr/share/games/fs2_open/foobar. You can get this name with something like... > > arg0 = strdup(argc[0]); > name = basename(arg0); > free(arg0); > I'm less keen on that because it's less Windows-friendly, although supporting it in addition to command line wouldn't hurt maybe.
(In reply to comment #99) > (In reply to comment #97) > I'm less keen on that because it's less Windows-friendly, although supporting > it in addition to command line wouldn't hurt maybe. > If were are going to do anything, I would rather it be done with command line options, becuase command line options is how I am mostly likely to solve this problem in the future.
(In reply to comment #95) > Ok, TBH I got a little bit lost in what the behavior is going to be. I still > don't like common binary from the reasons I explained earlier but as you > prefer. Is not strictly shared. And it's shortest way to get it working, as you have read it's not sure how many changes needing source, and people talk about command line option for switching TCs (best solution I think) > Just please explain me what do you expect of YAL in terms of data dir > and config dir and I'll make necessary changes. Cmd line switch or what? Finally I could get it working. But ,would be a more direct solution YAL selecting ".freespc2/" for freespace2 mod or no mod selected on mod panel. ".babylon2/" for babylon TC selected on mod panel. maybe .wngcsaga for WCS and so (remember, 8 length names) My ebuild currently working with babylon and freespace2. Only problem was bright control, which is not stored when I reopen game. However voice adjustments worked. Maybe related to yal or fs2_open? I think I will post today ebuilds. Please I needing somebody doing a 'from zero install' (without any component installed)
Created attachment 254415 [details] Full freespace2 stuff 3.6.10-r1 (revision 1) 'quick and dirty' multiTC support for testing Only freespace2 and babylon provided
If somebody could change original binary for building another one which using as standard place to store files something like .FS2OPEN2 (without bars) and post it here, I could check exact place where binary needing changes. Maybe could be fixed bright adjustment lost like this.
I just uploaded a new 3.6.12 source tarball with a patch that should fix its compiling on gentoo. I changed the filename from my previously posted one to better match the 3.6.10 filename. Would love to see working 3.6.12 ebuilds. http://swc.fs2downloads.com/builds/fs2_open_3_6_12.tgz Also, OGG cutscenes are now available again at http://swc.fs2downloads.com/files/FS2OGGCutscenepack.vp If that goes away, they're also at http://freespacemods.net/request.php?128. That resolves to fs2_ogg.zip, which would need to be extracted to the Freespace2 folder's data/movies directory or wherever movies are supposed to go. I'll attach a 3.6.12 ebuild based off of the 3.6.10-r1 that should work, but I can't test as I don't have a gentoo desktop. I took a tweak from Roland's ebuild on the forums as well. I'm not sure if I can do the NOCONFIGURE=1 like I did. I also don't think hex editing the fs2_open is necessary for freespace 2, it's already 8 characters and is like that everywhere else for FS2, so why change that one? I also changed .babylon2 to .babylon5, not sure why 2 was picked.
Created attachment 254449 [details] Example of a 3.6.12 ebuild like Enrique's 3.6.10 that does multi TC support in one ebuild.
(In reply to comment #97) Please feel free making patches, my temporary (I hope) and dirty solution mustn't be saw as a true solution. I could apply any patch you post here for whatever package version (best greater than 3.5.10, I think) In my opinion, YAL could send TC to be used and fs2_open could take it. Both binaries having to switch .fs2_open to correct value. TC localization don't mind because it's solved with wrapper (YAL complaints about this but work perfectly) I'm not a programmer, but I hope we get a standard way to do things.
Hi, I have the retail version of "Conflict: Freespace The Great War" and "Conflict: Freespace Silent Threat". I have the following questions regarding the creation of the related ebuilds: 1) I will, obviously, use the freespace2-data ebuild to create the ebuilds to retrieve the necessary data from the retail CDs. But I would like to know how to retrieve the list of files expected to be copied. I guess I have to uncompress the CAB files my self with unshield and check whats in there. @Enrico, is there anything else in the freespace2-data ebuild that is likely to change for those games beside the list of files to copy and the number of CDs to be processed? 2) Where to install the data? a) In directories like /opt/freespace1 and /opt/fs1-silent-threat with there own binaries. I suppose I can reuse the same binary than for freespace2. b) In a sub-directory of /opt/freespace2/. 3) Did the ebuilds need to retrieve anything from the internet like new mediavps? I remind of having seen a reference to something called FSPort, but I am not sure what it is exactly. 4) Is there anything else that the ebuilds or me should take care of? The ebuild lists I foreseen so far is: freespace1-meta fs2_open ??? freespace1-data freespace1-additional-data fs1-silent-threat-meta fs2_open ??? fs1-silent-threat-data fs1-silent-threat-additional-data
I'd like to know about this too. I've completed FS1 using the icculus.org port but Silent Threat was practically unplayable. I also read about FSPort. From what I remember, I think it's required.
(In reply to comment #107) > Hi, > > I have the retail version of "Conflict: Freespace The Great War" and "Conflict: > Freespace Silent Threat". I have the following questions regarding the creation > of the related ebuilds: > > 1) I will, obviously, use the freespace2-data ebuild to create the ebuilds to > retrieve the necessary data from the retail CDs. But I would like to know how > to retrieve the list of files expected to be copied. I guess I have to > uncompress the CAB files my self with unshield and check whats in there. I'm not write those ebuild but it's easy (I think) I think you have testing and adding, check mediavps ebuild for tiletypes too, and game eclass for functions. Help on ebuild writing on #gentoo-dev-help (http://www.gentoo.org/main/en/irc.xml) on Freenode > @Enrico, is there anything else in the freespace2-data ebuild that is likely to > change for those games beside the list of files to copy and the number of CDs > to be processed? I haven't those games but 100% sure you having to change this ebuild; please, using another name. > 2) Where to install the data? > a) In directories like /opt/freespace1 and /opt/fs1-silent-threat with there > own binaries. I suppose I can reuse the same binary than for freespace2. If you adding more directories fs2_open ebuild needing update to cover that. Start using /opt/freespace2 until your ebuild working and I would cover your changes when. > b) In a sub-directory of /opt/freespace2/. If you test in same dir (back up firstly being better) maybe could be added as mod? Please read how to adding mods to freespace (on hard-light?) > 3) Did the ebuilds need to retrieve anything from the internet like new > mediavps? > I remind of having seen a reference to something called FSPort, but I am not > sure what it is exactly. freespace-data don't take anything from internet. Maybe something would be changed to fs2_open binary? I'm not a fs2 expert at all. Again asking hard-light > 4) Is there anything else that the ebuilds or me should take care of? > The ebuild lists I foreseen so far is: > > freespace1-meta > fs2_open ??? > freespace1-data > freespace1-additional-data freespace1-additional-data??? There is additional data on freespace2 for adding files (modding) original game > fs1-silent-threat-meta > fs2_open ??? > fs1-silent-threat-data > fs1-silent-threat-additional-data > I think you needing to know (hard-light) if fs2_open would support Freespace1 (I think don't) files at all or you having to use linux binary from iculus (which would require a distinct ebuild for fs2_open_binary)
(In reply to comment #107) > Hi, > > I have the retail version of "Conflict: Freespace The Great War" and "Conflict: > Freespace Silent Threat". I have the following questions regarding the creation > of the related ebuilds: > FSO *cannot* use Freespace 1 data from either the original game (Freespace: The Great War) or its expansion (Silent Threat). If you want to play Freespace or its expansion, you need FreeSpace 2 and then download FSPort. Freespace 2 can be purchased from http://www.gog.com/en/gamecard/freespace_2 if you don't have the Freespace 2 disk. IIRC the gog.com version does require wine to extract the installer, see the linux and OSX install guide on HLP for more information http://www.hard-light.net/forums/index.php?topic=60842.0 FSPort can be downloaded from http://www.hard-light.net/forums/index.php?topic=70941.0 The release thread also links to the release threads of the Ported campaigns. As far as I know, the icculus.org version is just for Freespace 1 itself, it has not been tested on other Freespace 1 era campaigns, like Silent Threat (or the much better Silent Threat: Reborn). Also, I believe that development on it has more or less been abandoned. Only FSO has gotten the graphical upgrades and thus FSPort is the preferred way to play the Freespace 1 era campaigns.
Created attachment 255441 [details] ebuild for freespace2 and TBP using fso 3.6.12 Hi everybody, With the last version of the fs2_open 3.6.12 and the right vps, TBP is finally working for me. Attached are the ebuild of: - fs2_open 3.6.12 - fs2_launcher - freespace2 retail version - freespace2 mediavps + cutscenes - everything for TBP Please test them and tell if they are working for you too. There is 2 or 3 stuffs still to be done, I think, and I have some ideas I would like to submit to you, but it is a bit late now and it will wait for Saturday.
Hi again, I have a bit of time today, so I can talk about the 2 or 3 stuff to be done/investigated: 1. On HLP forum, The E. recommand to strip the -O flag from my Cflags, but I was not able to use the command -strip-flag provided by gentoo. This is not critical,because despite the presence of the flag fs2 and TBP work fine. 2. (I think I have already covered the topic before) For the compilation of the fs2_launcher, build-all.sh shouldn't be used because it compiles 4 times the launcher. Once for btr1 (Beyond The Red Line?), tbp, wcsaga and fs2_open itself. So the script should be analyzed and only the relevant lines of the script should be played to compile the launcher just once. 3. I seen in the source code of fs2_open a directory wxFRED2, what is the status of this editor? Is it stable enough to provide it to the users? If yes, how to compile it? Have a nice week-end.
(In reply to comment #112) > 3. I seen in the source code of fs2_open a directory wxFRED2, what is the > status of this editor? > > Is it stable enough to provide it to the users? > > If yes, how to compile it? > > Have a nice week-end. > Incomplete. It is stable and does work *but* it is mostly just a GUI, that is there is no glue code, so there is no point in providing it to the users as it is useless for mission creation. wxFRED currently does not seem to have a working build process for linux. On the other hand, I understand that the windows FRED2_open runs fine in WINE. You can download FRED2_open in the main release thread. http://www.hard-light.net/forums/index.php?topic=70692.0
Created attachment 255991 [details] ebuilds and metadata for freespace 2 and TBP using FSO 3.6.12 This new version of the packages contains the metadata.xml files for each package. Please can one review them and complete them where needed? - Some use flags are described with the text "FIX ME". - The <herd/> tag contains "no-herd".
Here are the 2 to totally insane ideas that I have in mind for sometimes: 1. A tool to select which TC to play. This is a continuation of the following thread http://www.hard-light.net/forums/index.php?topic=68413.20 and comment # 50. The idea would be to still create a root directory in /opt something like /opt/fso that would contains one directory for each TCs. This structure would also be created in the $HOME directory of the user the first time the user start the tool to select a TC. The structure in /opt could looks like: /opt/ fso/ babylon/ freespace2/ fs2_open/ TC3/ fs2_open/ would be a link to the TC selected by the user. At the same time, in the $HOME directory, the directory structure could looks like this: $HOME/ .fso/ babylon/ freespace2/ fs2_open/ TC3/ .fs2_open/ Here too, .fs2_open/ would be a link to one of the TCs in .fso/. This allows slotting of fs2_open and fs2_launcher if necessary and doesn't require to modify a thing into the source code or binary during installation, because the link would have the same name than what is in the binary. Each TC directory could contain a link to the related version of fs2_open and fs2_launcher for the same reason as above. The tool could simply select which TC is the "active" one or "activate" it and start the associated launcher or binary. My first idea was to create a module for eselect allowing that, but I don't think eselect was meant to be used by normal users, so a dedicate tools must be created I guess. 2. Using Gentoo Portage as the basement for the future FSO installer This is maybe better for the HLP forum but as it conserns Gentoo I post it here. Pros: - Gentoo allows to install the system on various OSes without root privilege even Windows and MAC OS X. This is done through what they called Prefix. - The way the system works doesn't require the modders to modify there package, except in very particular cases, and doesn't require the FSO to constrain people to use a particular package format as portage only requires a script that reference the package location and name. - Only a server for the installation scripts needs to be maintained by the FSO project if the idea behind the unified installer was to have a central server for the packages. Cons: - Gentoo is not the easiest system to administer for non Linux user maybe. - On Windows, at least, The Gentoo Prefix requires to install from an iso image (as far as I know). What is your view on those topics?
(In reply to comment #115) > Here are the 2 to totally insane ideas that I have in mind for sometimes: > > 1. A tool to select which TC to play. > > This is a continuation of the following thread > http://www.hard-light.net/forums/index.php?topic=68413.20 and comment # 50. > > The idea would be to still create a root directory in /opt something like > /opt/fso that would contains one directory for each TCs. This structure would > also be created in the $HOME directory of the user the first time the user > start the tool to select a TC. > > The structure in /opt could looks like: > > /opt/ > fso/ > babylon/ > freespace2/ > fs2_open/ > TC3/ > > > fs2_open/ would be a link to the TC selected by the user. > > At the same time, in the $HOME directory, the directory structure could looks > like this: > > $HOME/ > .fso/ > babylon/ > freespace2/ > fs2_open/ > TC3/ > .fs2_open/ > > Here too, .fs2_open/ would be a link to one of the TCs in .fso/. > > This allows slotting of fs2_open and fs2_launcher if necessary and doesn't > require to modify a thing into the source code or binary during installation, > because the link would have the same name than what is in the binary. Each TC > directory could contain a link to the related version of fs2_open and > fs2_launcher for the same reason as above. > > The tool could simply select which TC is the "active" one or "activate" it and > start the associated launcher or binary. My first idea was to create a module > for eselect allowing that, but I don't think eselect was meant to be used by > normal users, so a dedicate tools must be created I guess. > > > 2. Using Gentoo Portage as the basement for the future FSO installer > > This is maybe better for the HLP forum but as it conserns Gentoo I post it > here. > > Pros: > > - Gentoo allows to install the system on various OSes without root privilege > even Windows and MAC OS X. This is done through what they called Prefix. > > - The way the system works doesn't require the modders to modify there package, > except in very particular cases, and doesn't require the FSO to constrain > people to use a particular package format as portage only requires a script > that reference the package location and name. > > - Only a server for the installation scripts needs to be maintained by the FSO > project if the idea behind the unified installer was to have a central server > for the packages. > > Cons: > > - Gentoo is not the easiest system to administer for non Linux user maybe. > > - On Windows, at least, The Gentoo Prefix requires to install from an iso image > (as far as I know). > > > What is your view on those topics? > Of the two, the first seems more sane. However, I don't know why we'd want to avoid modifying the source code, when there's no aversion to that within the project. I get if you're forced to use a hack like that, but in this case, we're not, so why do a hack instead of a proper upgrade to the code base? It does probably depend on the command line upgrades Nigel (Iss Mneur) is working on, but in the end it would eliminate any need for those types of hacks. However, if it's what gets it working now, with 3.6.12, I can't say I'm opposed to it.
(In reply to comment #116) > (In reply to comment #115) > > Here are the 2 to totally insane ideas that I have in mind for sometimes: > > > > 1. A tool to select which TC to play. > > > > This is a continuation of the following thread > > http://www.hard-light.net/forums/index.php?topic=68413.20 and comment # 50. > > > > The idea would be to still create a root directory in /opt something like > > /opt/fso that would contains one directory for each TCs. This structure would > > also be created in the $HOME directory of the user the first time the user > > start the tool to select a TC. > > > > The structure in /opt could looks like: > > > > /opt/ > > fso/ > > babylon/ > > freespace2/ > > fs2_open/ > > TC3/ > > > > > > fs2_open/ would be a link to the TC selected by the user. > > > > At the same time, in the $HOME directory, the directory structure could looks > > like this: > > > > $HOME/ > > .fso/ > > babylon/ > > freespace2/ > > fs2_open/ > > TC3/ > > .fs2_open/ > > > > Here too, .fs2_open/ would be a link to one of the TCs in .fso/. > > > > This allows slotting of fs2_open and fs2_launcher if necessary and doesn't > > require to modify a thing into the source code or binary during installation, > > because the link would have the same name than what is in the binary. Each TC > > directory could contain a link to the related version of fs2_open and > > fs2_launcher for the same reason as above. > > > > The tool could simply select which TC is the "active" one or "activate" it and > > start the associated launcher or binary. My first idea was to create a module > > for eselect allowing that, but I don't think eselect was meant to be used by > > normal users, so a dedicate tools must be created I guess. > > > > > > 2. Using Gentoo Portage as the basement for the future FSO installer > > > > This is maybe better for the HLP forum but as it conserns Gentoo I post it > > here. > > > > Pros: > > > > - Gentoo allows to install the system on various OSes without root privilege > > even Windows and MAC OS X. This is done through what they called Prefix. > > > > - The way the system works doesn't require the modders to modify there package, > > except in very particular cases, and doesn't require the FSO to constrain > > people to use a particular package format as portage only requires a script > > that reference the package location and name. > > > > - Only a server for the installation scripts needs to be maintained by the FSO > > project if the idea behind the unified installer was to have a central server > > for the packages. > > > > Cons: > > > > - Gentoo is not the easiest system to administer for non Linux user maybe. > > > > - On Windows, at least, The Gentoo Prefix requires to install from an iso image > > (as far as I know). > > > > > > What is your view on those topics? > > > > Of the two, the first seems more sane. However, I don't know why we'd want to > avoid modifying the source code, when there's no aversion to that within the > project. I get if you're forced to use a hack like that, but in this case, > we're not, so why do a hack instead of a proper upgrade to the code base? It > does probably depend on the command line upgrades Nigel (Iss Mneur) is working > on, but in the end it would eliminate any need for those types of hacks. > However, if it's what gets it working now, with 3.6.12, I can't say I'm opposed > to it. > Sorry I should have been more explicit that "solution" is only until the code base is upgraded so it eliminates the need for this hack.
Created attachment 256528 [details] ebuilds and metadata for freespace 2 and TBP using FSO 3.6.12 + fsostarter ebuild Hi, Here is a new version of the ebuilds and metadata for Freespace Open and TBP. this archive contains also the tool fsostarter that allows the user to start a TC or freespace2 without having to go into the directory of the TC itself. Unfortunately, It was not possible to defines simply links to a common version of the binaries and links to a particular TC due to the inner working of YAL, so I keep the compilation as it was in the previous archive but have changed a bit the directories used to be able to use the fsostarter tool.
Created attachment 256529 [details] The tool to start a TC without a need of first stepping into the TC directory Here is the tool in itself. Do not forget to copy it into the distfiles directory before emerging it. Use 'fsostarter -h' to get the help on the tool.
Anybody could help contacting WCS prologue ant BTRL developers? I have sent email both, but no response. I would like getting links for mediavps packages and information about what is latest fs2_open version compatible. I have tested WCS with 3.6.10 but link and navigation to nav points won't work. I have done a better patch for hardcoding folders (now bright setting work again) and I would add SLOT support soon.
Version 3.7.0 was released: http://www.hard-light.net/forums/index.php?topic=85435.0
