ioEF 1.38 test version + windows x64 build

[Thilo]

Hi everyone. Normally I'd be posting this on the ubergames forums, but, well, they're down. How long has it been since ioEF 1.37?
I have been busy working on ioquake3 and have only recently updated my Elite Force patches, see http://thilo.kickchat.com/efport-progress
There are LOADS of changes and improvements since my last official version, 1.37

To those who don't know what ioef is: ioCow and rpgxEF are based on my work which turns the ioquake3 engine into an Elite Force engine.

This is but a small list of what this new holomatch engine does for you:

• Native support for anaglyph and quad-buffered 3d-stereo rendering
• IPv6 support
• VoIP support, with speakers correctly placed in 3d space
• Native Windows 64 bit support, no 32 bit emulation
• Fast UDP downloads, even Ravensoft's original clients will now download up to 100 times as fast (though they cannot download files larger than 32Megabytes)
• Tons of bugfixes and improvements

This is in addition to the manyfold improvements of my last ioEF 1.37 release.
I'd appreciate it if you could try this out for me. This is only a release candidate, not a stable version, so don't expect everything to run flawlessly out of the box.

How to install:
 - select your operating system
 - Download all files listed under that operating system, and copy them to your EliteForce folder
 - Run the .exe file!

Win32:
http://thilo.kickchat.com/efport-progress/bin/win32/iostvoyHM-1.38_rc1.x86.exe
http://thilo.kickchat.com/efport-progress/bin/win32/renderer_opengl1_x86.dll

Windows 64 bit:
http://thilo.kickchat.com/efport-progress/bin/win64/iostvoyHM-1.38_rc1.x64.exe
http://thilo.kickchat.com/efport-progress/bin/win64/SDL64.dll
http://thilo.kickchat.com/efport-progress/bin/win64/OpenAL32.dll
http://thilo.kickchat.com/efport-progress/bin/win64/renderer_opengl1_x64.dll

Linux 32 bit:
http://thilo.kickchat.com/efport-progress/bin/linux/iostvoyHM-1.38_rc1.i386
http://thilo.kickchat.com/efport-progress/bin/linux/renderer_opengl1_i386.so

Linux 64 bit:
http://thilo.kickchat.com/efport-progress/bin/linux/iostvoyHM-1.38_rc1.x86_64
http://thilo.kickchat.com/efport-progress/bin/linux/renderer_opengl1_x86_64.so


If you encounter any bugs, please report them here.

[Veritas]

Well, hello! Welcome to TLO's forums! I'm told the UGS problem is only temporary, but you are welcome to make yourself at home here . TLO would love to help you with your work in any way we can.

Now, some quick questions - will these be compatible with the current RPG-X beta, 8.4.1? Is it possible they'd work with GSIO's rpgxEF betas, 8.4.4-8.4.6 (my guess is no, but no harm in asking)? Lastly, how is this superior to the current ioCow version that ships with RPGXCE?

[Thilo]

First of all, ioEF is fully compatible with the original EliteForce as shipped by Ravensoft. If the rpgxEF betas require engine updates that make it incompatible with the original EliteForce from Ravensoft, then ioEF will not be compatible. But... why don't you just try out my engine builds?

Secondly, I don't know which svn revision of ioquake3 ioCow is based on, but my impression was that it's been a long time since ioCow has last been updated. In the meantime, there have been tons of bugfixes, some of them security critical.

Thirdly, as you see the renderer has been modularized. We are expecting a patch soon that would add modern rendering techniques to ioquake3 and thus ioEF. It includes Vertex Buffer Objects and does much more rendering on the hardware. This will greatly improve performance on large maps for newer hardware as is common today. See also: https://bugzilla.icculus.org/show_bug.cgi?id=4358

The purpose of me posting here is that there aren't many sites around anymore that are dedicated to Elite Force. This being one of the few that still uses a derivative of the EliteForce engine actively it was only logical for me to start a thread here.

[Veritas]

Hehe, I would have given it a try regardless... do you think this will help prevent issues such as Bad Command Byte, ParseServerError and other such messages? ioEF/ioCow already go a ways towards this, but they still can't handle quite as much as rpgxEF.

