The Last Outpost

Member Services => Engineering => Resolved Support Requests => Topic started by: Thilo on August 02, 2011, 11:16:55 PM

Title: ioEF 1.38 test version + windows x64 build
Post by: Thilo on August 02, 2011, 11:16:55 PM
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 (//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 (//http://www.ioquake3.org) into an Elite Force engine.

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


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/iostvoyHM-1.38_rc1.x86.exe)
http://thilo.kickchat.com/efport-progress/bin/win32/renderer_opengl1_x86.dll (//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/iostvoyHM-1.38_rc1.x64.exe)
http://thilo.kickchat.com/efport-progress/bin/win64/SDL64.dll (//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/OpenAL32.dll)
http://thilo.kickchat.com/efport-progress/bin/win64/renderer_opengl1_x64.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/iostvoyHM-1.38_rc1.i386)
http://thilo.kickchat.com/efport-progress/bin/linux/renderer_opengl1_i386.so (//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/iostvoyHM-1.38_rc1.x86_64)
http://thilo.kickchat.com/efport-progress/bin/linux/renderer_opengl1_x86_64.so (//http://thilo.kickchat.com/efport-progress/bin/linux/renderer_opengl1_x86_64.so)


If you encounter any bugs, please report them here.
Title: Re: ioEF 1.38 test version + windows x64 build
Post by: Veritas on August 02, 2011, 11:23:15 PM
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 :D. 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?
Title: Re: ioEF 1.38 test version + windows x64 build
Post by: Thilo on August 02, 2011, 11:33:36 PM
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 (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.
Title: Re: ioEF 1.38 test version + windows x64 build
Post by: Veritas on August 02, 2011, 11:35:42 PM
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.
Title: Re: ioEF 1.38 test version + windows x64 build
Post by: Thilo on August 02, 2011, 11:41:25 PM
Quote from: "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.

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.
Title: Re: ioEF 1.38 test version + windows x64 build
Post by: Thilo on August 02, 2011, 11:51:29 PM
Quote from: "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.

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?
Title: Re: ioEF 1.38 test version + windows x64 build
Post by: Veritas on August 02, 2011, 11:53:20 PM
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.

QuoteIf 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 :P
Title: Re: ioEF 1.38 test version + windows x64 build
Post by: Thilo on August 03, 2011, 12:05:22 AM
Quote from: "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.

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

QuoteWhen 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

QuoteLike 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.

QuoteIt 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 :P

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.
Title: Re: ioEF 1.38 test version + windows x64 build
Post by: Veritas on August 03, 2011, 12:15:06 AM
QuoteThat'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.
Title: Re: ioEF 1.38 test version + windows x64 build
Post by: Martin Thompson on August 03, 2011, 05:15:07 AM
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!

QuoteThirdly, 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 (//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 :P) 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 :P 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 (//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 :P
Title: Re: ioEF 1.38 test version + windows x64 build
Post by: Brex on August 03, 2011, 05:30:40 AM
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 :)
Title: Re: ioEF 1.38 test version + windows x64 build
Post by: Martin Thompson on August 03, 2011, 06:12:43 AM
Ah yeah, so thats a ioCow only cvar then. Maybe ioEF can use somethign similar?
Title: Re: ioEF 1.38 test version + windows x64 build
Post by: Brex on August 03, 2011, 06:16:37 AM
ioEF does use it, it just doesn't work in the same way (in that it doesn't work at all :P)

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.
Title: Re: ioEF 1.38 test version + windows x64 build
Post by: Thilo on August 03, 2011, 06:38:59 AM
Quote from: "Martin Thompson"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.

QuoteAs 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.

QuoteAs 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.

