rtcw linux - signal 11 in wolfmp

[pinkname Profile]

Yes, yes, it's out of question.

What I can't easily accept is why sp (and quite everything else) works while mp does not. So I invest _some_ time into it, and wrote here in the hope of getting ideas. :)

Whenever (if ever) the case gets solved I'll post back results.

Thanks again:

J.

[MAN-AT-ARMS]

I would guess either it comes down to getting a newer card that is still supported by the frglx driver, or downgrade to a distro with a kernel that supports the old frglx driver

[MAN-AT-ARMS]

You can also try using iortcw for single player.
I've had that running on gallium.

Here's some binaries for you to try:

http://stats.ecgnetwork.com/iortcw-SP.tar.gz

You just need to copy your pak0.pk3 and your sp_pak*.pk3's into the main folder.

[pinkname Profile]

Yes, but the question is why sp works, while mp does not. I repeat, sp (and everything else I tried including tuxracer :D) works flawlessly, wolfmp is the only thing I have issues with. I wouldn't think there are major differences between mp and sp engines, that's why I _feel_ the possibility of success somehow.

About changing hardware:

it's not a desktop but a postgres and ftp server using a quite complicated and already trusted setup. Having a GUI (btw limited to AGP) is just the topping on the cake, and quite noone cares about except me. :D Tampering with the hardware would mean giving up some of the hardly earned reliability factor (it serves clients since 2003). It used to work nicely with a gf3 that I could put in (without fears of troubles) instead of the x1600, but that barely produces 10 fps on assault (mkay, on beach 43 fps might work :D), making the whole change quite pointless. Maybe I could ruin the machine somehow to get a new one (don't tell anyone!) :D

J.

[MAN-AT-ARMS]

You already know what the issue is...the long extensions string bug

Sorry..I posted binaries for single player...I was confusing it with that other thread

[pinkname Profile]

Long extensions string bug? :o NO! Never heard of it. Yet! Thanks!

Now I googled a bit after it, it's a good idea to check, as I see it might even be possible to get things solved. (GL_ExtensionStringVersion is supported by mesa, woohoo!) If I understand it well at a first glance...


You just brought a new hope :D Yummy :)

thanks again:


J.

[MAN-AT-ARMS]

The bug is the GL extensions string is too long in newer drivers.

Basically the list of GL extensions has grown with each new version of OpenGL...and the driver reports which extensions it supports...that string is too long for the engine to handle. Older drivers worked because the list of extensions was shorter.

Nvidia drivers truncate that list so game still works...ATI doesn't. That's why the problem exists in ATI's (and apparently also the Gallium) driver.

There may be a way to set Gallium to truncate that list of GL extensions..Not sure. Haven't looked into it.


Here's iortcw binaries for multiplayer. This worked with Gallium when I briefly tested it. The extensions bug should be fixed in this but unfortunately there's no Punkbuster support because my engine updates are based off the GPL source which has no PB. Give this a try and see if this runs for you.

http://stats.ecgnetwork.com/iortcw-MP.tar.gz

[pinkname Profile]

Half dead in the middle of the night I've found this: http://www.mesa3d.org/envvars.html. I'll give a try on sunday night or monday, as I see MESA_EXTENSION_MAX_YEAR is just what I'm looking for.

BUT: how can I know if rly the fixed/too small buffer is the problem? Setting debuglog for rtcw showed nothing, nor mesa debuglog will show an error since it will properly give out the string to the app. (ofc. it will be a clear mark if the issue gets solved by it :D)

Do you know what the max length is (to compare the mesa given string against) or should I look it up in the rtcw sources?

______
iortcw: I'm very glad the project exists, much thanks for the efforts invested into it, I really appriciate it. But I don't (yet?) see how it could be used nowadays without punkbuster on the internet. I hope this will be solved some day, maybe having forks and issuing binaries for evenbalance is the future? I don't know. Is there any discussion about?

In a couple days I'll check iortcw (if it works or not with my setup) and truncating mesa variables.


thanks again:

J.

['L0, Profile]

In case if it helps, here's few solutions that were purposed (note they're for sp but may help):
http://ubuntuforums.org/archive/index.p ... 91932.html

The extension bug is the very first post. And yes, it's simple as hexing it out.

[Jun1oR]

In case if it helps, here's few solutions that were purposed (note they're for sp but may help):
http://ubuntuforums.org/archive/index.p ... 91932.html

The extension bug is the very first post. And yes, it's simple as hexing it out.

That fix only works for SP and he said his SP works fine. I have also given up on wolfmp on my linux install with my ATI card.

['L0, Profile]

I assume you tried this for mp then? Don't get me wrong, just asking so I know for next time as in past often people dismissed a lot of options without even trying.

P.S. I don't play 1.4 due ati crap either, so we're on same boat. ;)

[pinkname Profile]

Re :)

I would rather call that an ugly hack than a fix :D Forcing the binary to not check for gl extensions (but produce another error instead? :o) doesn't seem a viable way to solve anything (also pb will kick in), but it might be good for testing if I'm having the buffer issue or something completely different. Since sp works nicely for me, I'm not yet convinced of anything, so I check whatever comes up. I'll try this too, won't take long :D. Didn't do so yet, because the attached forum deals with quite different troubles. However going the "mesa way" seems to be much cleaner, might give a proper solution.

Anyhow, atm I have quite different priorities, I'm getting burnt on a real beach, will return tomorrow evening (CET) :)

Thanks again for the ideas, whatever they might be.

J.

[MAN-AT-ARMS]

The hack is not forcing it to not check for extensions. It's just not printing them out in full in the console.

If there is an option in MESA to truncate the list by year, I would prefer that myself.

Let me know how you make out with that.

[pinkname Profile]

UPDATE:

It looks like I'm not having the buffer issue:

- tried the mesa way first, glxinfo shows the truncating itself works, but my wolfmp has the same symptoms
- tried the hack, nothing changed
- tried iortcw (without any magic), UI starts without errors. When starting a nondedicated server I got the unpure client - invalid pk3 error. (It's not related to the signal 11 issues anyhow)

About the hex hack: thanks for clarifying, I wouldn't have thought it's just for the display in shell :) (even if %s is quite clear :D)

BUT: for those mesa users who can't use rtcw just because of not being able to truncate the list, the solution is dead simple:

type "MESA_EXTENSION_MAX_YEAR=2001" in the shell before running rtcw. You can do this system wide by exporting it (or including in /etc/profile, or ~/.bash_profile if you use such things): "export MESA_EXTENSION_MAX_YEAR=2001".

You can also experiment as documented at http://www.mesa3d.org/envvars.html.


Still looking for ideas... :D


thanks:

J.

[MAN-AT-ARMS]

In iortcw, you probably got the unpure error if you have the original mp_bin.pk3 file in your main folder. You would only need that if you are connecting to a pure server.

As far as your regular wolfmp problem, please post the output of the console to pastebin or slexy (with and without +developer 1)