[mitsubishi]

Rambetter, on 06 October 2009 - 09:43 PM, said:

suckiness of SVN

git is so beautiful; you don't even need a server to start off; just a .svn dir; it even has a built-in gui. user friendly from the beginning an extremely powerful since it handles thousands of editors communities.

[uJ|V00d00]

Rambetter, on 06 March 2010 - 09:33 PM, said:

MaJ has done something with the moderator stuff, but that change is not in this SVN repository. If you really want it, we can work on putting in the patch.

Yeah that moderator code would make sorting out low level admins a lot easier. If you could integrate it, that would be brilliant.

I wonder if FS would consider integrating it into 4.2 as well (unlikely), but it would be a better solution to ref, and would allow us to do away with B3 for admin levels.

TIA. :)

[Rambetter]

There is another exploit on the streets. I won't discuss it here to prevent script kiddies who aren't able to read source code from triggering this exploit. But some asshats have already triggered this exploit, so that is why I fixed it.

Update the SVN source code, read the logs, and read the source if you want. I did my best to make this a tidy change, but it is ugly in nature, because the problem really needs to be fixed in the game code, not in ioUrT. I'm pretty sure my fix in ioUrT will prevent the exploit from happening, but it does need more extensive testing.

Let me know if you can see a way to improve the fix.

[Rambetter]

I moved these repositories to my new server which has a purely public SVN repository. There is not longer a need to specify the username and password. I modified the original post to reflect this.

If you try to update an existing repository, you will get an SVN UUID mismatch (you know it when you see it). To get around this, you have to check out a fresh copy of the SVN project (just follow the instructions in the original post one more time).

This post has been edited by Rambetter: 31 March 2010 - 06:56 AM

[FS |HSO|RaideR]

V00d00, on 07 March 2010 - 01:28 PM, said:

Yeah that moderator code would make sorting out low level admins a lot easier. If you could integrate it, that would be brilliant.

I wonder if FS would consider integrating it into 4.2 as well (unlikely), but it would be a better solution to ref, and would allow us to do away with B3 for admin levels.

TIA. :)

I have read this. We use ioq3 for the most part, then modifyed by our Team sligthly (be it very slight), I can't make a choice because it is not my area. But since these are purely exploit fixes and NOT feature upgrades i don't see why it would be an issue.

The main issue i would have is with the moderator additions and weather or not the coders would include those. Anyway i have read this and i will make sure the team notice it. :D Cheers!

[Rambetter]

I don't recommend that any of these changes make it into 4.2. The exploit fixes are mostly just hacky workarounds for buggy QVM code. Well, the rcon flood exploit fix is actually specific to the ioquake3 code, not the QVM. So maybe you would want to take the rcon flood exploit fix and incorporate that into 4.2's ioquake3. That's only a couple of lines of code.

Like I said, these fixes address buggy QVM code. You should fix the QVM code for 4.2.

The extra-patches/ stuff is just extra that should definitely not make it into 4.2.

[voidref]

I made some changes to compile for mac x86_64 (the Make file and config haven't been updated for SnowLeopard, it seems).

When I try and exec server.cfg, it gets through a bunch of the qvm for urt and then barfs. I added some output to see what's happening and it looks like this:

<much snipped>

...
8, %r15
%r15
$8, %rsi
%rsi
4(%rsi), %eax
%eax
8(%rsi), %eax
%eax
i_00000009
$0, %rax
%rax
*rax
parsearg() - expected '%'
-> jmpq *rax

Is it possible I have a corrupted pac file? Or is there something else going wrong?

Thanks!

[MaJ]

Last I checked, older builds of ioQ3 (from 2007) weren't happy about 64-bit mac and FreeBSD. If I recall, the qvm was interpreted back at that time and it lead to some odd issues such as this.
This FreeBSD patch may do the trick for you: http://www.freebsd.o...r.cgi?pr=134874

If all else fails, pull a recent ioQ3 from their SVN and give it a try.

Also, I'd encourage you to build for x86 rather than x86_64 as 64-bit seems to have some performance issues.

[Rambetter]

MaJ, on 03 May 2010 - 07:37 AM, said:

Last I checked, older builds of ioQ3 (from 2007) weren't happy about 64-bit mac and FreeBSD. If I recall, the qvm was interpreted back at that time and it lead to some odd issues such as this.
This FreeBSD patch may do the trick for you: http://www.freebsd.o...r.cgi?pr=134874

If all else fails, pull a recent ioQ3 from their SVN and give it a try.

Also, I'd encourage you to build for x86 rather than x86_64 as 64-bit seems to have some performance issues.

Yes, try the patch mentioned above.

I would include this patch in my extra-patches/ directory, but I have no way to test it because I don't have a 64 bit FreeBSD or MacOSX machine available. I'd rather not include a patch in my SVN that I have not personally tested. But the above patch will almost certainly work.

[emanuele]

Hi to all.

I'd like to know if it is planned to fix "the Teamkill bug" in Urban Terror Server: even if I set g_maxteamkills variable to "4" and I set g_teamkillsforgettime variable to "300", when the kicked team killer player come back again, the server doesn't kick him anymore! It is a very annoying bug and I don't like to use BigBrother bot or any other else bot...

Please, can you consider to solve this particular bug?

Thanks.
Emanuele Bruno.