QuoteBig 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 (//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!
Title: Re: ioEF 1.38 test version + windows x64 build
Post by: Thilo on August 03, 2011, 06:48:03 AM
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.
Title: Re: ioEF 1.38 test version + windows x64 build
Post by: GSIO01 on August 03, 2011, 07:14:12 AM
Hey Thilo,

it's nice to see a new version of ioEF released and especially to have a new patch for ioquake 3. That'll make it a lot easier to get an updated version of rpgxEF done. I'm also happy to hear that the renderer modularization is finally there and I'm looking forward to the modern rendering techniques being implemented in future.

As to your question what I had to do to fix the mentioned errors. To fix them I had to increase MAX_GAMESTATE_CHARS and as a result of that of course MAX_CONFIGSTRINGS and MAX_MSGLEN as well. I increased MAX_MODELS and the entity limit later. I also and added shader remapping.

And just to clear things up for you other people the Lua implementation in RPG-X does not require rpgxEF at all as it is completely implemented in the gamecode. The only reason why it is only available for the rpgxEF right now is that I'm a bit too lazy to release  betas for both vEF/ioEF/ioCow and rpgxEF.

EDIT:
You're right about libmysql. I have already planned to remove mysql from rpgxEF in the next update though so that'll fix that.
Title: Re: ioEF 1.38 test version + windows x64 build
Post by: Thilo on August 03, 2011, 07:28:31 AM
Quote from: "GSIO01"it's nice to see a new version of ioEF released and especially to have a new patch for ioquake 3. That'll make it a lot easier to get an updated version of rpgxEF done. I'm also happy to hear that the renderer modularization is finally there and I'm looking forward to the modern rendering techniques being implemented in future.

Yes. I suggest you make a diff between your rpgxEF codebase and the ioEF codebase with my patches. This way you can always do this:
get ioq3 codebase
- apply my ioEF patch
- apply your rpgxEF patch

QuoteAs to your question what I had to do to fix the mentioned errors. To fix them I had to increase MAX_GAMESTATE_CHARS and as a result of that of course MAX_CONFIGSTRINGS and MAX_MSGLEN as well. I increased MAX_MODELS and the entity limit later. I also and added shader remapping.

Yes, the shader remapping is probably useful for rpgx. I am unsure as to what bug is fixed by changing these defines:
MAX_GAMESTATE_CHARS, MAX_CONFIGSTRINGS and MAX_MSGLEN.
This looks like a compatibility breaker to me. Isn't there another way around this? For instance, split gamestate messages and put the rest into DeltaGamestate messages

QuoteEDIT:
You're right about libmysql. I have already planned to remove mysql from rpgxEF in the next update though so that'll fix that.

Alrighty.
Any word on how you fixed the hmconfig overwrite issue? This might be an issue for ioquake3 as well. By the way, it's been fixed that a single shader can break all other shaders. This was one of the big issues the old ioEF had, I believe.
Title: Re: ioEF 1.38 test version + windows x64 build
Post by: Martin Thompson on August 03, 2011, 09:39:04 AM
Yeah, I also dont like the 20 or so .dll files you get with rpgxef, but thats GSIO01's decision. Besides rpgxef is really under "constant development". All releases should be considered as beta as far as I am aware anyway. Maybe the dlls are all seperate so that it is compatible on all systems (linux, windows, mac)? I don't really know lol.

Thanks for your feedback on my comments. As far as the fs_homepath goes, I never actually set it manually, I just use the default (like many other people who don't even know the cvar exists). Maybe its a thought of setting that to a different location in ioEF by default? I don't know what the default is, im assuming its the location in AppData. Anyway, a fix for the config file deletion/overwriting would be great.

QuoteI 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.

Yeah, I agree. Maybe you should have a talk with GSIO01 then, he's around here somewhere...

EDIT: I posted this before I saw your 2 latest posts, stupid me XD Anyway seems you already met :P

QuoteBy the way, it's been fixed that a single shader can break all other shaders. This was one of the big issues the old ioEF had, I believe.

Yup, this could happen. I don't know if this is already fixed in rpgxef, I know of a few people not being able to laod Station Vanderbilt (a rpgxef map) due to some texture/shader error. I dont know if this is related though.
Title: Re: ioEF 1.38 test version + windows x64 build
Post by: GSIO01 on August 04, 2011, 03:36:04 AM
I haven't fixed that config issue but was told in my bugtracker that the error message
Quotebuf_InsertText overflowed
get thrown out. When I read this my guess was it might be that the RPG-X configs have become to big with all the new we cvars added over the time. Haven't had enough time so I delayed research on that.

By the way have you fixed GF_RANDOM so it works correct? It never worked as in vEF ... if not you might be interested about my changes to it just let me know.

EDIT: Thilo you should check the rights for the patches ... 403 ... just noticed when I was trying to download them.
Title: Re: ioEF 1.38 test version + windows x64 build
Post by: Thilo on August 05, 2011, 07:52:37 AM
try now, it's fixed
Title: Re: ioEF 1.38 test version + windows x64 build
Post by: GSIO01 on October 12, 2011, 07:47:02 AM
Fine thanks.

Umm this might be my fault but I think I better mention it anyway:
Is it possible that your patch is missing the snd_codec_mp3.c source file? Because I did a fresh ioquake3 checkout and applied the patch and it isn't there.
I'm using the old one from 1.37 for now.