Author Topic: FS2_Open Linux Mini Howto  (Read 67913 times)

0 Members and 1 Guest are viewing this topic.

Offline taylor

  • Super SCP/Linux Guru
  • Moderator
  • 212
    • http://www.icculus.org/~taylor
Atalhlla:
My fault, got a little overzealous on the asm fixing.  I'll get a new patch out to you in the next little bit that will just apply to what you have and fix the problem.  It should only be that one file that has the problem.

Inquisitor:
This is bK's thing so I'd rather give him first go at it since he's already worked pretty hard to merge the FSO and icculus.org stuff together.  If he doesn't want to do it or doesn't have the time then I'll start work on updating it to the current CVS version in preparation for a merge.  I don't know that I can devote enough time to maintain it properly since I still don't have time to keep up with everything in FSO world, but if something breaks or needs some *nix candy coated sprinkles added on top then I'll happily do it.

 
Welp.  Don't know what to say about this.

Woot!  It worked!  It runs like malassass down a cold rock (about 2-4 fps on the first training mission) on this 500 MHZ PB G4 (I'm so slooowww...:( ), but it worked!  The sounds cap off alittle early, but that might just be due to the slowness.  Even if it's not, ohwell, it's minor IMO, and can be fixed later.  The important thing is that the last patch was all that was needed.  It now runs on PPC Linux.  I didn't turn off the stub outputs, so they kinda filled up the terminal, but eh. :P
(Unless compiling with out that verbosity speeds it up...)

Thank you, Taylor, Tigital, Bk, Amon, and anyone else that needs thanking.  And the rest of the FSO crew!  Woot! :D

~Atal . o O ( Specular lighting on that ship... oooooh.... )

[edit] Caveat : I still haven't tried importing pilots, yet. :O [/edit]
« Last Edit: February 18, 2004, 09:02:37 pm by 1633 »
Mertakk monae ki ienikk du bellou zhello.
Kuek mertakk monae ienikk divakkou zhello.

What does it mean if the most fun you had all night was blowing up asteroids...?

"Its a Babylon Space 2 HercFury!" --mikhael on seeing my first fighter design.

 

Offline Amon_Re

  • 28
    • http://www.kefren.be
Quote
Originally posted by Atalhlla
Thanks, Amon, that solved the gropengl thing.  Anyway, now it dies on graphics/scaler.cpp



Amon : Just to check, did you replace all the Mesa/OGL things in /usr/lib (or /usr/local/lib if you have them there, instead) and in /usr/X11R6/lib ?

~Atal


No, /lib only contains symlinks to the ones in /usr/X11R6/lib.
You should however run ldconfig after updating them (unless you updated with a package)

I've build a debug build, and it fails in graphics/2d.cpp here,  (line 1130, the assert function fails), so i commented out that, and recompiled & run it again, and it seems it can't locate some .tbl files (strings.tbl amongst others), so eighter my permissions are fubar, or i'm missing some files... Does this build run with a vanilla FS2 install? Or does it need some specific fs2_open vp files?

Cheers
Sig? What sig?

 

Offline Amon_Re

  • 28
    • http://www.kefren.be
Taylor,

Where can i get me hands on the LinuxPPC build? Preferable with the patches already in.

Cheers
Sig? What sig?

 

Offline Inquisitor

Taylor,

bk hasn't seemed to have time due to RL issues, so, if you are willing, email me, we'll get you set up with CVS accounts and the do's and don't s of our repository :)
No signature.

 

Offline taylor

  • Super SCP/Linux Guru
  • Moderator
  • 212
    • http://www.icculus.org/~taylor
Amon_Re:
I just wanted Atalhlla to test it first so I wouldn't have to keep sending multiple patches to multiple people.  As soon as he verifies that the code for using cross platform pilot files is working then I planed to get the patch to you.

You said you had or had access to an Amiga/AmigaOS right?  I've never used an Amiga so I'm not exactly sure of the basic hardware/software but if you get SDL, OpenAL, OpenGL, gcc working on it then I think that what I've sent Atalhlla should work for you.  Though it may need a couple of extra little things.  I know that SDL has Amiga support but I don't know about OpenAL.  We'll have to work that out later if you don't already know.

 

Offline Amon_Re

  • 28
    • http://www.kefren.be
