Messages

try now, it's fixed

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

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.

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

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.

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.

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.

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!

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.

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?

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.

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.

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.