BTW, the download link for SDL64.dll throws a 403 forbidden error.

[Thilo]

Hehe, I would have given it a try regardless... do you think this will help prevent issues such as Bad Command Byte, ParseServerError and other such messages? ioEF/ioCow already go a ways towards this, but they still can't handle quite as much as rpgxEF.

I am not sure about those. That's what you should test.

"BTW, the download link for SDL64.dll throws a 403 forbidden error."

fixed now, retry.

[Thilo]

Hehe, I would have given it a try regardless... do you think this will help prevent issues such as Bad Command Byte, ParseServerError and other such messages? ioEF/ioCow already go a ways towards this, but they still can't handle quite as much as rpgxEF.

If rpgxEF has fixed these issues I'd appreciate a notice on how to fix this so I can merge this upstream. You hear me, GSI001?

[Veritas]

Thanks, it's working now - I was able to run the client fine, but it throws g_spawn errors when loading complex maps (rpg_atlantis for example) locally, and parses when connecting to server running those maps - just like ioCow and regular ioEF. Of course, I haven't tested extensively at all. I used the x64 Windows version. A couple other things I've noticed, though these might be out of your control:

When I am running the game in fullscreen, and hit start or alt-tab out of the window, I'm unable to move the mouse, though the keyboard functions normally. This might be a setting issue on my end, but in ioCow, I'm able to switch between windows and so on easily.

Like earlier versions of ioEF (and ioCow to an extent), after running it once it ate up and misconfigured my hmconfig.cfg file, purging all my settings. I keep backups, so it's no big deal, but that's a definite bug.

One thing I did like: It doesn't throw vm_ui errors that ioCow generally throws upon exiting. I can also confirm it appears fully compatible with RPG-X 8.4.1, which means it is unlikely to work with rpgxEF.

If rpgxEF has fixed these issues I'd appreciate a notice on how to fix this so I can merge this upstream. You hear me, GSI001?

It pretty much has, but I don't know if the difference lies in the rpgxEF executable or the rpgxEF libraries. Overall, rpgxEF is a better solution than the ioCow installs we use currently; it's just that people prefer not to switch from something which reliably works, even when it's better

[Thilo]

Thanks, it's working now - I was able to run the client fine, but it throws g_spawn errors when loading complex maps (rpg_atlantis for example) locally, and parses when connecting to server running those maps - just like ioCow and regular ioEF.

Those are issues in the gamecode, and not engine related.

When I am running the game in fullscreen, and hit start or alt-tab out of the window, I'm unable to move the mouse, though the keyboard functions normally. This might be a setting issue on my end, but in ioCow, I'm able to switch between windows and so on easily.

Hmm. Yes, that might be a bug in SDL. You can try bringing down the console first, or setting cvar in_nograb to 1 before alt-tabbing

Like earlier versions of ioEF (and ioCow to an extent), after running it once it ate up and misconfigured my hmconfig.cfg file, purging all my settings. I keep backups, so it's no big deal, but that's a definite bug.

Hmm... strange. It might be related to switching mods ingame, though I thought I had that one pretty much fixed.

It pretty much has, but I don't know if the difference lies in the rpgxEF executable or the rpgxEF libraries. Overall, rpgxEF is a better solution than the ioCow installs we use currently; it's just that people prefer not to switch from something which reliably works, even when it's better

That's well possible that rpgxEF is better suited for your needs. However, this forum post will probably also be important to whoever maintains rpgxEF, so he can merge in the changes from ioquake3. I'd also like some more cooperation. If the guy who made rpgxEF fixed issues that are of interest to ioEF, I'd appreciate some patches, like fixing the hmconfig.cfg screwup. After all, neither the new incompatible rpgxEF, nor ioCow would have been possible without my groundwork.

[Veritas]

That's well possible that rpgxEF is better suited for your needs. However, this forum post will probably also be important to whoever maintains rpgxEF, so he can merge in the changes from ioquake3. I'd also like some more cooperation. If the guy who made rpgxEF fixed issues that are of interest to ioEF, I'd appreciate some patches, like fixing the hmconfig.cfg screwup. After all, neither the new incompatible rpgxEF, nor ioCow would have been possible without my groundwork.