Quote
Originally posted by taylor
Amon_Re:
I just wanted Atalhlla to test it first so I wouldn't have to keep sending multiple patches to multiple people.  As soon as he verifies that the code for using cross platform pilot files is working then I planed to get the patch to you.


That shouldn't be a big issue, thx

Quote
You said you had or had access to an Amiga/AmigaOS right?  I've never used an Amiga so I'm not exactly sure of the basic hardware/software but if you get SDL, OpenAL, OpenGL, gcc working on it then I think that what I've sent Atalhlla should work for you.  Though it may need a couple of extra little things.  I know that SDL has Amiga support but I don't know about OpenAL.  We'll have to work that out later if you don't already know.


Yea i got access to it, the old ones are based on 68000 series of proccessors (motorola) and had no 3D hardware, but there were PPC upgrades and 3D cards for those available.
Also there's a new Amiga on the market (not really finished yet, the porting of the new OS is almost done, and the boards are available) that's based on G3 & G4 proccessors with AGP cards and whatnot, so the hardware should be capable of running it.

Mesa should also be possible (i know Mesa 5 exists for it, dunno about the status of Mesa 6) and SDL is, as you aready mentioned existing. openAL... now that one i don't know, what does openAL do actually?

As for the port, i wouldn't be a straight compile, that's for sure, but i know some very capable people who are intrested in porting it from LinuxPPC to AOS.

Cheers
Sig? What sig?

 

Offline taylor

  • Super SCP/Linux Guru
  • Moderator
  • 212
    • http://www.icculus.org/~taylor
Quote
openAL... now that one i don't know, what does openAL do actually?


That's for the sound.  I looked and it's supports BeOS, MacOS, OSX, Linux (UNIX).  The Linux code should work on pretty much any processor and the OSX version is going to be based on this before too much longer.  I don't know enough about AmigaOS to know if the Linux code would work on it as well.  The Linux source does have Amiga references though so I assume that it does work or just needs to be finished.

Quote
As for the port, i wouldn't be a straight compile, that's for sure, but i know some very capable people who are intrested in porting it from LinuxPPC to AOS.


Privided that a full OpenGL implementation exists and that OpenAL and SDL work then there shouldn't be too much to this.  I say "too much" in a way that means "it probably won't compile out of the box yet but could probably be fixed in a weekend".  SDL should handle video initialization, window management, key-mouse-joy input, endianess issues and basic system setup without code changes.  If OpenAL support is complete then there shouldn't be any problems there either.  The only problems that I can forsee (admitedly without knowing anything about AmigaOS) are compiler issues and some wierdness with CFILE.  I still have dreams about CFILE so there shouldn't be any real problems dealing with that and the compiler issues may not actually be issues if GNU tools are used on the Amiga.

I guess we'll find out for sure though when it's tried for the first time.

 

Offline tigital

  • 23
Atalhlla:
Quote
Woot! It worked! It runs like malassass down a cold rock (about 2-4 fps on the first training mission) on this 500 MHZ PB G4 (I'm so slooowww... ), but it worked! The sounds cap off alittle early, but that might just be due to the slowness. Even if it's not, ohwell, it's minor IMO, and can be fixed later. The important thing is that the last patch was all that was needed. It now runs on PPC Linux. I didn't turn off the stub outputs, so they kinda filled up the terminal, but eh. :P
(Unless compiling with out that verbosity speeds it up...)


...wow!  did taylor send you the ppc changes?  I would REALLY like to see the eye-candy!  Anyway you can tar.gz me the source tree?  It'd be great to make available an OSX beta...

...in other news, I've been working on importing the project into apple's xCode, which is really cool:  zero-linking, fix & continue, distributed builds, etc...should speed things up considerably (development-wise, that is)...

Taylor:  are you running a 10.3.x install yet?  I highly recommend it:  made my 2+year old 667 tiBook seem like a new machine!

 

Offline Amon_Re

  • 28
    • http://www.kefren.be
@Taylor

AmigaOS's default compiler is gcc so no problems there neighter, and the TCP/IP stack is *bsd based, so that shouldn't give any nightmares neighter, so i think it would be quite doable to port it, yea

Cheers
Sig? What sig?

 

Offline Amon_Re

  • 28
    • http://www.kefren.be
Good news, i got fs2 running on my linuxbox :)

Basicly there were 2 problems, Mesa 6.0 being required and it doesn't work with a vanilla install of freespace.

