[ericcmi]

./ioUrT_diRf-smp.i386: /lib/i686/cmov/libm.so.6: version `GLIBC_2.15' not found (required by ./ioUrT_diRf-smp.i386)
./ioUrT_diRf-smp.i386: /lib/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by ./ioUrT_diRf-smp.i386)

I can't figure out which packages I need. Any thoughts? I'm on the latest stable debian. I get the same error with BOTH binaries, smp and the other one. I don't know the difference.

Thanks in advance,
tardfarmer

SOLVED! Compiled it for myself and it works perfectly. libc6 on debian is too old. Even the testing version.

This post has been edited by ericcmi: 07 August 2012 - 06:38 PM

[iLag]

ericcmi, on 07 August 2012 - 05:29 PM, said:

./ioUrT_diRf-smp.i386: /lib/i686/cmov/libm.so.6: version `GLIBC_2.15' not found (required by ./ioUrT_diRf-smp.i386)
./ioUrT_diRf-smp.i386: /lib/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by ./ioUrT_diRf-smp.i386)

I can't figure out which packages I need. Any thoughts? I'm on the latest stable debian. I get the same error with BOTH binaries, smp and the other one. I don't know the difference.

Thanks in advance,
tardfarmer

Let me guess: you're on 64-bit. Looks like you'll need libc6-i386 and possibly other 32-bit libraries. Alternatively, you can compile from source into native 64-bit code, but you'd be better off getting the i386 version of the libraries you need.

[ericcmi]

iLag, on 07 August 2012 - 05:55 PM, said:

Let me guess: you're on 64-bit. Looks like you'll need libc6-i386 and possibly other 32-bit libraries. Alternatively, you can compile from source into native 64-bit code, but you'd be better off getting the i386 version of the libraries you need.

Thanks, I'm all 32bit here. My libc6 is too old. Compiled for myself and it works perfectly.

[|P|Nitro]

strata, on 07 August 2012 - 06:47 AM, said:

NOTE: Due to controversy surrounding the "disable ambient background noise" feature, these binaries have no such capability!

I thank you good sir!

strata, on 07 August 2012 - 05:26 PM, said:

No. We don't plan on adding it at this time because - as mentioned in the thread Attackxie deleted - it has not been part of the plans for this project. This is not Mitsubishi's bloatimized build. :)

does this build include bumpy/simpleshaders? and if not raw mouse support what about dmaHD's mouse support? and finally is mouse buttons 4/5 work on this build?

[Ikslorin]

Found a bug : When using the normal client, will the Auth recognize my account ... when using this build, will the server respond with "no account".

I can log in on the main menu without any problems, but the server can't "see" me.

This post has been edited by Ikslorin: 07 August 2012 - 08:43 PM

[strata]

Ikslorin, on 07 August 2012 - 08:41 PM, said:

Found a bug : When using the normal client, will the Auth recognize my account ... when using this build, will the server respond with "no account".

I can log in on the main menu without any problems, but the server can't "see" me.

See my earlier post about this. You might have to manually edit your authkey file to get it to work. I'm still trying to solve this problem.

Here's a screenshot to show that it is somewhat working. As far as servers are concerned, I thought nobody was using Auth yet? Wasn't it causing server crashes?

http://i.imgur.com/77C0X.jpg

[[T]BludShoT]

strata, on 07 August 2012 - 05:26 PM, said:

it is rumored that butthurt rape victim league admins are trying to come up with ways to detect non-vanilla clients and ban them.

Totally ridiculous, unless you are talking about some euro leagues or something, I don't know what their thoughts are.

I have no interest in banning non-vanilla clients for the sake of them being non-vanilla clients. Sacc stuff is an attempt at improvements for all. But who would want to allow clients which allow you to cheat in audio or graphical ways? Sure, they are "fair", because everyone can get them, so that's fair. But that means we are allowing the game to be modified down to some kind of lowest common denominator, and forcing all players to move to that or put themselves at a disadvantage. Try to put your arrogance on hold for 2 seconds and think of the big picture instead of only your narrow view.

[strata]

BludShoT, on 07 August 2012 - 10:37 PM, said:

Totally ridiculous, unless you are talking about some euro leagues or something, I don't know what their thoughts are.

I have no interest in banning non-vanilla clients for the sake of them being non-vanilla clients. Sacc stuff is an attempt at improvements for all. But who would want to allow clients which allow you to cheat in audio or graphical ways? Sure, they are "fair", because everyone can get them, so that's fair. But that means we are allowing the game to be modified down to some kind of lowest common denominator, and forcing all players to move to that or put themselves at a disadvantage. Try to put your arrogance on hold for 2 seconds and think of the big picture instead of only your narrow view.

My view is this (like it or not): What diRf is doing with ambient sound removal is not cheating. This is not a wallhack/aimbot. And if you tried with this feature, you would realize that not hearing ambient sounds is moot. q3a and urt stem from an 'open to experimentation' community. And I AGREE that these types of "hacks" should not be acceptable in league play because they could create an unfair advantage. The binaries released yesterday do not contain these so called "cheats" (which are NOT cheats btw)