Yep, that'd be GSIO01. I'll make sure he takes a look here; rpgxEF itself has some issues that could stand to be worked out - the biggest being that it's incompatible with lower versions, of course.

[Martin Thompson]

Ah yes, a new version. Didn't know this was being developed anymore. Anyway I cant dl nor test here at my vacation residence but I can give some comments on what I've seen from Pie's posts if you dont mind.

The problem with the hmconfig.cfg being overwritten is a problem with the location. ioEF stores the hmconfig.cfg file
in /AppData/Roaming/EliteForce (or something like that, AppData anyway) so changing the hmconfig file
thats located in /RPG-X2 directory doesn't do anything. ioCow used the config thats stored in the current
mod directory (so /RPG-X2). For some reason, the overwriting usually happens when you have booted a non-ioEf version (so either Vanilla or RPG-XEF) and after that booting ioEF. Since all 3 versions use the same location (AppData) to store the config file, something gets overwritten. Brex says that if you set a parametre (i dont know what its called f_gamelocation or something) to change the directory the game looks for the hmconfig file, you don't have that problem. So maybe its an idea to have ioEF store the hmconfig file somewhere in a folder called "ioEF", so that other versions dont compete for the same space?

As for the fullscreen thing, both ioCow and RPG-XEF have the really neat ability to alt+tab without the game crashing or having to bring up the console first etc. It should be possible to do this and it has been one of few problems for me why I'm not using ioEF.

As a last note RPG-XEF still has some strange bugs (getting kicked off a server and not being able to rejoin for instance) that is preventing more usage of it. As it stands now, if RPG-XEF can fix the little annoying bugs, it would be the best alternative (no offence to you Thilo) since it has extra features build in like LUA codes (now you can use LUA code to program a RPG-X turbolift into a map that was build pre-rpgx and uses the transport/beam away function to switch between decks). It also supports larger maps like Atlantis, Station Iowa and the latest version of Station Modas without parse issues when multiple players join.

Don't get me wrong, i think ioEF is a great initiative an certainly worth it for those EF groups still active in clanning/fragging.
But for RP needs, extra stuff needs to be build in (to support the much more heavyer RP maps that are both larger and have more entities/functions then normal maps) which is currently a bit lacking in ioEF. However if you feel up to it to build in function that support RPG-X better, go for it!

Thirdly, as you see the renderer has been modularized. We are expecting a patch soon that would add modern rendering techniques to ioquake3 and thus ioEF. It includes Vertex Buffer Objects and does much more rendering on the hardware. This will greatly improve performance on large maps for newer hardware as is common today. See also: https://bugzilla.icculus.org/show_bug.cgi?id=4358

This sounds really exiting to me. RPG-XEF already brings us a few improvements but they are mostly visual and not "behind the scenes" improvements (like blooming). It would really be cool if the graphics engine could be build to support even larger maps (yay for RP maps ) and run the current maps faster.

At any rate, I hope my comments where useful to you, some might seem a bit demeanoring since I've mentioned RPG-XEF a lot, but don't feel offended lol, I'm just looking at this from a biased perspective So, whatever you are going to do, good luck with it

ADDITION:

Big problem for me on EF (any version, not just ioEF) is that I'm running an ATI HD 4850X2 on my desktop. I get really low FPS on alot of maps
because ATI naffed up some opengl lecacy support in thier newer drivers. I had to fix this like described in this topic: http://last-outpost.net/forum/index.php?topic=1552.0
If something could be done to fix that (without running some wierd conversion tool on an old dll and naffing up my opengl drivers after an ATI driver update (whoops XD)) you would be god

[Brex]

That cvar is "fs_homepath" and it only works for ioCow, ioEF still ignores it (and while it does save it doesn't load - even if it was launched with the command line). It's weird like that. I'll download this new version and give it a go

[Martin Thompson]

Ah yeah, so thats a ioCow only cvar then. Maybe ioEF can use somethign similar?

[Brex]

ioEF does use it, it just doesn't work in the same way (in that it doesn't work at all )