The fix seemed to be to run the game in windows once and updating it & then copying it to linux.

I wonder if this update can be achieved via linux... Oh well
I'll rewrite the mini howto to reflect the changes.

[edit] It seems i already mentioned this in my earlier minihowto's... argh, i guess it shows you have to RTFM :)

Cheers
« Last Edit: February 19, 2004, 03:34:04 pm by 1139 »
Sig? What sig?

 

Offline Amon_Re

  • 28
    • http://www.kefren.be
Incase you would like to get FS2_Open to run in linux (x86 architecture) you might find this intresting:

First grab bKtHeG's source tarball from http://ds.hamburg051.server4free.de/20031206_fs2_open_linux.tar.bz2 and extract the fs2_open directory.
First do the configure script ./configure -disable-networking
And after that execute make.

Incase you get compiler errors in gropengl.cpp, it's most likely because you lack an up to date version of Mesa, the current version is 6.0 and can be downloaded @ www.mesa3d.org.

You can verify this with the command glxinfo wich will report the version of OpenGL your system supports and wich extensions.
Check to see if the functions mentioned by gcc are present in the glxinfo output (eg glOpenBufferARB).

Unpack the tarball you downloaded, and do make linux-x86.

This will create the new GL libraries wich you need to install on your system.
Depending on the kind of distribution you use, these libraries might be in /lib or in /lib/X11R6/lib, eighter way, you need to replace them with the newly compiled ones, and run ldconfig

Rerun glxinfo to see if the system reports the correct version of Mesa now, if it doesn't, you might have DRI on your system, and you may be required to replace the library in /usr/X11R6/lib/tls aswell (make sure to run ldconfig afterwards).

Incase you get errors while compiling in ds.cpp, it is probably because you lack the latest CVS version of openAL.

In order to get the latest version, you should first make sure you have CVS installed.
Do the following in a shell(make sure you are online):

cvs -d:pserver:[email protected]:/usr/local/cvs-repository login

This will connect to the repository, if you are asked for a password, use "guest"
Now do the following:

cvs -d:pserver:[email protected]:/usr/local/cvs-repository co openal

This will download the repository into your current directory, so make sure you are in a temporary directory first!
Change to the directory, and read the docs for openAL.
Basicly, you'll have to do the following from within the openal directory:

cd linux
./configure --prefix=/usr/local
make
make install

Make sure you replace the old libraries in /usr/lib and that you eighter copy or link the new ones to /usr/lib

Now go back to the fs2_open directory, and run make again.

Make should now finish the compilation, and create the file fs2 (located in code/), copy this file to your freespace 2 directory.
If it doesn't, and complains about not finding -lGL, don't panic, this means you don't have a symbolic link in /usr/lib towards the correct file.
Create the symlink called libGL.so and make it point to /usr/X11R6/lib/libGL.so

Again start make from within the fs2_open directory.

In that same directory, create a textfile called fs2_open.ini and make sure it contains the following:

[Default]
Fullscreen=0
VideocardFs2open=OpenGL - Primary Display Driver(1024 x 768)
Videocard=OpenGL - Primary Display Driver(1024 x 768)
VideoApi=OpenGL

That's all, you should now be able to start fs2 with ./fs2