All of this is in fun and desire to explore new ideas. If you don't like it, use the stock client and quit bitching. I'm not removing this feature, period. But I feel I have made a kind gesture by not releasing binaries with said feature included and leave it up to anyone who wishes to have it to figure it out on their own.

And to answer your question about being arrogant. YES. narrow-viewed? Not in the least. I'm not the one trying to start a crusade against "hacky" clients here, YOU are.

[undead]

strata, on 07 August 2012 - 05:26 PM, said:

Here's what we're doing: We follow the ioquake3 trunk for the most part - but there's two people, myself and sudoking, working on it so sometimes things might get missed. On top of that there are tweaks for UrT, sacc, dmaHD, some caching, and the controversial "ambient noise" hack. So to answer your question about 'how pristine is this compared to 4.2?': Probably at least 3 years of changes between the ioquake3 FS is using vs. SVN 2304 which we are "loosely" based on. So e.g. the Auth System had to be ported in.

It has a lot more changes than needed when I go through the list. If you set LEGACY_PROTOCOL and STANDALONE, you don't need to remove a lot of code that the official UrT client does. Upstream ioquake3 made it much cleaner to have a standalone game. The official UrT client is too old to have those changes.

Could you have the plain 4.2 changes enabled by default and #ifdef protect the others? That way people can define what they want in Makefile.local.

I noticed some parts had #ifdef but others didn't. For instance, the SACC part is enabled by default. Speaking of SACC. Is it really necessary to rename all of the cvars to have a sacc_ prefix?

Someone asked about bumpy. Since the latest ioquake3 has a modular renderer, you could easily add a second renderer that supports bumpy along with the default. You can switch between them at runtime. However, I don't recommend it since bumpy isn't being maintained.

What I did for my 4.1 client was go through all of frozen sand's changes in their tarball. They had a mixture of SVN versions and things that weren't necessary so I made it as small of a diff as possible. I think a client that tracks the latest ioquake3 like yours may want to do a similar task. It sucks, but at least you know all of the changes are looked at.

My post before was deleted, but if anyone is interested, here's how you can see what changed in diRf compared to upstream ioquake3:

$ git clone git://github.com/urtdevs/diRf_client.git
$ cd diRf_client
$ git remote add upstream git://github.com/undeadzy/ioquake3_mirror.git
$ git fetch upstream
$ git diff upstream/master

I try to keep ioquake3_mirror up to date via 'git svn rebase'. I don't make any changes to that repo. It's all identical to upstream.

[strata]

undead, on 07 August 2012 - 11:15 PM, said:

It has a lot more changes than needed when I go through the list. If you set LEGACY_PROTOCOL and STANDALONE, you don't need to remove a lot of code that the official UrT client does. Upstream ioquake3 made it much cleaner to have a standalone game. The official UrT client is too old to have those changes.

Yep. Been using the LEGACY_PROTOCOL :)

undead, on 07 August 2012 - 11:15 PM, said:

Could you have the plain 4.2 changes enabled by default and #ifdef protect the others? That way people can define what they want in Makefile.local.

The last commit i made was moving in that direction because it doesn't make sense to run two separate branches for 4.1 and 4.2. see URT42

undead, on 07 August 2012 - 11:15 PM, said:

I noticed some parts had #ifdef but others didn't. For instance, the SACC part is enabled by default. Speaking of SACC. Is it really necessary to rename all of the cvars to have a sacc_ prefix?

The cvars were renamed because a few months ago, slackin requested that I keep them because he keeps track of sacc users via pugbot. (userinfo strings)

undead, on 07 August 2012 - 11:15 PM, said:

Someone asked about bumpy. Since the latest ioquake3 has a modular renderer, you could easily add a second renderer that supports bumpy along with the default. You can switch between them at runtime. However, I don't recommend it since bumpy isn't being maintained.

Hence the reason, no bumpy. However, USE_RENDERER_DLOPEN will allow anyone to easily swap it out, yes.

undead, on 07 August 2012 - 11:15 PM, said:

What I did for my 4.1 client was go through all of frozen sand's changes in their tarball. They had a mixture of SVN versions and things that weren't necessary so I made it as small of a diff as possible. I think a client that tracks the latest ioquake3 like yours may want to do a similar task. It sucks, but at least you know all of the changes are looked at.

My post before was deleted, but if anyone is interested, here's how you can see what changed in diRf compared to upstream ioquake3:

$ git clone git://github.com/urtdevs/diRf_client.git
$ cd diRf_client
$ git remote add upstream git://github.com/undeadzy/ioquake3_mirror.git
$ git fetch upstream
$ git diff upstream/master

I try to keep ioquake3_mirror up to date via 'git svn rebase'. I don't make any changes to that repo. It's all identical to upstream.

Because I'm a git noob, this all started with a diff between ioUrbanTerror_2007 - I don't remember what SVN of ioquake3 it was based on (at the time I did lol) - and ioquake3. Then manually hacked it into ioquake3 trunk, added sacc and dmaHD. Then I realized that there needs to be a way to keep track of all these changes. I'm doing my best. Could always use more help! :S