It's a valid cvar and will quite hapiliy save it's files there, but it won't load from it. Best I can tell it doesn't actually load from anywhere on Windows Vista/7, because even if I manually change all the configs in all the places where it could be stored it still loads with default settings.

[Thilo]

The problem with the hmconfig.cfg being overwritten is a problem with the location. ioEF stores the hmconfig.cfg file
in /AppData/Roaming/EliteForce (or something like that, AppData anyway) so changing the hmconfig file
thats located in /RPG-X2 directory doesn't do anything. ioCow used the config thats stored in the current
mod directory (so /RPG-X2). For some reason, the overwriting usually happens when you have booted a non-ioEf version (so either Vanilla or RPG-XEF) and after that booting ioEF. Since all 3 versions use the same location (AppData) to store the config file, something gets overwritten. Brex says that if you set a parametre (i dont know what its called f_gamelocation or something) to change the directory the game looks for the hmconfig file, you don't have that problem. So maybe its an idea to have ioEF store the hmconfig file somewhere in a folder called "ioEF", so that other versions dont compete for the same space?

Hmm, that's strange. ioEF should honor the fs_homepath cvar. What should be happening is that ioEF looks first at files in fs_homepath, then only in fs_basepath.
You should also know that setting fs_homepath to fs_basepath is really not recommended. It may be a bit more convenient, in that you don't have to click through as many folders looking for the config files, but you don't get per-user separation of config files. It may be that setting this fs_homepath to fs_basepath may overwrite the config files, which still shouldn't happen. I'll have a look at that.

As for the fullscreen thing, both ioCow and RPG-XEF have the really neat ability to alt+tab without the game crashing or having to bring up the console first etc. It should be possible to do this and it has been one of few problems for me why I'm not using ioEF.

Ah, I remember. ioq3 introduced the "minimize" command. Use it like: /bind m minimize
It will cleanly minimize the game then. It may be a bit dirty workaround. Maybe ioCow has a better solution for that, whatever it is.

As it stands now, if RPG-XEF can fix the little annoying bugs, it would be the best alternative (no offence to you Thilo) since it has extra features build in like LUA codes (now you can use LUA code to program a RPG-X turbolift into a map that was build pre-rpgx and uses the transport/beam away function to switch between decks). It also supports larger maps like Atlantis, Station Iowa and the latest version of Station Modas without parse issues when multiple players join.

Don't get me wrong, i think ioEF is a great initiative an certainly worth it for those EF groups still active in clanning/fragging.
But for RP needs, extra stuff needs to be build in (to support the much more heavyer RP maps that are both larger and have more entities/functions then normal maps) which is currently a bit lacking in ioEF.

I don't get you wrong. I even encourage the development of a separate engine. It really makes sense for you. But that doesn't mean improvements made by both developers shouldn't flow between the two versions.

Big problem for me on EF (any version, not just ioEF) is that I'm running an ATI HD 4850X2 on my desktop. I get really low FPS on alot of maps
because ATI naffed up some opengl lecacy support in thier newer drivers. I had to fix this like described in this topic: http://last-outpost.net/forum/index.php?topic=1552.0

That's very interesting, because I would run into the same issue and I didn't know what caused it, but I always suspected driver issues. This practically confirms my suspicions. No, I don't think I will go down that avenue. However, the newer renderer might fix these issues with the ATI drivers. I'll try this later this week!

[Thilo]

I tested rpgxef yesterday, I have also got a few comments on it:

- rpgxef obviously uses libmysqlclient to connect to a mysql server. I guess pure clients don't need a mysql backend, so it might be good to build a client version that does not explicitly link against libmysqlclient, or that loads the library dynamically at runtime. Currently, Linux users will have to install libmysqlclient just to run this game. That's pretty ugly.

- The Windows version includes all libraries efrpgx depends on as DLLs. It might be more convenient to build static versions of these libraries and link them statically. But that's really a matter of taste.