Extra notes, if you installed FreeSpace 2 using eg iculus's installer and get an error "error parsing strings.tbl" or "error parsing rank.tbl", try copying over your working freespace install from your windows partition, and see if that helps.
Don't have windows installed? No biggy, install the latest wine, and you can use the installer from the FreeSpace CD's.
Incase you got an error while compiling like, eg "brace-enclosed initializer used to initialize x", it is most likely because of a whacked GCC install, check that you have binaries that match each other (don't mix files from eg 2.9.2 with 3.x), and if that doesn't help, try removing & reïnstalling GCC.

With many thanks to bKtHeG, Taylor and all the others for making this available.
Sig? What sig?

 

Offline taylor

  • Super SCP/Linux Guru
  • Moderator
  • 212
    • http://www.icculus.org/~taylor
tigital:
It's a very cut down version of your OSX patch.  A few cosmetic changes that will hopefully make for easy porting to other platforms down the road and the new pilot file loading and saving code.  It's probably not enough to even run under OSX yet and deffinitely nothing that would make it work as an APP.  I'm going to get you the new pilot code as soon as it's tested to work 100% and will send you the full FSO patch at the same time.

I wanted to wait with a full OSX patch until you gave the thumbs up on the current code.  Can't say that I want two code bases with the same bugs floating around.  Also this is a good test to determine if any bugs are just OSX related (primarily sound issues where the actual libraries are different) and can help rule out any bugs that may be due to swapping issues.

Still only have access to 10.2.x since I have to deal with what I can steal.  I probably won't get the chance to even test any code on the Mac for a few months yet so that kinda sucks.

Amon_Re:
Might want to add to that HOWTO that if you're using NVIDIA drivers to *NOT* install Mesa6 as that will screw up the NVIDIA driver installation and revert back to software rendering which is slow as hell.

A second note is that I did put in the needed code to automatically create the default ini file (using 640x480 res), ~/.fs2_open/fs2_open.ini so the hand edit shouldn't be needed.  It just has to be run once with the current user to create the files.  If you install as root then don't make an ini file in the game directory since bad things can happen with updates.  Same with pilot files, logs, and anything else that's created/modified on the fly.  Every file that the game creates after install should end up in ~/.fs2_open.  If it doesn't then it's a bug and should be fixed.

I have a Linux FS2 updater to get it to version 1.20 on my website: http://icculus.org/~taylor/freespace/updates.  Just grab and execute fs2-1.20-x86.run to update the needed files from a fresh install.

 
*tabtabtabtabtabtabtabtab*
It ate my mouse!  Other than that,
X86 Linux pilot : the first training module plays fine up until the instructor has you match speeds with him, then the instructor just sort of wonders about... This has happened with the OSX Beta that Tigital put out, too, although it was only sometimes that it happened.  I'm wondering if it has something to do with any of the conditions for some of the things the instructor has you do...

And since it ate my mouse... Well, I'll need to try that.  Hold on a moment.

[Edit] Hey, did you know that, if it eats your mouse (but not your keyboard), you can just run ./fs2 again, and your mouse will work!
And I still need to test the Windows Pilot.  Boy, that Vasudan main hall is neat.[/edit]

~Atal
« Last Edit: February 19, 2004, 09:20:03 pm by 1633 »
Mertakk monae ki ienikk du bellou zhello.
Kuek mertakk monae ienikk divakkou zhello.

What does it mean if the most fun you had all night was blowing up asteroids...?

"Its a Babylon Space 2 HercFury!" --mikhael on seeing my first fighter design.

 

Offline taylor

  • Super SCP/Linux Guru
  • Moderator
  • 212
    • http://www.icculus.org/~taylor
Try using the --nograb option if you're playing in a window.  This will mean that you can't control your ship very well with the mouse but it shouldn't kill it either.  Typically you can just run anything that reinitializes the SDL input system to get you're mouse back, just like running the game again will do.  Also Ryan (icculus) wrote a quick little file to fix just this problem.  It's called umouse and if you can't find it with a search let me know and I can send you the source.

As far as the pilots go, if you try a fresh pilot does the instructor still wonder off?  Obviously this doesn't sound like a pilot issue but does the instructor still move around like it's following waypoints or does it just seem random?  Does he acknowledge that you matched speeds or not?  If he doesn't see that you're matching speeds then it's most likely some scripting issue but I have no idea why it would happen only with the PPC build.  It he does see it then I can think of a couple of off the wall things to check out.

tigital: did you get this fixed in the OSX build already?

 

Offline taylor

  • Super SCP/Linux Guru
  • Moderator
  • 212
    • http://www.icculus.org/~taylor
Worked on updating everything to the current CVS this weekend.  I want to do some more bug hunting and generic cleanup before making a new test release.  Should have something new for everyone to play with later this week.

 * Builds with networking enabled now but I don't know of a valid server to start testing the PXO code with.  Other than getting it to compile I haven't looked to bug fix or finish any missing parts so it may not even work, it could crash on first use and take half the Internet with it for all I know.  Other problems I noticed was that a PXO server is required in order to play network games, it will crash if you just want to LAN play.  This is mostly CFILE problems trying to read non-existing files that were read from a non-existing server.  I've fixed this but as it's FUBAR in the win32 build as well I don't have a way (don't have MSVC++) to test it yet.  I also have to look at a viable interface fix for the extra text on a multi-game creation screen.  I'm assuming that this is a PXO/non-PXO issue since it was previously commented out.  The code also seems rather intolerant of failures since if I give the PXO server as one of my computers, that obviously isn't running anything, it will crash.  This may just be an issue with *nix send() though so I may look at that.  I don't really want to spend too much time on this if the original PXO code is going to see the light of day, with Linux support.

 * What's the status of OGL HT&L?  It was crashing badly but it turned out to just be some NULL gr_* calls so that was easy to fix.  Most models don't show up though including missles and ships.  Particles, explosions, primary weapon fire and most debris do show up though.  But the cool glowing primaries are sweet!  I don't plan on fixing this myself for now though so hopefully there are some people actively working on this.  Also the HUD tends to disappear when HT&L is used.

 * I changed the ini file entry for video to be what is currently used in the win32 game, "OGL -(widthxheight)xbpp bits" for "VideocardFs2open" and got rid of "Videocard" and "VideoAPI".  If the entry exists but is invalid (ie. the old string) then it will be replaced with the new string and will ask the user to try running the game again and tells which file to edit to change from default resolution.  So basically this works kind of like the current win32 version does: wrong reg setting, get launcher and update setting, exit game to let user run again, tell user what happend and why.

 * Non-debug builds aren't so verbose now.  DEBUGME's are still there but most everything else is quite unless it's a debug build.  Having to look at all of that crap was annoying unless you actually wanted to know something, in which case you probably need a debug build anyway.

 * NULL does not a valid int make people, damn! :hopping: :D

 * I'm sure that I fixed a couple of small non-*nix specific issues but I can't remeber what they were off the top of my head right now.  I'll give better detail in the changes when I release something.

I still need to do a lot of cleaning before it approaches a CVS ready patch but it's coming along quickly.  About the only thing I need to figure out now is how to properly credit everybody (bK, icculus.org, etc.) since everything is kind of just mushed together at this point.

Does anyone have any complaints that I should know about?  Any bugs?  I'm going to have a quick look in bugzilla (mantis, whatever in the hell is being used now) and see if there is anything interesting.

 

Offline Kazan

  • PCS2 Wizard
  • 212
  • Soul lives in the Mountains
    • http://alliance.sourceforge.net
if you want to play multi without PXO uncheck PXO and all systems need to enter the IP of one of the systems [include that system] under TCP/IP

I need to make sure i fixed the crash that was presence with PXO not properly disabling -- i think it is fixed though.


FYI: if you're making chances to the TCP/IP code in fs2openPXO then make sure it's inside the unix ifdefs so it'll merge right and I can then backmerge that into the origional fsnetd codebase that it was pulled from --- as I haven't had a chance to do any unix compat testing/fixing for a while
PCS2 2.0.3 | POF CS2 wiki page | Important PCS2 Threads | PCS2 Mantis

"The Mountains are calling, and I must go" - John Muir

 

Offline taylor

  • Super SCP/Linux Guru
  • Moderator
  • 212
    • http://www.icculus.org/~taylor
Quote
if you want to play multi without PXO uncheck PXO and all systems need to enter the IP of one of the systems [include that system] under TCP/IP

On a LAN game it should use broadcast packets to find the servers so entering an IP is conterproductive unless required for firewalls or whatever.
Quote
I need to make sure i fixed the crash that was presence with PXO not properly disabling -- i think it is fixed though.

It's crashing with CVS HEAD for me on a fresh checkout of 10 minutes ago.  The main problem is stuff like this (in game_hacked_data()):
Code: [Select]

CFILE *tvalid_cfg = cfopen("tvalid.cfg", "rt", CFILE_NORMAL, CF_TYPE_DATA);
char *buffer = new char[cfilelength(tvalid_cfg)];

cfilelength will crash if tvalid_cfg is NULL since there is no test.  multi_update_valid_tables()  just returns if fs2open_pxo.cfg doesn't exist.  If it exists then fine but it shouldn't be a requirement for LAN play.

I added this:
Code: [Select]

   if (!Om_tracker_flag) {
      if (!Game_weapons_tbl_valid || !Game_ships_tbl_valid)
         retval = 1;
                                                                                                                     
         return retval;
    }

and then a check that tvalid_cfg != NULL for safety.  If it is NULL then something went wrong and the assumption is made the the tables are hacked.  There is this same thing in another place or two as well.  The other option was to give a return value to multi_update_valid_tables() to know whether or not it communicated with the server but I didn't want to make those types of changes on a whem.  I'm not looking at it closely but it appears that multi_update_valid_tables() will pass valid tables even if a server is not found to get the crcs from.  In that case the weapons_tbl and ships_tbl tests should be used for hacked or not, like I'm doing if the PXO button is not on (!Om_tracker_flag).
Quote
FYI: if you're making chances to the TCP/IP code in fs2openPXO then make sure it's inside the unix ifdefs so it'll merge right and I can then backmerge that into the origional fsnetd codebase that it was pulled from --- as I haven't had a chance to do any unix compat testing/fixing for a while

Since I don't have a way to test a win32 build I'm just leaving that code alone.  There actually aren't that many changes to code needed.  Most of what I changed was to #include's, just cosmetic/simplification stuff, and simplifying the #define's that didn't really need to be different between plaforms.  I also included globalincs/pstypes.h in a few places to provide endian-swapping if needed in the future and to make sure that the stubs for win32->linux stuff is used (ie. _cdecl under *nix is just "#define _cdecl" but it wasn't getting used)

I  can make a patch for all of this stuff against current CVS and post it for you if you want to take a look.

 

Offline Kazan

  • PCS2 Wizard
  • 212
  • Soul lives in the Mountains
    • http://alliance.sourceforge.net
I have no control over tha LAN play thing - that is V's netcode and is SOO DIRTY that i'm afraid it'll give me AIDS

anyting that should be called only when in multiplayer should be enclosed in
if (Om_tracker_flag) { }

for the !Om_tracker_flag and the _tbl_valid falgs they should be ignored -- IIRC they're not even used by fs2openPXO (id' have to double check)

if fs2open_pxo.cfg doesn't exist and PXO is enabled the game should b1tch  -- and you're write that call to update valid tables should be enclosed in an if tracker flag
PCS2 2.0.3 | POF CS2 wiki page | Important PCS2 Threads | PCS2 Mantis

"The Mountains are calling, and I must go" - John Muir

 

Offline taylor

  • Super SCP/Linux Guru
  • Moderator
  • 212
    • http://www.icculus.org/~taylor
The problem is that most of the code doesn't check if PXO is used or not, it just assumes that it is.  fs2open_pxo.cfg is checked for even if PXO is disabled.  If it's not found then OK but the block of code that called to check doesn't take into account that it could have failed not finding the file. Therefore it just keeps going like everything is as it should be.  This is where a return code from multi_update_valid_tables() would be nice but that means changing more than I did for it to work.

The weapon/ship table checks aren't used by your PXO code but were previously used to determine hacked tables for LAN games.  I'm using !Om_tracker_flag at the start of game_hacked_data() so that if we're not using PXO then used the weapon/ship table checks to determine hacked data and skip all of the PXO checks.  Encasing the PXO code in a (Om_tracker_flag) wasn't really needed for a 5 line fix (in this case).

Speaking long term it would be probably be better to just have multi_update_valid_tables() do all validation checking (it's already doing first pass) and return a valid/invalid to the calling function.  The calling functions are just checking again if it was actually valid or not by reading the file created by multi_update_valid_tables() which said that it was valid or not.  All that it looks like it's doing, and again I'm not looking at this real close, is that *_tables() gets name and valid status for each table, then the calling function looks through to find if there was any invalids and then calls it hacked.  If *_tables() has already found an invalid table then why does it have to check again?

You wrote all of this stuff though and other than looking enough to fix this one problem I don't have the entire picture to look at here.  There is probably more to this than I'm seeing but the short term fix so far should get LAN games going again and shouldn't have any impact on your PXO code.  I've been through the LAN code for the icculus.org stuff and there isn't a bunch to it, I'd never say that it was pretty, but it pretty much just does what it does.  I haven't seen anything network code wise that shows the PXO and LAN code interfering with each other.  The interference is in the setup before play, interface stuff and validation, but neither is difficult to fix.

I've posted a patch of just the PXO changes I made so that you can see everything that I did in context.  Grab it here: pxo_fix.diff.  This doesn't have all of the changes since that would require more pieces of the *nix patch but everything needed to get LAN play working should be here.  As I said previously I haven't tested this in actual network play, but it doesn't crash anymore and does allow LAN game creation.