From ceccato at itc.it  Fri May 11 10:16:28 2007
From: ceccato at itc.it (Mariano Ceccato)
Date: Fri, 11 May 2007 16:16:28 +0200
Subject: non-cheatable game
Message-ID: <46447ABC.9070305@itc.it>

Hello everybody,

I'm an Italian researcher working in the field of software analysis and 
evolution.

The topic my group is currently working on is a related to software 
security on network applications. Out goal is to identify which parts of 
an existing software system can be tampered with by a malicious user. We 
are also investigating a solution based on source-code automatic 
transformation to change all the not-safe parts into tamper-proof code.

In case of a network game, such as Quake, we would like to modify the 
game code in such a way that it is not longer possible by a malicious 
player to install cheat-patch on the system in order to gain an 
advantage over the other players.

Of course my purpose is to write good research publications but, I 
think, I can also contribute a lot to this project in case I will be 
able to provide you non-cheatable game source code.

To do that, I would need to know
1) the known cheat-patches that unfair players use,
2) kind of game design (if any)
3) game (and game-server) code
Could someone help me in find out any of those things?

Regards,

-- 
Mariano Ceccato
ITC-Irst
Via Sommarive, 18
I-38050 Povo, Trento - ITALY
email: ceccato at itc.it
web: http://sra.itc.it/people/ceccato
tel: +39.0461.314.577
fax: +39.0461.314.591


------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------


From diego1609 at gmail.com  Fri May 11 11:54:58 2007
From: diego1609 at gmail.com (Diego de Estrada)
Date: Fri, 11 May 2007 12:54:58 -0300
Subject: [quake3] non-cheatable game
In-Reply-To: <46447ABC.9070305@itc.it>
References: <46447ABC.9070305@itc.it>
Message-ID: <5dc44ec70705110854v5e9f6fc1y4d72c7e4a47f06d9@mail.gmail.com>

2) Read van Waveren master thesis:
http://www.kbs.twi.tudelft.nl/Publications/MSc/2001-VanWaveren-MSc.html

3) Here: http://ioquake3.org/?page=get

The current purpose of the ioquake3 project is to keep network
compatability with Id's binaries, maybe not a very clever idea taking
into account that the design is ten years old (although novel for that
time).

Maybe, IMHO, it's time to redesign some of the network code, and
implement it in SDL_net.

On 5/11/07, Mariano Ceccato <ceccato at itc.it> wrote:
> Hello everybody,
>
> I'm an Italian researcher working in the field of software analysis and
> evolution.
>
> The topic my group is currently working on is a related to software
> security on network applications. Out goal is to identify which parts of
> an existing software system can be tampered with by a malicious user. We
> are also investigating a solution based on source-code automatic
> transformation to change all the not-safe parts into tamper-proof code.
>
> In case of a network game, such as Quake, we would like to modify the
> game code in such a way that it is not longer possible by a malicious
> player to install cheat-patch on the system in order to gain an
> advantage over the other players.
>
> Of course my purpose is to write good research publications but, I
> think, I can also contribute a lot to this project in case I will be
> able to provide you non-cheatable game source code.
>
> To do that, I would need to know
> 1) the known cheat-patches that unfair players use,
> 2) kind of game design (if any)
> 3) game (and game-server) code
> Could someone help me in find out any of those things?
>
> Regards,
>
> --
> Mariano Ceccato
> ITC-Irst
> Via Sommarive, 18
> I-38050 Povo, Trento - ITALY
> email: ceccato at itc.it
> web: http://sra.itc.it/people/ceccato
> tel: +39.0461.314.577
> fax: +39.0461.314.591
>
>
> ------------------
> ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
> ITC -> since 1 March 2007 Fondazione Bruno Kessler
> ------------------
>


From expressvps at verizon.net  Sat May 12 13:42:19 2007
From: expressvps at verizon.net (Chris Bunting)
Date: Sat, 12 May 2007 13:42:19 -0400
Subject: Help moving dlls from baseq3 to ioquake3/ directory.
Message-ID: <001901c794bc$e391bc90$2f01a8c0@tosha418b8ca6b>

Hello,

I've been trying to find out where the reference is that calls for the game .dll's to be in the baseq3/ directory. I would like to have these in the main directory like the openal.dll.

/ioquake3/
   |-- cgamex86.dll
   |-- qagamex86.dll
   |-- uix86.dll
   |-- OpenAL32.dll

Not sure if that will look the same but that is what I'm trying to do.

Thanks,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/quake3/attachments/20070512/b90cc058/attachment.htm>

From expressvps at verizon.net  Sat May 12 13:59:53 2007
From: expressvps at verizon.net (Chris Bunting)
Date: Sat, 12 May 2007 13:59:53 -0400
Subject: [quake3] Help moving dlls from baseq3 to ioquake3/ directory.
References: <001901c794bc$e391bc90$2f01a8c0@tosha418b8ca6b>
Message-ID: <000801c794bf$57cd5f90$2f01a8c0@tosha418b8ca6b>

Hello,

Never mind.. I figured it out.. All that needs to be done is to just copy them over. Which also, with them being in the root directory of ioquake3 fixed the resolution issues with the main menu now as well.

Thanks,
Chris
  ----- Original Message ----- 
  From: Chris Bunting 
  To: quake3 at icculus.org 
  Sent: Saturday, May 12, 2007 1:42 PM
  Subject: [quake3] Help moving dlls from baseq3 to ioquake3/ directory.


  Hello,

  I've been trying to find out where the reference is that calls for the game .dll's to be in the baseq3/ directory. I would like to have these in the main directory like the openal.dll.

  /ioquake3/
     |-- cgamex86.dll
     |-- qagamex86.dll
     |-- uix86.dll
     |-- OpenAL32.dll

  Not sure if that will look the same but that is what I'm trying to do.

  Thanks,
  Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/quake3/attachments/20070512/317cbb4c/attachment.htm>

From defsyn at gmail.com  Sat May 12 14:00:31 2007
From: defsyn at gmail.com (Henry Garcia)
Date: Sat, 12 May 2007 14:00:31 -0400
Subject: [quake3] Help moving dlls from baseq3 to ioquake3/ directory.
In-Reply-To: <001901c794bc$e391bc90$2f01a8c0@tosha418b8ca6b>
References: <001901c794bc$e391bc90$2f01a8c0@tosha418b8ca6b>
Message-ID: <a387ed40705121100r47dc0256k3fc39b8f307c20be@mail.gmail.com>

When you can write the code, then you can decide where to put the dll's. I
would assume that the ioquake3.x86.exe expects the dlls to be in a certain
place. You move them around, and the program won't run.
But all the user should do is edit his Makefile to point to the destination
where he wants the compiled executable and libraries to be installed.

ifndef COPYDIR
> COPYDIR="/c/Q3Ademo"
> endif


Alter the COPYDIR to  match where you have your program installed: e.g.
/c/Program Files/Quake III Arena"

And then run Make copyfiles

That should install the executables and the dll's in their proper places.






On 5/12/07, Chris Bunting <expressvps at verizon.net> wrote:
>
>  Hello,
>
> I've been trying to find out where the reference is that calls for the
> game .dll's to be in the baseq3/ directory. I would like to have these in
> the main directory like the openal.dll.
>
> /ioquake3/
>    |-- cgamex86.dll
>    |-- qagamex86.dll
>    |-- uix86.dll
>    |-- OpenAL32.dll
>
> Not sure if that will look the same but that is what I'm trying to do.
>
> Thanks,
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/quake3/attachments/20070512/bdabfe58/attachment.htm>

From expressvps at verizon.net  Sun May 13 03:49:27 2007
From: expressvps at verizon.net (Chris Bunting)
Date: Sun, 13 May 2007 03:49:27 -0400
Subject: [quake3] Help moving dlls from baseq3 to ioquake3/ directory.
References: <001901c794bc$e391bc90$2f01a8c0@tosha418b8ca6b> <a387ed40705121100r47dc0256k3fc39b8f307c20be@mail.gmail.com>
Message-ID: <001b01c79533$3c66a8a0$2f01a8c0@tosha418b8ca6b>

Hello,

What I was looking for is in, ui_main.c, q_shared.h and cg_main.c 

Thanks,
Chris
  ----- Original Message ----- 
  From: Henry Garcia 
  To: quake3 at icculus.org 
  Sent: Saturday, May 12, 2007 2:00 PM
  Subject: Re: [quake3] Help moving dlls from baseq3 to ioquake3/ directory.


  When you can write the code, then you can decide where to put the dll's. I would assume that the ioquake3.x86.exe expects the dlls to be in a certain place. You move them around, and the program won't run. 
  But all the user should do is edit his Makefile to point to the destination where he wants the compiled executable and libraries to be installed. 


    ifndef COPYDIR
    COPYDIR="/c/Q3Ademo"
    endif

  Alter the COPYDIR to  match where you have your program installed: e.g. /c/Program Files/Quake III Arena"

  And then run Make copyfiles

  That should install the executables and the dll's in their proper places. 








  On 5/12/07, Chris Bunting <expressvps at verizon.net> wrote:
    Hello,

    I've been trying to find out where the reference is that calls for the game .dll's to be in the baseq3/ directory. I would like to have these in the main directory like the openal.dll.

    /ioquake3/
       |-- cgamex86.dll
       |-- qagamex86.dll
       |-- uix86.dll
       |-- OpenAL32.dll

    Not sure if that will look the same but that is what I'm trying to do.

    Thanks,
    Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/quake3/attachments/20070513/176dc4f5/attachment.htm>

From ceccato at itc.it  Mon May 14 06:04:58 2007
From: ceccato at itc.it (Mariano Ceccato)
Date: Mon, 14 May 2007 12:04:58 +0200
Subject: [quake3] non-cheatable game
In-Reply-To: <5dc44ec70705110854v5e9f6fc1y4d72c7e4a47f06d9@mail.gmail.com>
References: <46447ABC.9070305@itc.it> <5dc44ec70705110854v5e9f6fc1y4d72c7e4a47f06d9@mail.gmail.com>
Message-ID: <4648344A.3000608@itc.it>

Dear Diego,

thanks for the reference. Do you know this person? could you provide his 
current e-mail so I can contact him, in case?

Thanks a lot,
Mariano Ceccato



Diego de Estrada wrote:
> 2) Read van Waveren master thesis:
> http://www.kbs.twi.tudelft.nl/Publications/MSc/2001-VanWaveren-MSc.html
>
> 3) Here: http://ioquake3.org/?page=get
>
> The current purpose of the ioquake3 project is to keep network
> compatability with Id's binaries, maybe not a very clever idea taking
> into account that the design is ten years old (although novel for that
> time).
>
> Maybe, IMHO, it's time to redesign some of the network code, and
> implement it in SDL_net.
>
> On 5/11/07, Mariano Ceccato <ceccato at itc.it> wrote:
>> Hello everybody,
>>
>> I'm an Italian researcher working in the field of software analysis and
>> evolution.
>>
>> The topic my group is currently working on is a related to software
>> security on network applications. Out goal is to identify which parts of
>> an existing software system can be tampered with by a malicious user. We
>> are also investigating a solution based on source-code automatic
>> transformation to change all the not-safe parts into tamper-proof code.
>>
>> In case of a network game, such as Quake, we would like to modify the
>> game code in such a way that it is not longer possible by a malicious
>> player to install cheat-patch on the system in order to gain an
>> advantage over the other players.
>>
>> Of course my purpose is to write good research publications but, I
>> think, I can also contribute a lot to this project in case I will be
>> able to provide you non-cheatable game source code.
>>
>> To do that, I would need to know
>> 1) the known cheat-patches that unfair players use,
>> 2) kind of game design (if any)
>> 3) game (and game-server) code
>> Could someone help me in find out any of those things?
>>
>> Regards,
>>
>> -- 
>> Mariano Ceccato
>> ITC-Irst
>> Via Sommarive, 18
>> I-38050 Povo, Trento - ITALY
>> email: ceccato at itc.it
>> web: http://sra.itc.it/people/ceccato
>> tel: +39.0461.314.577
>> fax: +39.0461.314.591
>>
>>
>> ------------------
>> ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
>> ITC -> since 1 March 2007 Fondazione Bruno Kessler
>> ------------------
>>


-- 
Mariano Ceccato
ITC-Irst
Via Sommarive, 18
I-38050 Povo, Trento - ITALY
email: ceccato at itc.it
web: http://sra.itc.it/people/ceccato
tel: +39.0461.314.577
fax: +39.0461.314.591


------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------


From mike at hobbshouse.org  Mon May 14 15:03:19 2007
From: mike at hobbshouse.org (Mike Hobbs)
Date: Mon, 14 May 2007 14:03:19 -0500
Subject: [quake3] non-cheatable game
In-Reply-To: <46447ABC.9070305@itc.it>
References: <46447ABC.9070305@itc.it>
Message-ID: <4648B277.5000402@hobbshouse.org>

I don't mean to throw cold water on your research and I don't know what 
your proposed approach is, but I'm 99.999% certain that it is impossible 
to absolutely prevent cheating on any system that the cheater has 
indiscriminate physical access to. (As an aside, this is one reason why 
DRM will never be effective on consumer devices.) Access to the source 
code makes it very easy to cheat, but even without access to the code, a 
hacker with a decompiler can do a lot. Even if you encrypt the binary 
and all messages into and out of it, the secret will have to be decoded 
and into the client's memory at some point. A hacker can then inject 
whatever he wants at that point.

 From a different perspective, it is possible for a server to ban a 
client that it "suspects" is cheating, but there is no way to absolutely 
prevent it in the first place.

- Mike

Mariano Ceccato wrote:
> Hello everybody,
>
> I'm an Italian researcher working in the field of software analysis 
> and evolution.
>
> The topic my group is currently working on is a related to software 
> security on network applications. Out goal is to identify which parts 
> of an existing software system can be tampered with by a malicious 
> user. We are also investigating a solution based on source-code 
> automatic transformation to change all the not-safe parts into 
> tamper-proof code.
>
> In case of a network game, such as Quake, we would like to modify the 
> game code in such a way that it is not longer possible by a malicious 
> player to install cheat-patch on the system in order to gain an 
> advantage over the other players.
>
> Of course my purpose is to write good research publications but, I 
> think, I can also contribute a lot to this project in case I will be 
> able to provide you non-cheatable game source code.
>
> To do that, I would need to know
> 1) the known cheat-patches that unfair players use,
> 2) kind of game design (if any)
> 3) game (and game-server) code
> Could someone help me in find out any of those things?
>
> Regards,
>



From expressvps at verizon.net  Mon May 14 18:03:10 2007
From: expressvps at verizon.net (Chris Bunting)
Date: Mon, 14 May 2007 18:03:10 -0400
Subject: [quake3] non-cheatable game
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org>
Message-ID: <000601c79673$a97dae20$2f01a8c0@tosha418b8ca6b>

Hello,

 Aside from PunkBuster or BattleEye, This is the only other anti-cheat 
program that I know of. It seems to have been created for quake 3 but it 
looks like it can be modified to work with Q3.

http://antiche.at/

Chris


----- Original Message ----- 
From: "Mike Hobbs" <mike at hobbshouse.org>
To: <quake3 at icculus.org>
Sent: Monday, May 14, 2007 3:03 PM
Subject: Re: [quake3] non-cheatable game


>I don't mean to throw cold water on your research and I don't know what 
>your proposed approach is, but I'm 99.999% certain that it is impossible to 
>absolutely prevent cheating on any system that the cheater has 
>indiscriminate physical access to. (As an aside, this is one reason why DRM 
>will never be effective on consumer devices.) Access to the source code 
>makes it very easy to cheat, but even without access to the code, a hacker 
>with a decompiler can do a lot. Even if you encrypt the binary and all 
>messages into and out of it, the secret will have to be decoded and into 
>the client's memory at some point. A hacker can then inject whatever he 
>wants at that point.
>
> From a different perspective, it is possible for a server to ban a client 
> that it "suspects" is cheating, but there is no way to absolutely prevent 
> it in the first place.
>
> - Mike
>
> Mariano Ceccato wrote:
>> Hello everybody,
>>
>> I'm an Italian researcher working in the field of software analysis and 
>> evolution.
>>
>> The topic my group is currently working on is a related to software 
>> security on network applications. Out goal is to identify which parts of 
>> an existing software system can be tampered with by a malicious user. We 
>> are also investigating a solution based on source-code automatic 
>> transformation to change all the not-safe parts into tamper-proof code.
>>
>> In case of a network game, such as Quake, we would like to modify the 
>> game code in such a way that it is not longer possible by a malicious 
>> player to install cheat-patch on the system in order to gain an advantage 
>> over the other players.
>>
>> Of course my purpose is to write good research publications but, I think, 
>> I can also contribute a lot to this project in case I will be able to 
>> provide you non-cheatable game source code.
>>
>> To do that, I would need to know
>> 1) the known cheat-patches that unfair players use,
>> 2) kind of game design (if any)
>> 3) game (and game-server) code
>> Could someone help me in find out any of those things?
>>
>> Regards,
>>
> 



From azog at bellsouth.net  Mon May 14 22:24:18 2007
From: azog at bellsouth.net (David Jackson)
Date: Mon, 14 May 2007 21:24:18 -0500
Subject: [quake3] non-cheatable game
In-Reply-To: <4648B277.5000402@hobbshouse.org>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org>
Message-ID: <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net>


This is untrue, on many levels.  It is a software engineering  
problem; admittedly, a very hefty one, but it can be done.

At it's very core, you have to be able to protect your program code  
and program data.  A good start would be to -not- use dynamically- 
linked libraries.

David Jackson

On May 14, 2007, at 2:03 PM, Mike Hobbs wrote:

> I don't mean to throw cold water on your research and I don't know  
> what your proposed approach is, but I'm 99.999% certain that it is  
> impossible to absolutely prevent cheating on any system that the  
> cheater has indiscriminate physical access to. (As an aside, this  
> is one reason why DRM will never be effective on consumer devices.)  
> Access to the source code makes it very easy to cheat, but even  
> without access to the code, a hacker with a decompiler can do a  
> lot. Even if you encrypt the binary and all messages into and out  
> of it, the secret will have to be decoded and into the client's  
> memory at some point. A hacker can then inject whatever he wants at  
> that point.
>
> From a different perspective, it is possible for a server to ban a  
> client that it "suspects" is cheating, but there is no way to  
> absolutely prevent it in the first place.
>
> - Mike
>




From theorem21 at gmail.com  Mon May 14 23:51:13 2007
From: theorem21 at gmail.com (Theorem)
Date: Mon, 14 May 2007 23:51:13 -0400
Subject: [quake3] non-cheatable game
In-Reply-To: <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org> <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net>
Message-ID: <46492E31.2080306@gmail.com>

I disagree.  This is exactly the DRM problem, at some point in time you're going 
to have to present it to the user, that's the whole point.

The definition of cheating I use is "to deceive or influence by fraud".

	This can be done many, many ways, software is one attack vector, hardware is 
yet another.  This is why "if you can touch it, you can hack it" is a security 
mantra.  M. Hobbs eludes to this with "..indiscriminate physical access".

	Even assuming your software IS foolproof you rely on the hardware to make it 
happen, which is tainted the instant anyone has physical access. You're missing 
a large point here because you trust the hardware.  Regardless if it "would be 
difficult to do" to hack your game in hardware I have no doubt it could be done. 
  If not to inject code/control characters, then to make a physical robot move 
the mouse,press keys, etc all for the user's enjoyment.

	As a further aside, if you have root access you'll always be able to get at the 
memory addresses of whatever is running.  Using an OS that doesn't allow you to 
do that is a slippery slope and you no longer own this device.

As an academic exercise I'm sure you can improve the security of the system to 
an acceptable level, but you will never be able to make the game non-cheatable.

Have fun :),
Theorem

David Jackson wrote:
> 
> This is untrue, on many levels.  It is a software engineering problem; 
> admittedly, a very hefty one, but it can be done.
> 
> At it's very core, you have to be able to protect your program code and 
> program data.  A good start would be to -not- use dynamically-linked 
> libraries.
> 
> David Jackson
> 
> On May 14, 2007, at 2:03 PM, Mike Hobbs wrote:
> 
>> I don't mean to throw cold water on your research and I don't know 
>> what your proposed approach is, but I'm 99.999% certain that it is 
>> impossible to absolutely prevent cheating on any system that the 
>> cheater has indiscriminate physical access to. (As an aside, this is 
>> one reason why DRM will never be effective on consumer devices.) 
>> Access to the source code makes it very easy to cheat, but even 
>> without access to the code, a hacker with a decompiler can do a lot. 
>> Even if you encrypt the binary and all messages into and out of it, 
>> the secret will have to be decoded and into the client's memory at 
>> some point. A hacker can then inject whatever he wants at that point.
>>
>> From a different perspective, it is possible for a server to ban a 
>> client that it "suspects" is cheating, but there is no way to 
>> absolutely prevent it in the first place.
>>
>> - Mike


From tw3k.net at gmail.com  Tue May 15 00:58:00 2007
From: tw3k.net at gmail.com (~tw3k!)
Date: Tue, 15 May 2007 00:58:00 -0400
Subject: [quake3] non-cheatable game
In-Reply-To: <46492E31.2080306@gmail.com>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org> <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net> <46492E31.2080306@gmail.com>
Message-ID: <4EA6CD5A-D9AB-41E8-917D-771C1A764905@gmail.com>

man in the middle attack?

On May 14, 2007, at 11:51 PM, Theorem wrote:

> I disagree.  This is exactly the DRM problem, at some point in time  
> you're going to have to present it to the user, that's the whole  
> point.
>
> The definition of cheating I use is "to deceive or influence by  
> fraud".
>
> 	This can be done many, many ways, software is one attack vector,  
> hardware is yet another.  This is why "if you can touch it, you can  
> hack it" is a security mantra.  M. Hobbs eludes to this with  
> "..indiscriminate physical access".
>
> 	Even assuming your software IS foolproof you rely on the hardware  
> to make it happen, which is tainted the instant anyone has physical  
> access. You're missing a large point here because you trust the  
> hardware.  Regardless if it "would be difficult to do" to hack your  
> game in hardware I have no doubt it could be done.  If not to  
> inject code/control characters, then to make a physical robot move  
> the mouse,press keys, etc all for the user's enjoyment.
>
> 	As a further aside, if you have root access you'll always be able  
> to get at the memory addresses of whatever is running.  Using an OS  
> that doesn't allow you to do that is a slippery slope and you no  
> longer own this device.
>
> As an academic exercise I'm sure you can improve the security of  
> the system to an acceptable level, but you will never be able to  
> make the game non-cheatable.
>
> Have fun :),
> Theorem
>
> David Jackson wrote:
>> This is untrue, on many levels.  It is a software engineering  
>> problem; admittedly, a very hefty one, but it can be done.
>> At it's very core, you have to be able to protect your program  
>> code and program data.  A good start would be to -not- use  
>> dynamically-linked libraries.
>> David Jackson
>> On May 14, 2007, at 2:03 PM, Mike Hobbs wrote:
>>> I don't mean to throw cold water on your research and I don't  
>>> know what your proposed approach is, but I'm 99.999% certain that  
>>> it is impossible to absolutely prevent cheating on any system  
>>> that the cheater has indiscriminate physical access to. (As an  
>>> aside, this is one reason why DRM will never be effective on  
>>> consumer devices.) Access to the source code makes it very easy  
>>> to cheat, but even without access to the code, a hacker with a  
>>> decompiler can do a lot. Even if you encrypt the binary and all  
>>> messages into and out of it, the secret will have to be decoded  
>>> and into the client's memory at some point. A hacker can then  
>>> inject whatever he wants at that point.
>>>
>>> From a different perspective, it is possible for a server to ban  
>>> a client that it "suspects" is cheating, but there is no way to  
>>> absolutely prevent it in the first place.
>>>
>>> - Mike

Forest
http://tw3k.net




From diego1609 at gmail.com  Tue May 15 01:00:01 2007
From: diego1609 at gmail.com (Diego de Estrada)
Date: Tue, 15 May 2007 02:00:01 -0300
Subject: [quake3] non-cheatable game
In-Reply-To: <46492E31.2080306@gmail.com>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org>
	 <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net>
	 <46492E31.2080306@gmail.com>
Message-ID: <5dc44ec70705142200q5221d557w4556581fd2d65f4c@mail.gmail.com>

You are missing the point, this has nothing to do with DRM.
This is not security through obscurity. Here the "root" guy is the
server, not the clients.
A bulletproof system is possible, but not easy:

* Direct access to network data comming from the server must not give
any advantage to the client.
Example: instead of the server telling the client "an enemy is behind
the wall" so that he can hear the foot steps, it's better to say
directly "foot steps comming from that direction".
This makes wall hack a dull boy.

* A "lie" comming from a client should be detected if and only if it
gives him any advantage.
Example: it's easy to detect a too fast walking or movement of the
camera, so speed hack and auto aim, to some point, are detectable.

Anyway, it's clear that somebody can create something that plays
excellent without trespassing the limits. I call it a bot, and
fighting with them is meaningless. Even so, the quality of their play
is somewhat an evidence of us being closer to Turing's dream.

On 5/15/07, Theorem <theorem21 at gmail.com> wrote:
> I disagree.  This is exactly the DRM problem, at some point in time you're going
> to have to present it to the user, that's the whole point.
>
> The definition of cheating I use is "to deceive or influence by fraud".
>
>         This can be done many, many ways, software is one attack vector, hardware is
> yet another.  This is why "if you can touch it, you can hack it" is a security
> mantra.  M. Hobbs eludes to this with "..indiscriminate physical access".
>
>         Even assuming your software IS foolproof you rely on the hardware to make it
> happen, which is tainted the instant anyone has physical access. You're missing
> a large point here because you trust the hardware.  Regardless if it "would be
> difficult to do" to hack your game in hardware I have no doubt it could be done.
>   If not to inject code/control characters, then to make a physical robot move
> the mouse,press keys, etc all for the user's enjoyment.
>
>         As a further aside, if you have root access you'll always be able to get at the
> memory addresses of whatever is running.  Using an OS that doesn't allow you to
> do that is a slippery slope and you no longer own this device.
>
> As an academic exercise I'm sure you can improve the security of the system to
> an acceptable level, but you will never be able to make the game non-cheatable.
>
> Have fun :),
> Theorem
>
> David Jackson wrote:
> >
> > This is untrue, on many levels.  It is a software engineering problem;
> > admittedly, a very hefty one, but it can be done.
> >
> > At it's very core, you have to be able to protect your program code and
> > program data.  A good start would be to -not- use dynamically-linked
> > libraries.
> >
> > David Jackson
> >
> > On May 14, 2007, at 2:03 PM, Mike Hobbs wrote:
> >
> >> I don't mean to throw cold water on your research and I don't know
> >> what your proposed approach is, but I'm 99.999% certain that it is
> >> impossible to absolutely prevent cheating on any system that the
> >> cheater has indiscriminate physical access to. (As an aside, this is
> >> one reason why DRM will never be effective on consumer devices.)
> >> Access to the source code makes it very easy to cheat, but even
> >> without access to the code, a hacker with a decompiler can do a lot.
> >> Even if you encrypt the binary and all messages into and out of it,
> >> the secret will have to be decoded and into the client's memory at
> >> some point. A hacker can then inject whatever he wants at that point.
> >>
> >> From a different perspective, it is possible for a server to ban a
> >> client that it "suspects" is cheating, but there is no way to
> >> absolutely prevent it in the first place.
> >>
> >> - Mike
>


From tim at ngus.net  Tue May 15 04:23:59 2007
From: tim at ngus.net (Tim Angus)
Date: Tue, 15 May 2007 09:23:59 +0100
Subject: non-cheatable game
In-Reply-To: <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org> <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net>
Message-ID: <46496E1F.7030900@ngus.net>

David Jackson wrote:
> This is untrue, on many levels.

No, it's entirely true. You can't prevent cheating in online games. You 
can possibly put protection in place which makes it harder to cheat, and 
you can potentially detect when unsophisticated cheats are being used, 
but there is no global panacea that will ever prevent cheating. Get over it.


From kloppenburg at snt.utwente.nl  Tue May 15 06:35:07 2007
From: kloppenburg at snt.utwente.nl (Erik Kloppenburg)
Date: Tue, 15 May 2007 12:35:07 +0200
Subject: [quake3] Re: non-cheatable game
In-Reply-To: <46496E1F.7030900@ngus.net>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org> <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net> <46496E1F.7030900@ngus.net>
Message-ID: <46498CDB.4070907@snt.utwente.nl>

Tim Angus wrote:
> David Jackson wrote:
>> This is untrue, on many levels.
> 
> No, it's entirely true. You can't prevent cheating in online games.

I agree. It's not just hard, but it's 100% impossible. Everything 
running on a PC has to be understood by the machine, so it can be 
understood by humans too. For example, making an aimbot is ALWAYS 
possible. Even if the code is somehow obscured or whatever... If needed, 
one could point a webcam at the screen, and write a piece of software 
the recognizes enemies. This software is hooked up to a machine that 
auto-aims the mouse at the enemies. How the hell are you going to 
prevent that?


From baztheallmighty at hotmail.com  Tue May 15 08:03:59 2007
From: baztheallmighty at hotmail.com (baz theallmighty)
Date: Tue, 15 May 2007 12:03:59 +0000
Subject: [quake3] Re: non-cheatable game
In-Reply-To: <46498CDB.4070907@snt.utwente.nl>
Message-ID: <BAY127-F73C2509B72CA5B5534454A83D0@phx.gbl>

There is no way to prevent cheating. You can minimize it with patch's and 
anti-hax programs but that is about it.

On to more practical matters.

Well here is the start of the anti hax stuff(stops most aim bots that have a 
hard coded "+attack" )

http://www.quakesrc.org/forums/viewtopic.php?t=7525&postdays=0&postorder=asc&start=0

Anyone care to make it so that old bots can't hook into the engine(without a 
recompile of the bot)?
Maybe even do this in the cgame section of the code or have any idea how to?



"I don't play q3"

*points finger*

*releases bloodcurdling shriek*

_________________________________________________________________
Advertisement: Your Future Starts Here. Dream it? Then be it! Find it at 
www.seek.com.au 
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2F%3Ftracking%3Dsk%3Ahet%3Ask%3Anine%3A0%3Ahot%3Atext&_t=763838044&_r=seek_may07_futurestartshere&_m=EXT



From mike at hobbshouse.org  Tue May 15 10:46:16 2007
From: mike at hobbshouse.org (Mike Hobbs)
Date: Tue, 15 May 2007 09:46:16 -0500
Subject: [quake3] non-cheatable game
In-Reply-To: <5dc44ec70705142200q5221d557w4556581fd2d65f4c@mail.gmail.com>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org>	 <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net>	 <46492E31.2080306@gmail.com> <5dc44ec70705142200q5221d557w4556581fd2d65f4c@mail.gmail.com>
Message-ID: <4649C7B8.5070801@hobbshouse.org>

I guess it does all come down to the meaning of "cheat" as Theorem 
mentions below. For example, even in a game such as chess or go, where 
the entire state of the system is known to all players, I would consider 
it cheating if one player was using software that "thinks ahead" for him.

On a related but more practical level, there exist several types of 
poker bots that will play poker for you on many of the on-line gambling 
sites. That is certainly considered cheating by the other participants, 
even though there is no patching or hacking going on.

- Mike

Diego de Estrada wrote:
> You are missing the point, this has nothing to do with DRM.
> This is not security through obscurity. Here the "root" guy is the
> server, not the clients.
> A bulletproof system is possible, but not easy:
>
> * Direct access to network data comming from the server must not give
> any advantage to the client.
> Example: instead of the server telling the client "an enemy is behind
> the wall" so that he can hear the foot steps, it's better to say
> directly "foot steps comming from that direction".
> This makes wall hack a dull boy.
>
> * A "lie" comming from a client should be detected if and only if it
> gives him any advantage.
> Example: it's easy to detect a too fast walking or movement of the
> camera, so speed hack and auto aim, to some point, are detectable.
>
> Anyway, it's clear that somebody can create something that plays
> excellent without trespassing the limits. I call it a bot, and
> fighting with them is meaningless. Even so, the quality of their play
> is somewhat an evidence of us being closer to Turing's dream.
>
> On 5/15/07, Theorem <theorem21 at gmail.com> wrote:
>> I disagree.  This is exactly the DRM problem, at some point in time 
>> you're going
>> to have to present it to the user, that's the whole point.
>>
>> The definition of cheating I use is "to deceive or influence by fraud".
>>
>>         This can be done many, many ways, software is one attack 
>> vector, hardware is
>> yet another.  This is why "if you can touch it, you can hack it" is a 
>> security
>> mantra.  M. Hobbs eludes to this with "..indiscriminate physical 
>> access".
>>
>>         Even assuming your software IS foolproof you rely on the 
>> hardware to make it
>> happen, which is tainted the instant anyone has physical access. 
>> You're missing
>> a large point here because you trust the hardware.  Regardless if it 
>> "would be
>> difficult to do" to hack your game in hardware I have no doubt it 
>> could be done.
>>   If not to inject code/control characters, then to make a physical 
>> robot move
>> the mouse,press keys, etc all for the user's enjoyment.
>>
>>         As a further aside, if you have root access you'll always be 
>> able to get at the
>> memory addresses of whatever is running.  Using an OS that doesn't 
>> allow you to
>> do that is a slippery slope and you no longer own this device.
>>
>> As an academic exercise I'm sure you can improve the security of the 
>> system to
>> an acceptable level, but you will never be able to make the game 
>> non-cheatable.
>>
>> Have fun :),
>> Theorem
>>
>> David Jackson wrote:
>> >
>> > This is untrue, on many levels.  It is a software engineering problem;
>> > admittedly, a very hefty one, but it can be done.
>> >
>> > At it's very core, you have to be able to protect your program code 
>> and
>> > program data.  A good start would be to -not- use dynamically-linked
>> > libraries.
>> >
>> > David Jackson
>> >
>> > On May 14, 2007, at 2:03 PM, Mike Hobbs wrote:
>> >
>> >> I don't mean to throw cold water on your research and I don't know
>> >> what your proposed approach is, but I'm 99.999% certain that it is
>> >> impossible to absolutely prevent cheating on any system that the
>> >> cheater has indiscriminate physical access to. (As an aside, this is
>> >> one reason why DRM will never be effective on consumer devices.)
>> >> Access to the source code makes it very easy to cheat, but even
>> >> without access to the code, a hacker with a decompiler can do a lot.
>> >> Even if you encrypt the binary and all messages into and out of it,
>> >> the secret will have to be decoded and into the client's memory at
>> >> some point. A hacker can then inject whatever he wants at that point.
>> >>
>> >> From a different perspective, it is possible for a server to ban a
>> >> client that it "suspects" is cheating, but there is no way to
>> >> absolutely prevent it in the first place.
>> >>
>> >> - Mike
>>



From prefect_ at gmx.net  Tue May 15 12:08:52 2007
From: prefect_ at gmx.net (Nicolai =?iso-8859-1?q?H=E4hnle?=)
Date: Tue, 15 May 2007 18:08:52 +0200
Subject: [quake3] Re: non-cheatable game
In-Reply-To: <46496E1F.7030900@ngus.net>
References: <46447ABC.9070305@itc.it> <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net> <46496E1F.7030900@ngus.net>
Message-ID: <200705151808.53384.prefect_@gmx.net>

On Tuesday 15 May 2007 10:23:59 Tim Angus wrote:
> David Jackson wrote:
> > This is untrue, on many levels.
>
> No, it's entirely true. You can't prevent cheating in online games. You
> can possibly put protection in place which makes it harder to cheat, and
> you can potentially detect when unsophisticated cheats are being used,
> but there is no global panacea that will ever prevent cheating. Get over
> it.

I've always felt it useful classify cheats into different "cheat types" to 
make statements that are more precise than a simple "you can't prevent 
cheating". I prefer a classification into:

1) Game mechanics cheat
This is the kind of cheat that hacks the underlying "physics" part of the 
rules of a game world. Classic examples would be things like god mode, 
flying, increased speed, infinite resources, quicker building speed in RTS 
games, breaking the rules in chess, etc.

2) Knowledge cheat
This kind of cheat reveals some knowledge to the player that is expected to be 
hidden. Examples would include wall hacks, lifting "fog of war" in RTS, 
knowing the resource amounts available to opponents, etc.

3) Skill cheat / Doping
This kind of cheat enhances the player's natural abilities, such as her 
dexterity or problem solving skills. Examples would be aimbots or a chess 
computer that a player uses to calculate her next move.

Game mechanics cheats are easily stopped in client-server architectures (just 
verify everything on the server).

You can make Doping difficult, but you can never stop it completely. Period. 
As somebody mentioned in this thread already, a player could (in the extreme 
case) build a robot that connects to the keyboard and monitor and does the 
playing for him.

Knowledge cheats are a grey area. In theory, they can be stopped entirely in a 
client-server architecture by streaming the entire audio and video output in 
real-time from server to client. However, this is prohibitively expensive, 
and completely undesirable for twitch games due to latency issues that simply 
cannot be solved (speed of light, and all that). So in practice, one has to 
find a reasonable balance in what is exposed to the client.

~Nicolai


From ceccato at itc.it  Tue May 15 12:32:36 2007
From: ceccato at itc.it (Mariano Ceccato)
Date: Tue, 15 May 2007 18:32:36 +0200
Subject: [quake3] Re: non-cheatable game
In-Reply-To: <200705151808.53384.prefect_@gmx.net>
References: <46447ABC.9070305@itc.it> <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net> <46496E1F.7030900@ngus.net> <200705151808.53384.prefect_@gmx.net>
Message-ID: <4649E0A4.20101@itc.it>

Dear Nicolai,

I found your classification very useful to focus the effort of 
anti-cheating.
I also think that different classes of cheat require different approaches.

Regards,
Mariano

Nicolai H?hnle wrote:
> On Tuesday 15 May 2007 10:23:59 Tim Angus wrote:
>  > David Jackson wrote:
>  > > This is untrue, on many levels.
>  >
>  > No, it's entirely true. You can't prevent cheating in online games. You
>  > can possibly put protection in place which makes it harder to cheat, and
>  > you can potentially detect when unsophisticated cheats are being used,
>  > but there is no global panacea that will ever prevent cheating. Get over
>  > it.
>
> I've always felt it useful classify cheats into different "cheat types" to
> make statements that are more precise than a simple "you can't prevent
> cheating". I prefer a classification into:
>
> 1) Game mechanics cheat
> This is the kind of cheat that hacks the underlying "physics" part of the
> rules of a game world. Classic examples would be things like god mode,
> flying, increased speed, infinite resources, quicker building speed in RTS
> games, breaking the rules in chess, etc.
>
> 2) Knowledge cheat
> This kind of cheat reveals some knowledge to the player that is expected to be
> hidden. Examples would include wall hacks, lifting "fog of war" in RTS,
> knowing the resource amounts available to opponents, etc.
>
> 3) Skill cheat / Doping
> This kind of cheat enhances the player's natural abilities, such as her
> dexterity or problem solving skills. Examples would be aimbots or a chess
> computer that a player uses to calculate her next move.
>
> Game mechanics cheats are easily stopped in client-server architectures (just
> verify everything on the server).
>
> You can make Doping difficult, but you can never stop it completely. Period.
> As somebody mentioned in this thread already, a player could (in the extreme
> case) build a robot that connects to the keyboard and monitor and does the
> playing for him.
>
> Knowledge cheats are a grey area. In theory, they can be stopped entirely in a
> client-server architecture by streaming the entire audio and video output in
> real-time from server to client. However, this is prohibitively expensive,
> and completely undesirable for twitch games due to latency issues that simply
> cannot be solved (speed of light, and all that). So in practice, one has to
> find a reasonable balance in what is exposed to the client.
>
> ~Nicolai
>
>   


-- 
Mariano Ceccato
ITC-Irst
Via Sommarive, 18
I-38050 Povo, Trento - ITALY
email: ceccato at itc.it
web: http://sra.itc.it/people/ceccato
tel: +39.0461.314.577
fax: +39.0461.314.591


------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------


From mike at hobbshouse.org  Tue May 15 13:14:00 2007
From: mike at hobbshouse.org (Mike Hobbs)
Date: Tue, 15 May 2007 12:14:00 -0500
Subject: [quake3] Re: non-cheatable game
In-Reply-To: <4649E0A4.20101@itc.it>
References: <46447ABC.9070305@itc.it> <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net> <46496E1F.7030900@ngus.net> <200705151808.53384.prefect_@gmx.net> <4649E0A4.20101@itc.it>
Message-ID: <4649EA58.7080008@hobbshouse.org>

At the end of the day, I've always figured that the best cheat deterrent 
on-line is also the best cheat deterrent off-line: good identification. 
That is, in the real world, if you know someone who often deals from the 
bottom of the deck or nudges chess pieces when you aren't looking, you 
stop playing with her and she soon finds herself rather alone. The 
problem on-line is that you can't often tell that the newbie named 
"dred" is the same player that you played against last week that was 
obviously using an aimbot, but was then named "fang". When there is good 
on-line identification, such as on Ebay, you see less cheating than you 
would otherwise expect.

BTW, good identification doesn't necessarily require revealing your 
name, address, and social security number. It only requires identifying 
repeat players as being the same person.

- Mike


From azog at bellsouth.net  Tue May 15 14:33:52 2007
From: azog at bellsouth.net (David Jackson)
Date: Tue, 15 May 2007 13:33:52 -0500
Subject: [quake3] non-cheatable game
In-Reply-To: <46492E31.2080306@gmail.com>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org> <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net> <46492E31.2080306@gmail.com>
Message-ID: <D9554C3B-3B94-4418-8D5D-2A03913B5D47@bellsouth.net>


I always worry about absolute statements like "this can never be done".

You have to look beyond conventional methods of memory mapping, and  
program code/program data organization.

I'm not going to dig into it, it's far too lengthy for this forum,  
but it is entirely possible to obfuscate it at many levels.  The  
question becomes more what tradeoffs you are willing to accept.

David Jackson

On May 14, 2007, at 10:51 PM, Theorem wrote:

> I disagree.  This is exactly the DRM problem, at some point in time  
> you're going to have to present it to the user, that's the whole  
> point.
>
> The definition of cheating I use is "to deceive or influence by  
> fraud".
>
> 	This can be done many, many ways, software is one attack vector,  
> hardware is yet another.  This is why "if you can touch it, you can  
> hack it" is a security mantra.  M. Hobbs eludes to this with  
> "..indiscriminate physical access".
>
> 	Even assuming your software IS foolproof you rely on the hardware  
> to make it happen, which is tainted the instant anyone has physical  
> access. You're missing a large point here because you trust the  
> hardware.  Regardless if it "would be difficult to do" to hack your  
> game in hardware I have no doubt it could be done.  If not to  
> inject code/control characters, then to make a physical robot move  
> the mouse,press keys, etc all for the user's enjoyment.
>
> 	As a further aside, if you have root access you'll always be able  
> to get at the memory addresses of whatever is running.  Using an OS  
> that doesn't allow you to do that is a slippery slope and you no  
> longer own this device.
>
> As an academic exercise I'm sure you can improve the security of  
> the system to an acceptable level, but you will never be able to  
> make the game non-cheatable.
>
> Have fun :),
> Theorem
>
> David Jackson wrote:
>> This is untrue, on many levels.  It is a software engineering  
>> problem; admittedly, a very hefty one, but it can be done.
>> At it's very core, you have to be able to protect your program  
>> code and program data.  A good start would be to -not- use  
>> dynamically-linked libraries.
>> David Jackson
>> On May 14, 2007, at 2:03 PM, Mike Hobbs wrote:
>>> I don't mean to throw cold water on your research and I don't  
>>> know what your proposed approach is, but I'm 99.999% certain that  
>>> it is impossible to absolutely prevent cheating on any system  
>>> that the cheater has indiscriminate physical access to. (As an  
>>> aside, this is one reason why DRM will never be effective on  
>>> consumer devices.) Access to the source code makes it very easy  
>>> to cheat, but even without access to the code, a hacker with a  
>>> decompiler can do a lot. Even if you encrypt the binary and all  
>>> messages into and out of it, the secret will have to be decoded  
>>> and into the client's memory at some point. A hacker can then  
>>> inject whatever he wants at that point.
>>>
>>> From a different perspective, it is possible for a server to ban  
>>> a client that it "suspects" is cheating, but there is no way to  
>>> absolutely prevent it in the first place.
>>>
>>> - Mike



From azog at bellsouth.net  Tue May 15 14:38:30 2007
From: azog at bellsouth.net (David Jackson)
Date: Tue, 15 May 2007 13:38:30 -0500
Subject: [quake3] Re: non-cheatable game
In-Reply-To: <46496E1F.7030900@ngus.net>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org> <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net> <46496E1F.7030900@ngus.net>
Message-ID: <BC7F4454-199A-4522-A2BC-85C3AE07F653@bellsouth.net>


I think your response went bad right at "get over it", which is not  
an argument.

It's a software engineering problem, which requires innovation and  
"thinking outside of the box".  It is entirely possible, but it begs  
the question of whether or not it's worth it.

Stop trying to be insulting.


On May 15, 2007, at 3:23 AM, Tim Angus wrote:

> David Jackson wrote:
>> This is untrue, on many levels.
>
> No, it's entirely true. You can't prevent cheating in online games.  
> You can possibly put protection in place which makes it harder to  
> cheat, and you can potentially detect when unsophisticated cheats  
> are being used, but there is no global panacea that will ever  
> prevent cheating. Get over it.



From daniellord at mac.com  Tue May 15 14:40:47 2007
From: daniellord at mac.com (Daniel Lord)
Date: Tue, 15 May 2007 11:40:47 -0700
Subject: [quake3] non-cheatable game
In-Reply-To: <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org> <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net>
Message-ID: <0BA16E1D-A290-4F8F-94FA-8B736AAF615E@mac.com>


David Jackson wrote:

> At it's very core, you have to be able to protect your program code  
> and program data.  A good start would be to -not- use dynamically- 
> linked libraries.

Then there goes extensibility (mods, characters, map updates, etc)  
and with it upgrade revenue. That's commercially inviable out of the  
gate.
And even so, a clever hacker to document all entry points and patch  
the code anyway.


mike at hobbshouse.org wrote:

> At the end of the day, I've always figured that the best cheat  
> deterrent on-line is also the best cheat deterrent off-line: good  
> identification.

I think that's why Microsoft uses more rigid identification regimes  
on Xbox Live.
They also cut down on cheating by keeping the hardware platform  
constant and unchangeable (mostly).

I am reminded by the parallels to freedom in society: the more  
individual freedom one has, the more responsibility to behave morally  
and the greater the temptation and opportunity not to.
Microsoft has instituted a more totalitarian police-stat of on-line  
gaming. It reduces cheating substantially, but carries with it many  
costs.

For my part, I think ultimately Mike has the right idea: the more  
community and publicity a game provides players, the less their  
anonymity and the better their behavior.

Even major league baseball players (not to single out baseball), who  
many (thought not I) view as heroes, cheat if they think their  
behavior is in the shadows (Sammy Sosa, Barry Bonds, Pete Rose, Jose  
Canseco, and many, many more). There will always be cheaters. Rather  
than try to create a system you can trust implicitly, keep everything  
public and banish the cheaters.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/quake3/attachments/20070515/40352741/attachment.htm>

From mike at hobbshouse.org  Tue May 15 14:45:58 2007
From: mike at hobbshouse.org (Mike Hobbs)
Date: Tue, 15 May 2007 13:45:58 -0500
Subject: [quake3] non-cheatable game
In-Reply-To: <D9554C3B-3B94-4418-8D5D-2A03913B5D47@bellsouth.net>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org> <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net> <46492E31.2080306@gmail.com> <D9554C3B-3B94-4418-8D5D-2A03913B5D47@bellsouth.net>
Message-ID: <4649FFE6.8020302@hobbshouse.org>

Until the CPU can perform arithmetic with encrypted data in its 
registers, and the encryption key is 100% unreadable from memory, disk, 
network, and EEPROM, I remain skeptical that anything is hacker-proof.

- Mike


David Jackson wrote:
>
> I always worry about absolute statements like "this can never be done".
>
> You have to look beyond conventional methods of memory mapping, and 
> program code/program data organization.
>
> I'm not going to dig into it, it's far too lengthy for this forum, but 
> it is entirely possible to obfuscate it at many levels.  The question 
> becomes more what tradeoffs you are willing to accept.
>
> David Jackson
>
> On May 14, 2007, at 10:51 PM, Theorem wrote:
>
>> I disagree.  This is exactly the DRM problem, at some point in time 
>> you're going to have to present it to the user, that's the whole point.
>>
>> The definition of cheating I use is "to deceive or influence by fraud".
>>
>>     This can be done many, many ways, software is one attack vector, 
>> hardware is yet another.  This is why "if you can touch it, you can 
>> hack it" is a security mantra.  M. Hobbs eludes to this with 
>> "..indiscriminate physical access".
>>
>>     Even assuming your software IS foolproof you rely on the hardware 
>> to make it happen, which is tainted the instant anyone has physical 
>> access. You're missing a large point here because you trust the 
>> hardware.  Regardless if it "would be difficult to do" to hack your 
>> game in hardware I have no doubt it could be done.  If not to inject 
>> code/control characters, then to make a physical robot move the 
>> mouse,press keys, etc all for the user's enjoyment.
>>
>>     As a further aside, if you have root access you'll always be able 
>> to get at the memory addresses of whatever is running.  Using an OS 
>> that doesn't allow you to do that is a slippery slope and you no 
>> longer own this device.
>>
>> As an academic exercise I'm sure you can improve the security of the 
>> system to an acceptable level, but you will never be able to make the 
>> game non-cheatable.
>>
>> Have fun :),
>> Theorem
>>
>> David Jackson wrote:
>>> This is untrue, on many levels.  It is a software engineering 
>>> problem; admittedly, a very hefty one, but it can be done.
>>> At it's very core, you have to be able to protect your program code 
>>> and program data.  A good start would be to -not- use 
>>> dynamically-linked libraries.
>>> David Jackson
>>> On May 14, 2007, at 2:03 PM, Mike Hobbs wrote:
>>>> I don't mean to throw cold water on your research and I don't know 
>>>> what your proposed approach is, but I'm 99.999% certain that it is 
>>>> impossible to absolutely prevent cheating on any system that the 
>>>> cheater has indiscriminate physical access to. (As an aside, this 
>>>> is one reason why DRM will never be effective on consumer devices.) 
>>>> Access to the source code makes it very easy to cheat, but even 
>>>> without access to the code, a hacker with a decompiler can do a 
>>>> lot. Even if you encrypt the binary and all messages into and out 
>>>> of it, the secret will have to be decoded and into the client's 
>>>> memory at some point. A hacker can then inject whatever he wants at 
>>>> that point.
>>>>
>>>> From a different perspective, it is possible for a server to ban a 
>>>> client that it "suspects" is cheating, but there is no way to 
>>>> absolutely prevent it in the first place.
>>>>
>>>> - Mike
>



From linuxmanmikec at gmail.com  Tue May 15 15:02:09 2007
From: linuxmanmikec at gmail.com (LinuxManMikeC)
Date: Tue, 15 May 2007 15:02:09 -0400
Subject: [quake3] non-cheatable game
In-Reply-To: <D9554C3B-3B94-4418-8D5D-2A03913B5D47@bellsouth.net>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org>
	 <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net>
	 <46492E31.2080306@gmail.com>
	 <D9554C3B-3B94-4418-8D5D-2A03913B5D47@bellsouth.net>
Message-ID: <4561ec380705151202w368ffeedvdb2e8a2f4db193b2@mail.gmail.com>

Whatever you make, someone can break.  Its just a question of how
difficult you make it for them to break.  Hence, "you will never be
able to make the game non-cheatable".  You can only make it extremely
difficult to cheat, or make it infeasible to even attempt cheating for
a considerable length of time.  But if you really have such profound
knowledge of how to do this, why not go create it, become a
billionaire, and make us all eat our hats?

Mike

On 5/15/07, David Jackson <azog at bellsouth.net> wrote:
>
> I always worry about absolute statements like "this can never be done".
>
> You have to look beyond conventional methods of memory mapping, and
> program code/program data organization.
>
> I'm not going to dig into it, it's far too lengthy for this forum,
> but it is entirely possible to obfuscate it at many levels.  The
> question becomes more what tradeoffs you are willing to accept.
>
> David Jackson
>
> On May 14, 2007, at 10:51 PM, Theorem wrote:
>
> > I disagree.  This is exactly the DRM problem, at some point in time
> > you're going to have to present it to the user, that's the whole
> > point.
> >
> > The definition of cheating I use is "to deceive or influence by
> > fraud".
> >
> >       This can be done many, many ways, software is one attack vector,
> > hardware is yet another.  This is why "if you can touch it, you can
> > hack it" is a security mantra.  M. Hobbs eludes to this with
> > "..indiscriminate physical access".
> >
> >       Even assuming your software IS foolproof you rely on the hardware
> > to make it happen, which is tainted the instant anyone has physical
> > access. You're missing a large point here because you trust the
> > hardware.  Regardless if it "would be difficult to do" to hack your
> > game in hardware I have no doubt it could be done.  If not to
> > inject code/control characters, then to make a physical robot move
> > the mouse,press keys, etc all for the user's enjoyment.
> >
> >       As a further aside, if you have root access you'll always be able
> > to get at the memory addresses of whatever is running.  Using an OS
> > that doesn't allow you to do that is a slippery slope and you no
> > longer own this device.
> >
> > As an academic exercise I'm sure you can improve the security of
> > the system to an acceptable level, but you will never be able to
> > make the game non-cheatable.
> >
> > Have fun :),
> > Theorem
> >
> > David Jackson wrote:
> >> This is untrue, on many levels.  It is a software engineering
> >> problem; admittedly, a very hefty one, but it can be done.
> >> At it's very core, you have to be able to protect your program
> >> code and program data.  A good start would be to -not- use
> >> dynamically-linked libraries.
> >> David Jackson
> >> On May 14, 2007, at 2:03 PM, Mike Hobbs wrote:
> >>> I don't mean to throw cold water on your research and I don't
> >>> know what your proposed approach is, but I'm 99.999% certain that
> >>> it is impossible to absolutely prevent cheating on any system
> >>> that the cheater has indiscriminate physical access to. (As an
> >>> aside, this is one reason why DRM will never be effective on
> >>> consumer devices.) Access to the source code makes it very easy
> >>> to cheat, but even without access to the code, a hacker with a
> >>> decompiler can do a lot. Even if you encrypt the binary and all
> >>> messages into and out of it, the secret will have to be decoded
> >>> and into the client's memory at some point. A hacker can then
> >>> inject whatever he wants at that point.
> >>>
> >>> From a different perspective, it is possible for a server to ban
> >>> a client that it "suspects" is cheating, but there is no way to
> >>> absolutely prevent it in the first place.
> >>>
> >>> - Mike
>
>


From zakk at timedoctor.org  Tue May 15 15:34:15 2007
From: zakk at timedoctor.org (Zachary Slater)
Date: Tue, 15 May 2007 12:34:15 -0700
Subject: [quake3] Re: non-cheatable game
In-Reply-To: <BC7F4454-199A-4522-A2BC-85C3AE07F653@bellsouth.net>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org> <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net> <46496E1F.7030900@ngus.net> <BC7F4454-199A-4522-A2BC-85C3AE07F653@bellsouth.net>
Message-ID: <464A0B37.5030108@timedoctor.org>

David Jackson wrote:
> 
> I think your response went bad right at "get over it", which is not an 
> argument.
> 
> It's a software engineering problem, which requires innovation and 
> "thinking outside of the box".  It is entirely possible, but it begs the 
> question of whether or not it's worth it.
> 
> Stop trying to be insulting.
> 

Thank you, Tom Cruise/David Jackson:
You don't know the history of cheating like I do!

Also, you can never prevent someone from replacing their input devices 
with a camera pointed at the screen, scraping out the image and 
autoaiming with fake keyboard/mouse signals. It has never been and will 
never be the intention of this project to get into an anti-cheat war.
-- 
- Zachary J. Slater
zakk at timedoctor.org
zacharyslater at gmail.com


From tim at ngus.net  Tue May 15 15:36:20 2007
From: tim at ngus.net (Tim Angus)
Date: Tue, 15 May 2007 20:36:20 +0100
Subject: non-cheatable game
In-Reply-To: <BC7F4454-199A-4522-A2BC-85C3AE07F653@bellsouth.net>
References: <46447ABC.9070305@itc.it>
	<4648B277.5000402@hobbshouse.org>
	<81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net>
	<46496E1F.7030900@ngus.net>
	<BC7F4454-199A-4522-A2BC-85C3AE07F653@bellsouth.net>
Message-ID: <20070515203620.5783012b.tim@ngus.net>

On Tue, 15 May 2007 13:38:30 -0500 David wrote:
> I think your response went bad right at "get over it", which is not  
> an argument.

I didn't really make an argument to be honest, only stated the facts as
they stand based on my knowledge and experience.

> It's a software engineering problem, which requires innovation and  
> "thinking outside of the box".  It is entirely possible, but it begs  
> the question of whether or not it's worth it.

I'm unconvinced you actually understand the problem. In the
client/server model, there is a client. This client, at some stage,
whether implicitly or explicity, MUST be trusted to do what it was
engineered to do. The trouble is that the malicious user is in
_complete_ control of the client and is thus able to make the client do
whatever he/she pleases. In other words there is conflict which
fundamentally cannot be overcome regardless of your software
engineering prowess. In some cases you may be able to detect the use
of client altering cheats from the server, but the more sophisticated
some become, the less reliable a counter attack this is. Having said
that, this is the most sensible area to address in countering cheats, in
my opinion.

The best you can do on the client is make it more difficult to alter,
but at a fundamental level you can never prevent client altering
cheats as the only tool you really possess is the ability to obfuscate.
In this sense it is very much like DRM.

I don't really understand why you're so insistent that this is a
solvable problem. If it were, surely you're not so naive as to think
it's just that nobody has got around to it yet?

> Stop trying to be insulting.

I wasn't trying to be insulting. However if you go making indignant
statements like "This is untrue, on many levels", you really ought to
expect a terse response and at the very least explain through logical
reasoning why you disagree.



From expressvps at verizon.net  Tue May 15 15:38:10 2007
From: expressvps at verizon.net (Chris Bunting)
Date: Tue, 15 May 2007 15:38:10 -0400
Subject: [quake3] non-cheatable game
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org><81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net><46492E31.2080306@gmail.com><D9554C3B-3B94-4418-8D5D-2A03913B5D47@bellsouth.net> <4561ec380705151202w368ffeedvdb2e8a2f4db193b2@mail.gmail.com>
Message-ID: <00a701c79728$9234fa60$2f01a8c0@tosha418b8ca6b>

Hello,
I take it that none of you guys are actual game hackers or cheat makers?

I ask this because you guys have went round and round about how cheating can 
never be stopped but yet no one has posted exactly how any of these hacks 
are done.  I myself will not get into this. But all I can say, is that 
PunkBuster does the best with weeding out cheating. PB also catches almost 
all in-memory hacks for aimbots, wall hacks, ammo-mods and so forth. Almost 
every hack that once worked for Quake 3 no longer works anymore. Quake 3 may 
be a little different in the way that it was written but try to find a hack 
or write one to get past PunkBuster in Call of Duty 2.. It's almost 
impossible..

Most games based on of Quake 3 source code such as IoQuake, Tremour, Open 
Arena and many others offer custom game clients.. But how many of these 
developers actually modified any dedicated servers that work specificly with 
the client? ioquake doesn't offer a dedicated server that I've seen. So, 
until you write both, a client and a server with anti-hacking taken into 
consideration, there is no way to ever stop cheating.

Thats just my thoughts,
Chris


----- Original Message ----- 
From: "LinuxManMikeC" <linuxmanmikec at gmail.com>
To: <quake3 at icculus.org>
Sent: Tuesday, May 15, 2007 3:02 PM
Subject: Re: [quake3] non-cheatable game


> Whatever you make, someone can break.  Its just a question of how
> difficult you make it for them to break.  Hence, "you will never be
> able to make the game non-cheatable".  You can only make it extremely
> difficult to cheat, or make it infeasible to even attempt cheating for
> a considerable length of time.  But if you really have such profound
> knowledge of how to do this, why not go create it, become a
> billionaire, and make us all eat our hats?
>
> Mike
>
> On 5/15/07, David Jackson <azog at bellsouth.net> wrote:
>>
>> I always worry about absolute statements like "this can never be done".
>>
>> You have to look beyond conventional methods of memory mapping, and
>> program code/program data organization.
>>
>> I'm not going to dig into it, it's far too lengthy for this forum,
>> but it is entirely possible to obfuscate it at many levels.  The
>> question becomes more what tradeoffs you are willing to accept.
>>
>> David Jackson
>>
>> On May 14, 2007, at 10:51 PM, Theorem wrote:
>>
>> > I disagree.  This is exactly the DRM problem, at some point in time
>> > you're going to have to present it to the user, that's the whole
>> > point.
>> >
>> > The definition of cheating I use is "to deceive or influence by
>> > fraud".
>> >
>> >       This can be done many, many ways, software is one attack vector,
>> > hardware is yet another.  This is why "if you can touch it, you can
>> > hack it" is a security mantra.  M. Hobbs eludes to this with
>> > "..indiscriminate physical access".
>> >
>> >       Even assuming your software IS foolproof you rely on the hardware
>> > to make it happen, which is tainted the instant anyone has physical
>> > access. You're missing a large point here because you trust the
>> > hardware.  Regardless if it "would be difficult to do" to hack your
>> > game in hardware I have no doubt it could be done.  If not to
>> > inject code/control characters, then to make a physical robot move
>> > the mouse,press keys, etc all for the user's enjoyment.
>> >
>> >       As a further aside, if you have root access you'll always be able
>> > to get at the memory addresses of whatever is running.  Using an OS
>> > that doesn't allow you to do that is a slippery slope and you no
>> > longer own this device.
>> >
>> > As an academic exercise I'm sure you can improve the security of
>> > the system to an acceptable level, but you will never be able to
>> > make the game non-cheatable.
>> >
>> > Have fun :),
>> > Theorem
>> >
>> > David Jackson wrote:
>> >> This is untrue, on many levels.  It is a software engineering
>> >> problem; admittedly, a very hefty one, but it can be done.
>> >> At it's very core, you have to be able to protect your program
>> >> code and program data.  A good start would be to -not- use
>> >> dynamically-linked libraries.
>> >> David Jackson
>> >> On May 14, 2007, at 2:03 PM, Mike Hobbs wrote:
>> >>> I don't mean to throw cold water on your research and I don't
>> >>> know what your proposed approach is, but I'm 99.999% certain that
>> >>> it is impossible to absolutely prevent cheating on any system
>> >>> that the cheater has indiscriminate physical access to. (As an
>> >>> aside, this is one reason why DRM will never be effective on
>> >>> consumer devices.) Access to the source code makes it very easy
>> >>> to cheat, but even without access to the code, a hacker with a
>> >>> decompiler can do a lot. Even if you encrypt the binary and all
>> >>> messages into and out of it, the secret will have to be decoded
>> >>> and into the client's memory at some point. A hacker can then
>> >>> inject whatever he wants at that point.
>> >>>
>> >>> From a different perspective, it is possible for a server to ban
>> >>> a client that it "suspects" is cheating, but there is no way to
>> >>> absolutely prevent it in the first place.
>> >>>
>> >>> - Mike
>>
>> 



From tim at ngus.net  Tue May 15 15:22:49 2007
From: tim at ngus.net (Tim Angus)
Date: Tue, 15 May 2007 20:22:49 +0100
Subject: non-cheatable game
In-Reply-To: <BC7F4454-199A-4522-A2BC-85C3AE07F653@bellsouth.net>
References: <46447ABC.9070305@itc.it>
	<4648B277.5000402@hobbshouse.org>
	<81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net>
	<46496E1F.7030900@ngus.net>
	<BC7F4454-199A-4522-A2BC-85C3AE07F653@bellsouth.net>
Message-ID: <20070515202249.2b26eed4.tim@ngus.net>

On Tue, 15 May 2007 13:38:30 -0500 David wrote:
> I think your response went bad right at "get over it", which is not  
> an argument.

I didn't really make an argument to be honest, only stated the facts as
they stand based on my knowledge and experience.

> It's a software engineering problem, which requires innovation and  
> "thinking outside of the box".  It is entirely possible, but it begs  
> the question of whether or not it's worth it.

I'm unconvinced you actually understand the problem. In the
client/server model, there is a client. This client, at some stage,
whether implicitly or explicity, MUST be trusted to do what it was
engineered to do. The trouble is that the malicious user is in
_complete_ control of the client and is thus able to make the client do
whatever he/she pleases. In other words there is conflict which
fundamentally cannot be overcome regardless of your software
engineering prowess. In some cases you may be able to detect the use
of client altering cheats from the server, but the more sophisticated
some become, the less reliable a counter attack this is. Having said
that, this is the most sensible area to address in countering cheats, in
my opinion.

The best you can do on the client is make it more difficult to alter,
but at a fundamental level you can never prevent client altering
cheats as the only tool you really possess is the ability to obfuscate.
In this sense it is very much like DRM.

I don't really understand why you're so insistent that this is a
solvable problem. If it were, surely you're not so naive as to think
it's just that nobody has got around to it yet?

> Stop trying to be insulting.

I wasn't trying to be insulting. However if you go making indignant
statements like "This is untrue, on many levels", you really ought to
expect a terse response and at the very least explain through logical
reasoning why you disagree.



From f0rqu3 at gmail.com  Tue May 15 17:53:25 2007
From: f0rqu3 at gmail.com (mister fork)
Date: Wed, 16 May 2007 00:53:25 +0300
Subject: [quake3] Re: non-cheatable game
In-Reply-To: <20070515202249.2b26eed4.tim@ngus.net>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org>
	 <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net>
	 <46496E1F.7030900@ngus.net>
	 <BC7F4454-199A-4522-A2BC-85C3AE07F653@bellsouth.net>
	 <20070515202249.2b26eed4.tim@ngus.net>
Message-ID: <7cd2d9980705151453t4996c255g50e908357a3f7828@mail.gmail.com>

>
> looks interesting, sounds interesting, and tastes interesting. but it is
> not doable


1) read GPL ( it doesnt allow closed source sauce )
2) it is easy to fool cheat protection even if it is closed source ( see
bankbuster )
3) ioquake3 is open source

(1) & (2) & (3) implies you need to stop
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/quake3/attachments/20070516/beeee07a/attachment.htm>

From subsolar at subsolar.com  Tue May 15 18:59:47 2007
From: subsolar at subsolar.com (Paul)
Date: Tue, 15 May 2007 17:59:47 -0500
Subject: [quake3] non-cheatable game
In-Reply-To: <5dc44ec70705142200q5221d557w4556581fd2d65f4c@mail.gmail.com>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org>
	<81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net>
	<46492E31.2080306@gmail.com>
	<5dc44ec70705142200q5221d557w4556581fd2d65f4c@mail.gmail.com>
Message-ID: <1179269987.4206.4.camel@chilly>

On Tue, 2007-05-15 at 02:00 -0300, Diego de Estrada wrote:
> You are missing the point, this has nothing to do with DRM.
> This is not security through obscurity. Here the "root" guy is the
> server, not the clients.
> A bulletproof system is possible, but not easy:
> 
> * Direct access to network data comming from the server must not give
> any advantage to the client.
> Example: instead of the server telling the client "an enemy is behind
> the wall" so that he can hear the foot steps, it's better to say
> directly "foot steps comming from that direction".
> This makes wall hack a dull boy.
> 
> * A "lie" comming from a client should be detected if and only if it
> gives him any advantage.
> Example: it's easy to detect a too fast walking or movement of the
> camera, so speed hack and auto aim, to some point, are detectable.

No totally, a "Trigger Bot" is an example of where sniffing the data
stream can give an advantage.  It works wonderfully with line of sight
weapons and AFAK there would be no possible way for the server to
detect.

Encrypting the data stream would help prevent sniffing the data, but
it's still possible to perform man in the middle attacks.

Paul



From diego1609 at gmail.com  Tue May 15 22:49:26 2007
From: diego1609 at gmail.com (Diego de Estrada)
Date: Tue, 15 May 2007 23:49:26 -0300
Subject: [quake3] non-cheatable game
In-Reply-To: <1179269987.4206.4.camel@chilly>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org>
	 <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net>
	 <46492E31.2080306@gmail.com>
	 <5dc44ec70705142200q5221d557w4556581fd2d65f4c@mail.gmail.com>
	 <1179269987.4206.4.camel@chilly>
Message-ID: <5dc44ec70705151949r11c5248hfa9b0bcb385bb23d@mail.gmail.com>

> No totally, a "Trigger Bot" is an example of where sniffing the data
> stream can give an advantage.  It works wonderfully with line of sight
> weapons and AFAK there would be no possible way for the server to
> detect.

What I've said is that if both items I mentioned are taken into
account, they imply an acceptable level of security. So the trigger
bot is an example of my point.

> Encrypting the data stream would help prevent sniffing the data, but of
> it's still possible to perform man in the middle attacks.

Encrypting the stream won't make any difference, trust me. The
security of the protocol must not come from obfuscation, but from the
strength of the design, specially in an open source project like this.


From zakk at timedoctor.org  Tue May 15 22:56:58 2007
From: zakk at timedoctor.org (Zachary Slater)
Date: Tue, 15 May 2007 19:56:58 -0700
Subject: [quake3] non-cheatable game
In-Reply-To: <5dc44ec70705151949r11c5248hfa9b0bcb385bb23d@mail.gmail.com>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org>	 <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net>	 <46492E31.2080306@gmail.com>	 <5dc44ec70705142200q5221d557w4556581fd2d65f4c@mail.gmail.com>	 <1179269987.4206.4.camel@chilly> <5dc44ec70705151949r11c5248hfa9b0bcb385bb23d@mail.gmail.com>
Message-ID: <464A72FA.2030606@timedoctor.org>

Diego de Estrada wrote:
> Encrypting the stream won't make any difference, trust me. The
> security of the protocol must not come from obfuscation, but from the
> strength of the design, specially in an open source project like this.

Once again let me point out that the focus of ioquake3 is not preventing 
cheaters, to do so would be a waste of time so we are not going to 
pursue it at all. We will close security holes where they exist, but not 
go out of our way to prevent David Jackson from wallhacking on his 
mommies e-machine.
-- 
- Zachary J. Slater
zakk at timedoctor.org
zacharyslater at gmail.com


From baztheallmighty at hotmail.com  Wed May 16 03:43:49 2007
From: baztheallmighty at hotmail.com (baz theallmighty)
Date: Wed, 16 May 2007 07:43:49 +0000
Subject: [quake3] non-cheatable game
In-Reply-To: <464A72FA.2030606@timedoctor.org>
Message-ID: <BAY127-F313787223E66AD4EA73542A83C0@phx.gbl>

Is anyone going to put in any useful idea's or code other then yes you can 
do it no you can't.


Some useful information:
1)Ogc is the major one for non PB server's. Bot's and source code can be 
found here:
www.ecdownloads.com

2)engiene + client + server
engeine:
Does all the input and output stuff
bot lib
renderer
server (maps, bsp tree,etc)
network,etc,etc

Client:
cgame section of code.
Tells the renderer what to render,parses input, runs a mini server(client 
side prediction,etc)


server:
game section of code
The rules of the game. who killed who.


3)There are many copies of the quake 3 source code out there google.

Other useful information/interesting reading:
www.quakesrc.org/forums
http://www.quakesrc.org/forums/viewtopic.php?t=5363

_________________________________________________________________
Advertisement: Senior Management roles paying $80k+ Search now at 
www.seek.com.au 
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eexecutive%2Eseek%2Ecom%2Eau%2F%3Ftracking%3Dsk%3Ahet%3Ase%3Anine%3A0%3Ahot%3Atext&_t=763838044&_r=seek_may07_snrmanagement&_m=EXT



From ceccato at itc.it  Wed May 16 04:59:23 2007
From: ceccato at itc.it (Mariano Ceccato)
Date: Wed, 16 May 2007 10:59:23 +0200
Subject: [quake3] non-cheatable game
In-Reply-To: <BAY127-F313787223E66AD4EA73542A83C0@phx.gbl>
References: <BAY127-F313787223E66AD4EA73542A83C0@phx.gbl>
Message-ID: <464AC7EB.5050904@itc.it>

Thanks a lot Baz, this is actually the kind of help I meant to ask for 
when I started this thread.
This will be a very useful starting point for my research.

Regards,
Mariano

baz theallmighty wrote:
> Is anyone going to put in any useful idea's or code other then yes you can
> do it no you can't.
>
>
> Some useful information:
> 1)Ogc is the major one for non PB server's. Bot's and source code can be
> found here:
> www.ecdownloads.com
>
> 2)engiene + client + server
> engeine:
> Does all the input and output stuff
> bot lib
> renderer
> server (maps, bsp tree,etc)
> network,etc,etc
>
> Client:
> cgame section of code.
> Tells the renderer what to render,parses input, runs a mini server(client
> side prediction,etc)
>
>
> server:
> game section of code
> The rules of the game. who killed who.
>
>
> 3)There are many copies of the quake 3 source code out there google.
>
> Other useful information/interesting reading:
> www.quakesrc.org/forums
> http://www.quakesrc.org/forums/viewtopic.php?t=5363
>   


-- 
Mariano Ceccato
ITC-Irst
Via Sommarive, 18
I-38050 Povo, Trento - ITALY
email: ceccato at itc.it
web: http://sra.itc.it/people/ceccato
tel: +39.0461.314.577
fax: +39.0461.314.591


------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------


From stefanw at gmx.org  Wed May 16 09:07:30 2007
From: stefanw at gmx.org (Stefan Wichmann)
Date: Wed, 16 May 2007 15:07:30 +0200
Subject: Compiling ioquake3 with g++
Message-ID: <464B0212.8070708@gmx.org>

Hi everybody,

as part of my diploma thesis I am porting Quake to a framework for
distributed real-time applications, that we have developed at my
university. This platform is written in C++ and since i have to map the
existing quake-entities onto classes managed by the framework, I have to
compile ioquake with some C++-compiler.

After some initial analysis my approach is to replace all relevant
structs (entityState_t etc.) with classes containing only public
attributes (This way the code using these structs doesn't need to be
changed).

The challenge I am facing now, is to compile the source with a
C++-Compiler. Since Linux is my main development environment this would
be the g++.

It seems, that this compiler is a little stricter than the gcc and
doesn't allow implicit casts anymore (as proposed by the ANSI C++
Standard). Unfortunately these are spread all over the source.

So my questions would be:

Has anybody managed to compile ioquake with the g++?

Do I have to fix every single cast by hand or is someone aware of
tools supporting this conversion?

Will the replacement of structs with classes break the whole qvm-stuff?

I've read about some C++-Port on quakesrc.org, but it hasn't produced
any public code yet. Also I'm not planing to convert everything but the
essential parts to C++.


Thanks very much in advance!

cheers
Stefan


From zakk at timedoctor.org  Wed May 16 11:25:16 2007
From: zakk at timedoctor.org (Zachary Slater)
Date: Wed, 16 May 2007 08:25:16 -0700
Subject: [quake3] non-cheatable game
In-Reply-To: <BAY127-F313787223E66AD4EA73542A83C0@phx.gbl>
References: <BAY127-F313787223E66AD4EA73542A83C0@phx.gbl>
Message-ID: <464B225C.6050409@timedoctor.org>

baz theallmighty wrote:
> Is anyone going to put in any useful idea's or code other then yes you 
> can do it no you can't.
> 

Let me make this clear once again, this discussion is not relevant to 
ioquake3.


-- 
- Zachary J. Slater
zakk at timedoctor.org
zacharyslater at gmail.com


From expressvps at verizon.net  Wed May 16 16:12:59 2007
From: expressvps at verizon.net (Chris Bunting)
Date: Wed, 16 May 2007 16:12:59 -0400
Subject: [quake3] Re: non-cheatable game
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org><81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net><46496E1F.7030900@ngus.net><BC7F4454-199A-4522-A2BC-85C3AE07F653@bellsouth.net><20070515202249.2b26eed4.tim@ngus.net> <7cd2d9980705151453t4996c255g50e908357a3f7828@mail.gmail.com>
Message-ID: <007701c797f6$9a7caf00$2f01a8c0@tosha418b8ca6b>

Hello,

There are 2 Quake 3 related games that I know about that are based on ioquake3.

http://www.urbanterror.net/news.php Urban Terror has anti-cheating (BattleEye) incorporated into it and it's based on ioquake3..

How exactly is this not doable?

Games like Urban Terror from what I understand, must release the source code as per the GPL from ID Software but there is no source available on their site so I'm guessing UT paid the $10,000 for the private license to offer this free game?

Chris
  ----- Original Message ----- 
  From: mister fork 
  To: quake3 at icculus.org 
  Sent: Tuesday, May 15, 2007 5:53 PM
  Subject: Re: [quake3] Re: non-cheatable game


    looks interesting, sounds interesting, and tastes interesting. but it is not doable

  1) read GPL ( it doesnt allow closed source sauce )
  2) it is easy to fool cheat protection even if it is closed source ( see bankbuster )
  3) ioquake3 is open source

  (1) & (2) & (3) implies you need to stop 
   




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/quake3/attachments/20070516/2c7c884f/attachment.htm>

From expressvps at verizon.net  Wed May 16 16:17:57 2007
From: expressvps at verizon.net (Chris Bunting)
Date: Wed, 16 May 2007 16:17:57 -0400
Subject: [quake3] Compiling ioquake3 with g++
References: <464B0212.8070708@gmx.org>
Message-ID: <009101c797f7$4b265c70$2f01a8c0@tosha418b8ca6b>

Hello,

There is a C++ and .NET Version of Quake 2 on the net somewhere. There is 
also infomation about Microsofts new Visual C++ Express Codename Orca that 
also mentions the .Net version as the new Express developer tools and 
supposed to make game building easier. However, the C++ 10 Express will not 
compile regular quake source code as the header files are not the same as 
Express 2005.

There is a lot of information about Quake, Quake 2 and Quake 3 but you'll 
not find much on any quake sites. You need to find the released code and 
thesis papers about quake through google like the multithreaded q3 engine 
and so on.

Chris

----- Original Message ----- 
From: "Stefan Wichmann" <stefanw at gmx.org>
To: <quake3 at icculus.org>
Sent: Wednesday, May 16, 2007 9:07 AM
Subject: [quake3] Compiling ioquake3 with g++


> Hi everybody,
>
> as part of my diploma thesis I am porting Quake to a framework for
> distributed real-time applications, that we have developed at my
> university. This platform is written in C++ and since i have to map the
> existing quake-entities onto classes managed by the framework, I have to
> compile ioquake with some C++-compiler.
>
> After some initial analysis my approach is to replace all relevant
> structs (entityState_t etc.) with classes containing only public
> attributes (This way the code using these structs doesn't need to be
> changed).
>
> The challenge I am facing now, is to compile the source with a
> C++-Compiler. Since Linux is my main development environment this would
> be the g++.
>
> It seems, that this compiler is a little stricter than the gcc and
> doesn't allow implicit casts anymore (as proposed by the ANSI C++
> Standard). Unfortunately these are spread all over the source.
>
> So my questions would be:
>
> Has anybody managed to compile ioquake with the g++?
>
> Do I have to fix every single cast by hand or is someone aware of
> tools supporting this conversion?
>
> Will the replacement of structs with classes break the whole qvm-stuff?
>
> I've read about some C++-Port on quakesrc.org, but it hasn't produced
> any public code yet. Also I'm not planing to convert everything but the
> essential parts to C++.
>
>
> Thanks very much in advance!
>
> cheers
> Stefan 



From pomac at vapor.com  Wed May 16 16:24:52 2007
From: pomac at vapor.com (Ian Kumlien)
Date: Wed, 16 May 2007 22:24:52 +0200
Subject: [quake3] Compiling ioquake3 with g++
In-Reply-To: <464B0212.8070708@gmx.org>
References: <464B0212.8070708@gmx.org>
Message-ID: <1179347102.22739.0.camel@pi.pomac.com>

On ons, 2007-05-16 at 15:07 +0200, Stefan Wichmann wrote:
> Hi everybody,
> 
> as part of my diploma thesis I am porting Quake to a framework for
> distributed real-time applications, that we have developed at my
> university. This platform is written in C++ and since i have to map the
> existing quake-entities onto classes managed by the framework, I have to
> compile ioquake with some C++-compiler.
> 
> After some initial analysis my approach is to replace all relevant
> structs (entityState_t etc.) with classes containing only public
> attributes (This way the code using these structs doesn't need to be
> changed).
> 
> The challenge I am facing now, is to compile the source with a
> C++-Compiler. Since Linux is my main development environment this would
> be the g++.
> 
> It seems, that this compiler is a little stricter than the gcc and
> doesn't allow implicit casts anymore (as proposed by the ANSI C++
> Standard). Unfortunately these are spread all over the source.
> 
> So my questions would be:
> 
> Has anybody managed to compile ioquake with the g++?
> 
> Do I have to fix every single cast by hand or is someone aware of
> tools supporting this conversion?
> 
> Will the replacement of structs with classes break the whole qvm-stuff?
> 
> I've read about some C++-Port on quakesrc.org, but it hasn't produced
> any public code yet. Also I'm not planing to convert everything but the
> essential parts to C++.

Doing the following to all files:

#ifdef __cplusplus
extern "C" {
#endif

<code />

#ifdef __cplusplus
}
#endif

Would be the standard way of doing it.

But it feels kinda obvius. Porting it to C++ would involve so much more
work. But is there something special that forces you to compile it with
C++?


-- 
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://icculus.org/pipermail/quake3/attachments/20070516/78b72fe4/attachment.pgp>

From pomac at vapor.com  Wed May 16 16:26:23 2007
From: pomac at vapor.com (Ian Kumlien)
Date: Wed, 16 May 2007 22:26:23 +0200
Subject: [quake3] Re: non-cheatable game
In-Reply-To: <007701c797f6$9a7caf00$2f01a8c0@tosha418b8ca6b>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org>
	 <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net>
	 <46496E1F.7030900@ngus.net>
	 <BC7F4454-199A-4522-A2BC-85C3AE07F653@bellsouth.net>
	 <20070515202249.2b26eed4.tim@ngus.net>
	 <7cd2d9980705151453t4996c255g50e908357a3f7828@mail.gmail.com>
	 <007701c797f6$9a7caf00$2f01a8c0@tosha418b8ca6b>
Message-ID: <1179347193.22739.2.camel@pi.pomac.com>

On ons, 2007-05-16 at 16:12 -0400, Chris Bunting wrote:
> Hello,
>  
> There are 2 Quake 3 related games that I know about that are based on
> ioquake3.
>  
> http://www.urbanterror.net/news.php Urban Terror has anti-cheating
> (BattleEye) incorporated into it and it's based on ioquake3..
>  
> How exactly is this not doable?
>  
> Games like Urban Terror from what I understand, must release the
> source code as per the GPL from ID Software but there is no source
> available on their site so I'm guessing UT paid the $10,000 for the
> private license to offer this free game?

But does that apply to code that other programmers has worked on in good
faith and contributed to under the gpl?

-- 
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://icculus.org/pipermail/quake3/attachments/20070516/cdb66314/attachment.pgp>

From monk at rq3.com  Wed May 16 16:27:17 2007
From: monk at rq3.com (monk at rq3.com)
Date: Wed, 16 May 2007 14:27:17 -0600 (MDT)
Subject: [quake3] Re: non-cheatable game
In-Reply-To: <007701c797f6$9a7caf00$2f01a8c0@tosha418b8ca6b>
References: <46447ABC.9070305@itc.it>
    <4648B277.5000402@hobbshouse.org><81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net><46496E1F.7030900@ngus.net><BC7F4454-199A-4522-A2BC-85C3AE07F653@bellsouth.net><20070515202249.2b26eed4.tim@ngus.net>
    <7cd2d9980705151453t4996c255g50e908357a3f7828@mail.gmail.com>
    <007701c797f6$9a7caf00$2f01a8c0@tosha418b8ca6b>
Message-ID: <39084.63.150.173.150.1179347237.squirrel@mail.rq3.com>

It's been a while since I looked at the cluster-f*** that is the GPL, but
I believe there are flexible terms in offering the source.  It could be
that the source is in the downloadable binary, i.e. a separate src.zip or
something that's there once you install.

Or they have it on a different download site.  Hell, GPL specifies you can
offer the source if you want in a way where people have to mail you for it
and you have to physically mail them the source on media.

So just because there's not a discrete download link for the source
doesn't mean they are in GPL violation.  I haven't yet checked out the
downloadable package but since you mention no source on their SITE, I'm
guessing you haven't either and haven't checked the binary download.

I'd check there for the source if you haven't already.  Otherwise, well,
see if anyone attached with UrT can clarify the situation for you.

Monk.

> Games like Urban Terror from what I understand, must release the source
> code as per the GPL from ID Software but there is no source available on
> their site so I'm guessing UT paid the $10,000 for the private license to
> offer this free game?
>
> Chris



From pomac at vapor.com  Wed May 16 16:42:20 2007
From: pomac at vapor.com (Ian Kumlien)
Date: Wed, 16 May 2007 22:42:20 +0200
Subject: [quake3] Re: non-cheatable game
In-Reply-To: <007701c797f6$9a7caf00$2f01a8c0@tosha418b8ca6b>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org>
	 <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net>
	 <46496E1F.7030900@ngus.net>
	 <BC7F4454-199A-4522-A2BC-85C3AE07F653@bellsouth.net>
	 <20070515202249.2b26eed4.tim@ngus.net>
	 <7cd2d9980705151453t4996c255g50e908357a3f7828@mail.gmail.com>
	 <007701c797f6$9a7caf00$2f01a8c0@tosha418b8ca6b>
Message-ID: <1179348150.22739.6.camel@pi.pomac.com>

On ons, 2007-05-16 at 16:12 -0400, Chris Bunting wrote:
> Hello,
>  
> There are 2 Quake 3 related games that I know about that are based on
> ioquake3.
>  
> http://www.urbanterror.net/news.php Urban Terror has anti-cheating
> (BattleEye) incorporated into it and it's based on ioquake3..
>  
> How exactly is this not doable?
>  
> Games like Urban Terror from what I understand, must release the
> source code as per the GPL from ID Software but there is no source
> available on their site so I'm guessing UT paid the $10,000 for the
> private license to offer this free game?

From the forums:

Tuxist: How can i download the sourcecode from Urban terror ?
Oswald: We do not distribute our source code, sorry
woekele: ioUrbanTerror is available at
http://camelot.snt.utwente.nl/UrbanTerror

This includes a patch against ioq3.

-- 
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://icculus.org/pipermail/quake3/attachments/20070516/54b671e9/attachment.pgp>

From monk at rq3.com  Wed May 16 16:47:35 2007
From: monk at rq3.com (monk at rq3.com)
Date: Wed, 16 May 2007 14:47:35 -0600 (MDT)
Subject: [quake3] Re: non-cheatable game
In-Reply-To: <1179347193.22739.2.camel@pi.pomac.com>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org>
    <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net>
    <46496E1F.7030900@ngus.net>
    <BC7F4454-199A-4522-A2BC-85C3AE07F653@bellsouth.net>
    <20070515202249.2b26eed4.tim@ngus.net>
    <7cd2d9980705151453t4996c255g50e908357a3f7828@mail.gmail.com>
    <007701c797f6$9a7caf00$2f01a8c0@tosha418b8ca6b>
    <1179347193.22739.2.camel@pi.pomac.com>
Message-ID: <39491.63.150.173.150.1179348455.squirrel@mail.rq3.com>

You are correct.  They can offer a closed-source UrT based on whatever
code id gives in their license.  They cannot use ioq3's code, though,
since that code is GPL'ed.  Even if they have a license for the closed
source and claim they backported the changes from ioq3, it would still be
in GPL violation as the ioq3 code was released under GPL.  Ergo, the ioq3
code is related to the GPL'ed Q3 code and the GPL, not, the ioq3 code is
only related to ANY version of Q3.

So if the source isn't available in their binary package or via terms
outlined in the GPL, UrT team is in GPL violation.

A grey area exists with calling external libraries and able to keep them
closed source if their functionality does not solely depend on GPL'ed
code.  i.e. if you made a closed-source anti-cheat program that a modified
ioq3 calls, you may be able to keep it closed-source if that modified ioq3
does not require the anti-cheat program to function and/or if that
anti-cheat program does something else or works with other programs.

Monk.

>> Games like Urban Terror from what I understand, must release the
>> source code as per the GPL from ID Software but there is no source
>> available on their site so I'm guessing UT paid the $10,000 for the
>> private license to offer this free game?
>
> But does that apply to code that other programmers has worked on in good
> faith and contributed to under the gpl?




From kloppenburg at snt.utwente.nl  Wed May 16 16:55:28 2007
From: kloppenburg at snt.utwente.nl (Erik Kloppenburg)
Date: Wed, 16 May 2007 22:55:28 +0200
Subject: [quake3] Re: non-cheatable game
In-Reply-To: <007701c797f6$9a7caf00$2f01a8c0@tosha418b8ca6b>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org><81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net><46496E1F.7030900@ngus.net><BC7F4454-199A-4522-A2BC-85C3AE07F653@bellsouth.net><20070515202249.2b26eed4.tim@ngus.net> <7cd2d9980705151453t4996c255g50e908357a3f7828@mail.gmail.com> <007701c797f6$9a7caf00$2f01a8c0@tosha418b8ca6b>
Message-ID: <464B6FC0.5020409@snt.utwente.nl>

Urban Terror is a closed source (SDK license) mod for quake3, it does 
not have anti-cheat in it.

ioUrbanTerror is a opensource client (source is available as mentioned 
in the ioUrbanTerror readme and installer), based on ioq3. It can use 
BattlEye anti-cheat, which is closed sourced. BE does not pretend to be 
100% effective. The maker knows it can never be 100% safe. It's just to 
stop most noobs from easily cheating.

Chris Bunting wrote:
> Hello,
> 
> There are 2 Quake 3 related games that I know about that are based on ioquake3.
> 
> http://www.urbanterror.net/news.php Urban Terror has anti-cheating (BattleEye) incorporated into it and it's based on ioquake3..
> 
> How exactly is this not doable?
> 
> Games like Urban Terror from what I understand, must release the source code as per the GPL from ID Software but there is no source available on their site so I'm guessing UT paid the $10,000 for the private license to offer this free game?
> 
> Chris
>   ----- Original Message ----- 
>   From: mister fork 
>   To: quake3 at icculus.org 
>   Sent: Tuesday, May 15, 2007 5:53 PM
>   Subject: Re: [quake3] Re: non-cheatable game
> 
> 
>     looks interesting, sounds interesting, and tastes interesting. but it is not doable
> 
>   1) read GPL ( it doesnt allow closed source sauce )
>   2) it is easy to fool cheat protection even if it is closed source ( see bankbuster )
>   3) ioquake3 is open source
> 
>   (1) & (2) & (3) implies you need to stop 
>    
> 
> 
> 
> 
> 


From daniellord at mac.com  Wed May 16 23:45:17 2007
From: daniellord at mac.com (Daniel Lord)
Date: Wed, 16 May 2007 20:45:17 -0700
Subject: [quake3] Re: non-cheatable game
In-Reply-To: <464B6FC0.5020409@snt.utwente.nl>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org> <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net> <46496E1F.7030900@ngus.net> <BC7F4454-199A-4522-A2BC-85C3AE07F653@bellsouth.net> <20070515202249.2b26eed4.tim@ngus.net> <7cd2d9980705151453t4996c255g50e908357a3f7828@mail.gmail.com> <007701c797f6$9a7caf00$2f01a8c0@tosha418b8ca6b> <464B6FC0.5020409@snt.utwente.nl>
Message-ID: <F1C0EA8A-5741-4AB3-9D0C-41FED049BF55@mac.com>

Go ahead and gallop on you, Don Quixotes! Keep on tilting at the  
windmills of on-line multi-player game cheating! Bravo!

You put your faith in a purely technical solution and that will not  
be enough.
You will never win because you cannot control some essential elements  
of the game which you need control over in order to secure it.
You are fighting human nature, a nature that has changed little in  
over 2,000 years of recorded history, and has shown its need to cheat.
Not everyone or even most, but enough vex most players of online  
gaming at one time or another.

The best defense is the same defense societies have learned--deter  
violations so that only determined violators pierce the protection,  
and then punish the few violators and shun them.
Trying to prevent their crimes is useful but never fully effective.  
You have to be prepared to identify and banish those who are  
determined to get through

Otherwise, you provide a false sense of security and one that will  
leave you undefended.


From expressvps at verizon.net  Thu May 17 04:54:09 2007
From: expressvps at verizon.net (Chris Bunting)
Date: Thu, 17 May 2007 04:54:09 -0400
Subject: [quake3] Re: non-cheatable game
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org><81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net><46496E1F.7030900@ngus.net><BC7F4454-199A-4522-A2BC-85C3AE07F653@bellsouth.net><20070515202249.2b26eed4.tim@ngus.net> <7cd2d9980705151453t4996c255g50e908357a3f7828@mail.gmail.com> <007701c797f6$9a7caf00$2f01a8c0@tosha418b8ca6b> <464B6FC0.5020409@snt.utwente.nl>
Message-ID: <001e01c79860$ef78eb30$2f01a8c0@tosha418b8ca6b>

Hello,

> Urban Terror is a closed source (SDK license) mod for quake3, it does not 
> have anti-cheat in it.

Well, then that explains why Punkbuster and BattleEye are both listed as 
being supported.

If battleeye is closed source though, How does it work with ioTerror?  a 
.dll?

Chris

----- Original Message ----- 
From: "Erik Kloppenburg" <kloppenburg at snt.utwente.nl>
To: <quake3 at icculus.org>
Sent: Wednesday, May 16, 2007 4:55 PM
Subject: Re: [quake3] Re: non-cheatable game


> Urban Terror is a closed source (SDK license) mod for quake3, it does not 
> have anti-cheat in it.
>
> ioUrbanTerror is a opensource client (source is available as mentioned in 
> the ioUrbanTerror readme and installer), based on ioq3. It can use 
> BattlEye anti-cheat, which is closed sourced. BE does not pretend to be 
> 100% effective. The maker knows it can never be 100% safe. It's just to 
> stop most noobs from easily cheating.
>
> Chris Bunting wrote:
>> Hello,
>>
>> There are 2 Quake 3 related games that I know about that are based on 
>> ioquake3.
>>
>> http://www.urbanterror.net/news.php Urban Terror has anti-cheating 
>> (BattleEye) incorporated into it and it's based on ioquake3..
>>
>> How exactly is this not doable?
>>
>> Games like Urban Terror from what I understand, must release the source 
>> code as per the GPL from ID Software but there is no source available on 
>> their site so I'm guessing UT paid the $10,000 for the private license to 
>> offer this free game?
>>
>> Chris
>>   ----- Original Message ----- 
>>   From: mister fork To: quake3 at icculus.org Sent: Tuesday, May 15, 2007 
>> 5:53 PM
>>   Subject: Re: [quake3] Re: non-cheatable game
>>
>>
>>     looks interesting, sounds interesting, and tastes interesting. but it 
>> is not doable
>>
>>   1) read GPL ( it doesnt allow closed source sauce )
>>   2) it is easy to fool cheat protection even if it is closed source ( 
>> see bankbuster )
>>   3) ioquake3 is open source
>>
>>   (1) & (2) & (3) implies you need to stop 



From icculus at icculus.org  Thu May 17 05:26:21 2007
From: icculus at icculus.org (Ryan C. Gordon)
Date: Thu, 17 May 2007 05:26:21 -0400
Subject: [quake3] Re: non-cheatable game
In-Reply-To: <F1C0EA8A-5741-4AB3-9D0C-41FED049BF55@mac.com>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org> <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net> <46496E1F.7030900@ngus.net> <BC7F4454-199A-4522-A2BC-85C3AE07F653@bellsouth.net> <20070515202249.2b26eed4.tim@ngus.net> <7cd2d9980705151453t4996c255g50e908357a3f7828@mail.gmail.com> <007701c797f6$9a7caf00$2f01a8c0@tosha418b8ca6b> <464B6FC0.5020409@snt.utwente.nl> <F1C0EA8A-5741-4AB3-9D0C-41FED049BF55@mac.com>
Message-ID: <464C1FBD.8020104@icculus.org>


> Go ahead and gallop on you, Don Quixotes! Keep on tilting at the  
> windmills of on-line multi-player game cheating! Bravo!

This has been interesting, but it's time to take this conversation 
off-list, guys.

Please feel free to email each other directly if you want to keep 
talking about cheats/hacks, but this mailing list is for ioquake3 
development, and not hypothetical engineering scenarios, even if they 
happen to be hypothetically about quake 3.

Also, there are volumes of information about the finer points of the GPL 
available on the Internet. If you feel someone is in violation of 
ioquake3's license, please contact me directly and I will follow up with 
the copyright holder, but again, this mailing list is for ioquake3 
development, and not hypothetical GPL circumvention techniques, even if 
they happen to be hypothetically about quake 3.

Let's let the people doing real development work have their list back now.

Thanks,
--ryan, mailing list mommy.



From expressvps at verizon.net  Thu May 17 05:46:44 2007
From: expressvps at verizon.net (Chris Bunting)
Date: Thu, 17 May 2007 05:46:44 -0400
Subject: [quake3] Re: non-cheatable game
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org> <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net> <46496E1F.7030900@ngus.net> <BC7F4454-199A-4522-A2BC-85C3AE07F653@bellsouth.net> <20070515202249.2b26eed4.tim@ngus.net> <7cd2d9980705151453t4996c255g50e908357a3f7828@mail.gmail.com> <007701c797f6$9a7caf00$2f01a8c0@tosha418b8ca6b> <464B6FC0.5020409@snt.utwente.nl> <F1C0EA8A-5741-4AB3-9D0C-41FED049BF55@mac.com> <464C1FBD.8020104@icculus.org>
Message-ID: <003c01c79868$476bdb20$2f01a8c0@tosha418b8ca6b>

Hello,

Someone had mentioned in an earlier reply that this list wasn't related to 
ioquake3 so this threw me off a bit.

But since I now see that it is about ioquake3, I'd like to know what 
development is actually taking place?

Thanks,
Chris

----- Original Message ----- 
From: "Ryan C. Gordon" <icculus at icculus.org>
To: <quake3 at icculus.org>
Sent: Thursday, May 17, 2007 5:26 AM
Subject: Re: [quake3] Re: non-cheatable game


>
>> Go ahead and gallop on you, Don Quixotes! Keep on tilting at the 
>> windmills of on-line multi-player game cheating! Bravo!
>
> This has been interesting, but it's time to take this conversation 
> off-list, guys.
>
> Please feel free to email each other directly if you want to keep talking 
> about cheats/hacks, but this mailing list is for ioquake3 development, and 
> not hypothetical engineering scenarios, even if they happen to be 
> hypothetically about quake 3.
>
> Also, there are volumes of information about the finer points of the GPL 
> available on the Internet. If you feel someone is in violation of 
> ioquake3's license, please contact me directly and I will follow up with 
> the copyright holder, but again, this mailing list is for ioquake3 
> development, and not hypothetical GPL circumvention techniques, even if 
> they happen to be hypothetically about quake 3.
>
> Let's let the people doing real development work have their list back now.
>
> Thanks,
> --ryan, mailing list mommy.
> 



From monk at rq3.com  Thu May 17 19:59:59 2007
From: monk at rq3.com (monk at rq3.com)
Date: Thu, 17 May 2007 17:59:59 -0600 (MDT)
Subject: [quake3] Re: non-cheatable game
In-Reply-To: <003c01c79868$476bdb20$2f01a8c0@tosha418b8ca6b>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org>
    <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net>
    <46496E1F.7030900@ngus.net>
    <BC7F4454-199A-4522-A2BC-85C3AE07F653@bellsouth.net>
    <20070515202249.2b26eed4.tim@ngus.net>
    <7cd2d9980705151453t4996c255g50e908357a3f7828@mail.gmail.com>
    <007701c797f6$9a7caf00$2f01a8c0@tosha418b8ca6b>
    <464B6FC0.5020409@snt.utwente.nl>
    <F1C0EA8A-5741-4AB3-9D0C-41FED049BF55@mac.com>
    <464C1FBD.8020104@icculus.org>
    <003c01c79868$476bdb20$2f01a8c0@tosha418b8ca6b>
Message-ID: <57199.63.150.173.150.1179446399.squirrel@mail.rq3.com>

> Hello,
>
> Someone had mentioned in an earlier reply that this list wasn't related to
> ioquake3 so this threw me off a bit.
>
> But since I now see that it is about ioquake3, I'd like to know what
> development is actually taking place?
>
> Thanks,
> Chris

Well, looking at: http://ioquake3.org/

Since December, a reminder of Thilo's existing MDR/MD4 patch and how to
enable it.  And a patch for cell shading.  A link to some MD3 playermodels
from polycount.  And 2 mods went standalone using ioq3 as a base.  Amusing
that under the cell shading patch's "reason for denial" it has
"Cel-shading is perfect for authors to add to their own games using this
patch."  Um... that's a hell of a justification to keep it out of the main
source!  Heheheh.

1.34 has been pending as beta for the last 6 months.  Dunno if there are
any specific areas it needs testing in or what.  I do know I need to get
off my butt and figure out how to enter a bug on the OS X behavior of
config files after I properly document it.

1.35+ looks like mainly code cleanup with only one usability enhancement,
the OS X mod loader.  From what I can tell, IPv6 support is mostly done? 
But not included yet for some reason and is mostly a nerd-pleasing patch. 
Game of the future, supporting IPv6 but 8-year-old animation/model
formats.  hrm.

2.0 has what I could consider to be an EXCELLENT feature if someone were
to bother to port it back to the Dreamcast.  4-player split screen. 
That's an excellent console-centric feature to have and I can't for the
life of me see it of being much use on a desktop computer.  4 mice?  4
gamepads (plausible)?  Maybe as an enticement for using ioq3 as a base for
XBox Live development, but what are the odds that MS would go through the
hassle of having a separate download for the GPL-required source?  And how
hard would it be to port it to XBox's environment?  XNA required, or
something else?


Looking at the mailing list...

Since December, 6 months of being on the list:

172 emails

40 related to the recent cheating/GPL topic
27 related to toggleconsole and international keyboard support
24 related to a request for a full-featured demo playback function/player
22 related to how to compile/make ioq3 (mainly mac questions) or porting
to another language (python, c++)
7 related to me trying to drum up interest in additional model support
7 related to server passwords stored in cl_consoleHistory
5 related to Irix
5 related to TAB completion
4 related to Carmack talking about ASM
22 related to misc, i.e. removing "impotent code"?, FYI on ioq3 on Vista,
bugs (related to bots and mapcycles), freetype support, "advanced admin
authentication", measuring frame rate, ioq3 not working with a demos
option, invisible players being shown by award icon over their heads, etc.


40 emails amounted to pretty much, "stop spamming the list".
27 emails amounted to tjw finally committing a patch after people going
back and forth about the ergonomics of even allowing a console.
24 emails amounted to pretty much, "yeah better demo manipulation would be
neat; someone should do it someday."  Freezetag bloke thought he had some
mostly-done code but he had lost the good bits he wanted to share.
22 emails about compiling, heck, put up a "how to compile ioq3 for mac"
bit in ioq3's website's FAQ and half those mails would probably disappear.
 Or, the responses would be "rtfm" perhaps.
7 emails re: model support was basically, thilo's stuff should be good
enough for mod/game authors, there's no interest in broadening support, do
it yourself if you care enough.  Valid point, nothing wrong with thilo's
work, just the wrong solution to the problem posed.
7 emails amounted to tim implementing the proposed changes in regards to
storing passwords in cl_commandHistory, though under dissention.  I guess
programmer mindset versus real-world usage and usability was the conflict
but feature/bug was addressed.
5 emails about the bloke working on getting an Irix compile, yay!
5 emails about a code question re: editing the tab completion in console.
4 emails about Carmack, an FYI
22 emails about randoms stuff, some FYI, some valid concerns, some not so
much.


I hope that answers your question about what development is actually
taking place?  Honestly, I think some momentum has been lost.  I mean,
it's not as if some of the main contributors don't already have their
hands full ( http://ioquake3.org/?page=games ) with their own projects.


I've harped on it before, but "Our permanent goal is to create the open
source Quake 3 distribution upon which people base their games and
projects."  It's kind of a willy-nilly effort and it HAS produced a very
solid game base.  But that seems kind of like where it's stagnated.  I
think the finished standalones are either using existing content (Star
Trek models from EF, not newly-generated, UrT seems to have rolled their
own model system from way back) or are using basic MD3s (Tremulous and
Padman?).

What ioq3 does seem to have done is provide a good base for other projects
to actually extend Q3 into a better modern platform.  Yes, I know many
people dismiss this as fly-by-night fluff, but XreaL (
http://xreal.sourceforge.net/xrealwiki/CodeChanges ) and Evolution (
http://evolution.quakedev.com/screens.php ) at least are trying to update
support for the latest and greatest.  I mean, Doom 3-class graphics (
http://xreal.sourceforge.net/xrealwiki/ScreenShots ) (
http://evolution.quakedev.com/revolution/screens/shot0002.jpg ) in a free,
open engine that many people have experience with?  Yes, please!

We ( www.rq3.com ) had been looking at ioq3 as a base for a standalone for
quite some time.  Nothing really wrong with it.  However, lately some of
our content creators have been more interested in what they could do with
the "fluff" of XreaL and Evolution.  Yes, total conversions like Padman (
http://padworld.myexp.de/index.php?media&gallery=action ) and Tremulous (
http://tremulous.net/screenshots/ ) look pretty good.  But they also look
like Quake 3.  My content creators point to XreaL screenshots and say, "we
want to do THAT."  They could just as easily point to Doom 3 or UT2K4 and
say the same thing.  It's not just about enticing and pleasing the
programmers when making a solid development platform, it's also about the
users and content creators.

As someone trying to continue work on a mod/game, it's hard enough to
retain content creators working for 4+ years on something for the payment
of "nothing".  It's even harder when there's nothing really new for them
to do.  They are stuck with the same technology and abilities from Quake
3, 7 years ago (give or take; I didn't bother looking it up).  For a while
it was ok.  I think our mod was the first to release something that took
advantage of ydnar's "new" (at the time) lightmap blending support in
q3map2.  And it looked great.  But for a while now, measured in years,
people have had the ability to manipulate skeletal-based models and
animation in-engine.  And have had good support through the entire content
creation toolchain for other game engines.

I may find people who are proficient in Lightwave or Maya or 3DMax.  Or
even someone willing to give their existing content created for another
game, say Half Life or Unreal Tournament 2004.  But there's no real good
way to integrate that stuff with an ioq3-based project.  The entire
content creation pipeline becomes a kludge.

I honestly think ioq3 is really good enough at being a solid base.  But
there's no desire or motivation for anyone to try and extend it into being
a solid MODERN base.  With all the programming talent involved in this
project, it would be great if ioq3 were extended with a graceful fallback
depending on hardware.  Have the traditional Q3 renderer for old, slow
computers.  But hey, got one made in the last 5 years?  Why, enable
bumpmapping and dynamic-light everything.  Instead to get something like
that, one would have to look at another project that is going that way but
might not be as portable or as clean.  A tradeoff, I suppose.

And then there's always the opensource response of, "if you care that much
about it, do it yourself."  True.  But a rather sad and ignorant response
with a project that claims, "Our permanent goal is to create the open
source Quake 3 distribution upon which people base their games and
projects."

I guess it's a success.  I mean, you got 5 games there.  6 if you count
another I know about (though not sure if they use ioq3 or a real Q3
license).  But it's boring and seemingly stagnate.  It's a project for
coders, not for users.  Enhancements that non-programmers would care about
seem to be shot down, ignored, or only grudgingly accepted.  It's
interesting and solid from a programming standpoint, but not necessarily
for any new cutting edge projects.

Well, sorry I went off on a rant.  It's probably something y'all have
heard other people whine about before and I would assume those who didn't
just trash the email after the first few lines skimmed and dismissed or
are already preparing the scathing replies.  ;)

I'll slink back into my hole now.

Monk.


From expressvps at verizon.net  Sun May 20 05:42:23 2007
From: expressvps at verizon.net (Chris Bunting)
Date: Sun, 20 May 2007 05:42:23 -0400
Subject: Questions about ioquake
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org> <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net> <46496E1F.7030900@ngus.net> <BC7F4454-199A-4522-A2BC-85C3AE07F653@bellsouth.net> <20070515202249.2b26eed4.tim@ngus.net> <7cd2d9980705151453t4996c255g50e908357a3f7828@mail.gmail.com> <007701c797f6$9a7caf00$2f01a8c0@tosha418b8ca6b> <464B6FC0.5020409@snt.utwente.nl> <F1C0EA8A-5741-4AB3-9D0C-41FED049BF55@mac.com> <464C1FBD.8020104@icculus.org> <003c01c79868$476bdb20$2f01a8c0@tosha418b8ca6b> <57199.63.150.173.150.1179446399.squirrel@mail.rq3.com>
Message-ID: <000a01c79ac3$2b6a1060$2e01a8c0@tosha418b8ca6b>

Hello All,

I was originally working with a different version of the Quake 3 engine but 
I like the fact that ioquake has a lot of bug fixes and such.

However, I've noticed that the msvc versions have various issues, the source 
code still has the original pack checksum checks and is still fairly plain 
aside from the fixes. Are there any planned features in the future for this 
engine or is it pretty much as is? There is mention on site about adding 
rendering enhancements but I don't see anything aside from what has been 
posted in tutorials or forums. Is there any new original code in here 
anywhere?

Also, I see that curl and other server related features have been 
incorporated into the client. Why is this in the client and not incorporated 
into a Q3A dedicated server?

Thanks,
Chris 



From arny at ats.s.bawue.de  Sun May 20 06:50:28 2007
From: arny at ats.s.bawue.de (Thilo Schulz)
Date: Sun, 20 May 2007 12:50:28 +0200
Subject: [quake3] Questions about ioquake
In-Reply-To: <000a01c79ac3$2b6a1060$2e01a8c0@tosha418b8ca6b>
References: <46447ABC.9070305@itc.it> <57199.63.150.173.150.1179446399.squirrel@mail.rq3.com> <000a01c79ac3$2b6a1060$2e01a8c0@tosha418b8ca6b>
Message-ID: <200705201250.32303.arny@ats.s.bawue.de>

On Sunday 20 May 2007 11:42, Chris Bunting wrote:
> However, I've noticed that the msvc versions have various issues, the
> source code still has the original pack checksum checks and is still fairly
> plain aside from the fixes.

Why should these checks be removed?

> Are there any planned features in the future 
> for this engine or is it pretty much as is? There is mention on site about
> adding rendering enhancements but I don't see anything aside from what has
> been posted in tutorials or forums. Is there any new original code in here
> anywhere?

This project does not focus on rendering enhancements. Some stuff has been 
moved to seperate patches.

> Also, I see that curl and other server related features have been
> incorporated into the client. Why is this in the client and not
> incorporated into a Q3A dedicated server?

Is there any reason why curl download support should be added to a _server_?

-- 
Thilo Schulz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://icculus.org/pipermail/quake3/attachments/20070520/c9572151/attachment.pgp>

From zakk at timedoctor.org  Sun May 20 13:57:39 2007
From: zakk at timedoctor.org (Zachary Slater)
Date: Sun, 20 May 2007 10:57:39 -0700
Subject: [quake3] Questions about ioquake
In-Reply-To: <000a01c79ac3$2b6a1060$2e01a8c0@tosha418b8ca6b>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org> <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net> <46496E1F.7030900@ngus.net> <BC7F4454-199A-4522-A2BC-85C3AE07F653@bellsouth.net> <20070515202249.2b26eed4.tim@ngus.net> <7cd2d9980705151453t4996c255g50e908357a3f7828@mail.gmail.com> <007701c797f6$9a7caf00$2f01a8c0@tosha418b8ca6b> <464B6FC0.5020409@snt.utwente.nl> <F1C0EA8A-5741-4AB3-9D0C-41FED049BF55@mac.com> <464C1FBD.8020104@icculus.org> <003c01c79868$476bdb20$2f01a8c0@tosha418b8ca6b> <57199.63.150.173.150.1179446399.squirrel@mail.rq3.com> <000a01c79ac3$2b6a1060$2e01a8c0@tosha418b8ca6b>
Message-ID: <46508C13.9050607@timedoctor.org>

Chris Bunting wrote:
> Hello All,
> 
> I was originally working with a different version of the Quake 3 engine 
> but I like the fact that ioquake has a lot of bug fixes and such.
>
> However, I've noticed that the msvc versions have various issues, the 
> source code still has the original pack checksum checks and is still 
> fairly plain aside from the fixes.

MSVC: Submit patches, none of us use it and the last guy to work on it 
bailed.

pk3 checksum checks: http://ioquake3.org/?page=help
Scroll to the bottom, and this is never changing. The game as shipped 
and in svn is for running quake3: arena + mods.

> Are there any planned features in the 
> future for this engine or is it pretty much as is? There is mention on 
> site about adding rendering enhancements but I don't see anything aside 
> from what has been posted in tutorials or forums. Is there any new 
> original code in here anywhere?

Submit patches if you don't like something. Rendering patches would go 
onto the patches page.

> Also, I see that curl and other server related features have been 
> incorporated into the client. Why is this in the client and not 
> incorporated into a Q3A dedicated server?

You don't need curl downloading in the server.

> Thanks,
> Chris


...


-- 
- Zachary J. Slater
zakk at timedoctor.org
zacharyslater at gmail.com


From bnoordhuis at gmail.com  Sun May 20 14:09:09 2007
From: bnoordhuis at gmail.com (Ben Noordhuis)
Date: Sun, 20 May 2007 20:09:09 +0200
Subject: [quake3] Questions about ioquake
In-Reply-To: <46508C13.9050607@timedoctor.org>
References: <46447ABC.9070305@itc.it>
	 <7cd2d9980705151453t4996c255g50e908357a3f7828@mail.gmail.com>
	 <007701c797f6$9a7caf00$2f01a8c0@tosha418b8ca6b>
	 <464B6FC0.5020409@snt.utwente.nl>
	 <F1C0EA8A-5741-4AB3-9D0C-41FED049BF55@mac.com>
	 <464C1FBD.8020104@icculus.org>
	 <003c01c79868$476bdb20$2f01a8c0@tosha418b8ca6b>
	 <57199.63.150.173.150.1179446399.squirrel@mail.rq3.com>
	 <000a01c79ac3$2b6a1060$2e01a8c0@tosha418b8ca6b>
	 <46508C13.9050607@timedoctor.org>
Message-ID: <54885e060705201109x4afbdab4le27169c10894f62f@mail.gmail.com>

On 5/20/07, Zachary Slater <zakk at timedoctor.org> wrote:
> Submit patches if you don't like something.

Sure thing, buddy. But what's the normal time frame for a patch to be
accepted or rejected? I don't see much development going on, the
bugzilla seems to be pretty much frozen.


From zakk at timedoctor.org  Sun May 20 16:13:40 2007
From: zakk at timedoctor.org (Zachary Slater)
Date: Sun, 20 May 2007 13:13:40 -0700
Subject: [quake3] Questions about ioquake
In-Reply-To: <54885e060705201109x4afbdab4le27169c10894f62f@mail.gmail.com>
References: <46447ABC.9070305@itc.it>	 <7cd2d9980705151453t4996c255g50e908357a3f7828@mail.gmail.com>	 <007701c797f6$9a7caf00$2f01a8c0@tosha418b8ca6b>	 <464B6FC0.5020409@snt.utwente.nl>	 <F1C0EA8A-5741-4AB3-9D0C-41FED049BF55@mac.com>	 <464C1FBD.8020104@icculus.org>	 <003c01c79868$476bdb20$2f01a8c0@tosha418b8ca6b>	 <57199.63.150.173.150.1179446399.squirrel@mail.rq3.com>	 <000a01c79ac3$2b6a1060$2e01a8c0@tosha418b8ca6b>	 <46508C13.9050607@timedoctor.org> <54885e060705201109x4afbdab4le27169c10894f62f@mail.gmail.com>
Message-ID: <4650ABF4.4050409@timedoctor.org>

Ben Noordhuis wrote:
> On 5/20/07, Zachary Slater <zakk at timedoctor.org> wrote:
>> Submit patches if you don't like something.
> 
> Sure thing, buddy. But what's the normal time frame for a patch to be
> accepted or rejected? I don't see much development going on, the
> bugzilla seems to be pretty much frozen.

This is the first perfectly legitimate complaint I've seen come out of 
this thread. I don't look at bugzilla often enough, so I just went and 
messed around with it.

You can help by commenting on bugs and bringing them to this list if you 
feel they're urgent/spectacular. It would also be great to get people 
reproducing issues. For example:
https://bugzilla.icculus.org/show_bug.cgi?id=2946

Which I can reproduce
or

https://bugzilla.icculus.org/show_bug.cgi?id=3072

Which I can't.
-- 
- Zachary J. Slater
zakk at timedoctor.org
zacharyslater at gmail.com


From linuxmanmikec at gmail.com  Mon May 21 01:42:04 2007
From: linuxmanmikec at gmail.com (LinuxManMikeC)
Date: Mon, 21 May 2007 01:42:04 -0400
Subject: [quake3] Questions about ioquake
In-Reply-To: <000a01c79ac3$2b6a1060$2e01a8c0@tosha418b8ca6b>
References: <46447ABC.9070305@itc.it> <20070515202249.2b26eed4.tim@ngus.net>
	 <7cd2d9980705151453t4996c255g50e908357a3f7828@mail.gmail.com>
	 <007701c797f6$9a7caf00$2f01a8c0@tosha418b8ca6b>
	 <464B6FC0.5020409@snt.utwente.nl>
	 <F1C0EA8A-5741-4AB3-9D0C-41FED049BF55@mac.com>
	 <464C1FBD.8020104@icculus.org>
	 <003c01c79868$476bdb20$2f01a8c0@tosha418b8ca6b>
	 <57199.63.150.173.150.1179446399.squirrel@mail.rq3.com>
	 <000a01c79ac3$2b6a1060$2e01a8c0@tosha418b8ca6b>
Message-ID: <4561ec380705202242jd7d0e27w732f667c69f0ed86@mail.gmail.com>

On 5/20/07, Chris Bunting <expressvps at verizon.net> wrote:
> the source
> code still has the original pack checksum checks

As already stated, this is because this is meant to run original Quake
3 and mods.  However, if you are using this code as a base for your
own game you can remove these tests or put your own checksums in.  Not
a big deal.


From ludwig.nussel at suse.de  Mon May 21 02:50:39 2007
From: ludwig.nussel at suse.de (Ludwig Nussel)
Date: Mon, 21 May 2007 08:50:39 +0200
Subject: [quake3] Questions about ioquake
In-Reply-To: <4650ABF4.4050409@timedoctor.org>
References: <46447ABC.9070305@itc.it> <54885e060705201109x4afbdab4le27169c10894f62f@mail.gmail.com> <4650ABF4.4050409@timedoctor.org>
Message-ID: <200705210850.39228.ludwig.nussel@suse.de>

Zachary Slater wrote:
> Ben Noordhuis wrote:
> > On 5/20/07, Zachary Slater <zakk at timedoctor.org> wrote:
> >> Submit patches if you don't like something.
> > 
> > Sure thing, buddy. But what's the normal time frame for a patch to be
> > accepted or rejected? I don't see much development going on, the
> > bugzilla seems to be pretty much frozen.
> 
> This is the first perfectly legitimate complaint I've seen come out of 
> this thread. I don't look at bugzilla often enough, so I just went and 
> messed around with it.

I already suggested this a while ago, what about setting up a
read-only mailinglist that gets all ioquake3 related bug mails? That
way people would not need to poll bugzilla.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE Labs
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)



From bnoordhuis at gmail.com  Mon May 21 03:26:16 2007
From: bnoordhuis at gmail.com (Ben Noordhuis)
Date: Mon, 21 May 2007 09:26:16 +0200
Subject: [quake3] Questions about ioquake
In-Reply-To: <200705210850.39228.ludwig.nussel@suse.de>
References: <46447ABC.9070305@itc.it>
	 <54885e060705201109x4afbdab4le27169c10894f62f@mail.gmail.com>
	 <4650ABF4.4050409@timedoctor.org>
	 <200705210850.39228.ludwig.nussel@suse.de>
Message-ID: <54885e060705210026yf176c0ci1eb7caaf47842c73@mail.gmail.com>

On 5/21/07, Ludwig Nussel <ludwig.nussel at suse.de> wrote:
> what about setting up a read-only mailinglist that gets all ioquake3 related bug mails?

Gets my vote.


From tim at ngus.net  Mon May 21 04:27:35 2007
From: tim at ngus.net (Tim Angus)
Date: Mon, 21 May 2007 09:27:35 +0100
Subject: Questions about ioquake
In-Reply-To: <200705210850.39228.ludwig.nussel@suse.de>
References: <46447ABC.9070305@itc.it> <54885e060705201109x4afbdab4le27169c10894f62f@mail.gmail.com> <4650ABF4.4050409@timedoctor.org> <200705210850.39228.ludwig.nussel@suse.de>
Message-ID: <465157F7.1060708@ngus.net>

Ludwig Nussel wrote:
> I already suggested this a while ago, what about setting up a
> read-only mailinglist that gets all ioquake3 related bug mails? That
> way people would not need to poll bugzilla.

This is what we do with Tremulous. It works fairly well I think.


From zakk at timedoctor.org  Mon May 21 11:05:07 2007
From: zakk at timedoctor.org (Zachary Slater)
Date: Mon, 21 May 2007 08:05:07 -0700
Subject: [quake3] Questions about ioquake
In-Reply-To: <200705210850.39228.ludwig.nussel@suse.de>
References: <46447ABC.9070305@itc.it> <54885e060705201109x4afbdab4le27169c10894f62f@mail.gmail.com> <4650ABF4.4050409@timedoctor.org> <200705210850.39228.ludwig.nussel@suse.de>
Message-ID: <4651B523.1000403@timedoctor.org>

Ludwig Nussel wrote:
> I already suggested this a while ago, what about setting up a
> read-only mailinglist that gets all ioquake3 related bug mails? That
> way people would not need to poll bugzilla.
> 
> cu
> Ludwig
> 


I think I've tried to get ryan to set this up before, here is the IM 
conversation:

Zachary Slater
7:56
I can't remember, what is the problem with a read-only mailing list that 
gets all the bugzilla bugs?

icculus
7:57
I can't remember either.

Zachary Slater
7:57
well, I'm sure I've asked before and then we didn't do it
so it must be a good reason

icculus
7:57
I'm looking it up

Zachary Slater
7:57
ok
I already set up that for timbo with tremulous

icculus
7:59
I have like 5 IMs of you asking for it

Zachary Slater
7:59
haha

icculus
8:00
but no reason why I didn't do it.

Zachary Slater
8:00
nice

icculus
8:00
I guess I will now. :)

-- 
- Zachary J. Slater
zakk at timedoctor.org
zacharyslater at gmail.com


From zakk at timedoctor.org  Mon May 21 11:49:23 2007
From: zakk at timedoctor.org (Zachary Slater)
Date: Mon, 21 May 2007 08:49:23 -0700
Subject: new mailing list
Message-ID: <4651BF83.8030507@timedoctor.org>

subscribe to the bugs mailing list to get all bug related e-mails by 
sending a blank e-mail to quake3-bugzilla-subscribe at icculus.org

here is the video tutorial:
http://youtube.com/watch?v=f2b1D5w82yU
-- 
- Zachary J. Slater
zakk at timedoctor.org
zacharyslater at gmail.com


From s.smid at chello.nl  Tue May 22 13:43:07 2007
From: s.smid at chello.nl (Sander Smid)
Date: Tue, 22 May 2007 19:43:07 +0200
Subject: quake 3 bots
Message-ID: <46532BAB.5060808@chello.nl>

HI,

As a newbie to the quake 3 source code I want to ask some questions that 
hopefully can speed up a few modifications I have in mind for some of 
the quake 3 bots. I'm a computer science student and I want to modify 
the q3 bot source in a way that bots can ask for help when they're in 
need in a TDM game. I have a few other ideas but they are all related to 
this kind of problem.

Today I worked my way to the code base and made some modifications. My 
first goal was to let a bot say something when he is fighting. I found 
some code related to that in "ai_dmnet.c". But when I add code in there 
which I tell the bots of the blue team to do the following lines of code 
nothing seems to happen. As a matter of fact I haven't been able to let 
the bots talk anymore then they're used to do with the original code.

if (BotTeam(bs) == TEAM_BLUE){
    BotAI_BotInitialChat(bs, "kill_praise", name, NULL);
    bs->lastchat_time = FloatTime();
    bs->chatto = CHAT_ALL;
   
    BotAI_Print(PRT_MESSAGE, "There should be some chatting here...\n");
}

I've read the thesis written by the guy from the "University of Delft" 
but that paper doesn't go into details about the actual source code... 
it describes the inner workings vaguely.

Perhaps some more experienced quake coders can give me a jump start?

Thanks in advantage,
San


From stefanw at gmx.org  Wed May 23 04:20:13 2007
From: stefanw at gmx.org (Stefan Wichmann)
Date: Wed, 23 May 2007 10:20:13 +0200
Subject: [quake3] Compiling ioquake3 with g++
In-Reply-To: <1179347102.22739.0.camel@pi.pomac.com>
References: <464B0212.8070708@gmx.org> <1179347102.22739.0.camel@pi.pomac.com>
Message-ID: <4653F93D.5090506@gmx.org>

Hi everyone,

and first of all: Thanks for the answers...

Ian Kumlien wrote:
> Doing the following to all files:
> 
> #ifdef __cplusplus
> extern "C" {
> #endif
> 
> <code />
> 
> #ifdef __cplusplus
> }
> #endif
> 
> Would be the standard way of doing it.

I tried that, but this only works if the source between this marcos is
pure ANSI C. As I noted, I want (read "have") to change this basic game
structs into classes. After this, it isn't C anymore.

> But it feels kinda obvius. Porting it to C++ would involve so much more
> work. But is there something special that forces you to compile it with
> C++?

The framework I have to use is written in C++. And since it's
integration into Quake is my task, there is no real way around this. But
 as I said: I have no intention to port the whole source. Only the
entity structs have to be changed, so that they can be managed by the
framework.

I started to make the described changes... The replacement of the
structs by classes with public attributes works pretty well (aside from
the compiler errors caused by illegal casts). But there are two things
that came up, when I was working on this:

1) When compiling the renderer-source (code/renderer/*) there many
strange errors, like these:

tr_light.c:47: error: expected primary-expression before ?||? token
tr_light.c:47: error: expected primary-expression before ?->? token

or

tr_local.h:493: error: expected unqualified-id before ?||? token

My friend Google says, that this may happen due to missing semicolons in
 the header files... but i couldn't find anything. Any ideas?

2) Changing structs to classes breaks the compilation with q3lcc (since
it is C-only). Is anyone aware of a good introduction to the whole
qvm-concept? If I got it  right, the game logic is compiled with the
q3lcc (a variation of the standard lcc), linked with q3asm and can then
be interpreted by the quake virtual machine... If this is correct, I
have two more questions:

Is there a way to get around the whole qvm-story by linking the game
logic directly into the engine (like statically linking a library)?

Could I replace the q3lcc with the g++ and let it produce object code
that q3asm understands?

I know this are many questions, but I would really appreciate some hints
from the experts. Thank you very much in advance!

Cheers
Stefan


From spirolat at gmx.net  Thu May 24 09:59:25 2007
From: spirolat at gmx.net (uwe koch)
Date: Thu, 24 May 2007 15:59:25 +0200
Subject: [quake3] quake 3 bots
In-Reply-To: <46532BAB.5060808@chello.nl>
References: <46532BAB.5060808@chello.nl>
Message-ID: <46559A3D.5090203@gmx.net>

Sander Smid wrote:
> if (BotTeam(bs) == TEAM_BLUE){
>    BotAI_BotInitialChat(bs, "kill_praise", name, NULL);
>    bs->lastchat_time = FloatTime();
>    bs->chatto = CHAT_ALL;
>      BotAI_Print(PRT_MESSAGE, "There should be some chatting here...\n");
> }

BotAI_BotInitialChat() does not send the message but constructs it from 
the strings in botfiles/teamplay.h (in pak0.pk3) and stores it 
engineside (bot_chatstate_t::chatmessage). to actually send it, call 
trap_BotEnterChat(). for implementation details see botlib/be_ai_chat.c: 
BotInitialChat() and BotEnterChat().

the easy way for sending arbitray text is using trap_EA_Say() and 
trap_EA_SayTeam().

btw: a better place for modding questions would be forums like:
http://www.quake3world.com/forum/viewforum.php?f=16
http://www.quakesrc.org/forums/viewforum.php?f=20

hope that helps


From azog at bellsouth.net  Thu May 24 18:40:44 2007
From: azog at bellsouth.net (David Jackson)
Date: Thu, 24 May 2007 17:40:44 -0500
Subject: [quake3] non-cheatable game
In-Reply-To: <4561ec380705151202w368ffeedvdb2e8a2f4db193b2@mail.gmail.com>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org> <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net> <46492E31.2080306@gmail.com> <D9554C3B-3B94-4418-8D5D-2A03913B5D47@bellsouth.net> <4561ec380705151202w368ffeedvdb2e8a2f4db193b2@mail.gmail.com>
Message-ID: <24F714AB-28AA-40BA-BB38-756B4BE805CE@bellsouth.net>


I am unsure as to why this has devolved into derisive comments and  
veiled insults.

Rather than reiterate, I will simply take a few steps back and when  
everyone comes to their senses, and the outrage subsides, I will  
return to this discussion.


On May 15, 2007, at 2:02 PM, LinuxManMikeC wrote:

> Whatever you make, someone can break.  Its just a question of how
> difficult you make it for them to break.  Hence, "you will never be
> able to make the game non-cheatable".  You can only make it extremely
> difficult to cheat, or make it infeasible to even attempt cheating for
> a considerable length of time.  But if you really have such profound
> knowledge of how to do this, why not go create it, become a
> billionaire, and make us all eat our hats?
>
> Mike
>
> On 5/15/07, David Jackson <azog at bellsouth.net> wrote:
>>
>> I always worry about absolute statements like "this can never be  
>> done".
>>
>> You have to look beyond conventional methods of memory mapping, and
>> program code/program data organization.
>>
>> I'm not going to dig into it, it's far too lengthy for this forum,
>> but it is entirely possible to obfuscate it at many levels.  The
>> question becomes more what tradeoffs you are willing to accept.
>>
>> David Jackson
>>
>> On May 14, 2007, at 10:51 PM, Theorem wrote:
>>
>> > I disagree.  This is exactly the DRM problem, at some point in time
>> > you're going to have to present it to the user, that's the whole
>> > point.
>> >
>> > The definition of cheating I use is "to deceive or influence by
>> > fraud".
>> >
>> >       This can be done many, many ways, software is one attack  
>> vector,
>> > hardware is yet another.  This is why "if you can touch it, you can
>> > hack it" is a security mantra.  M. Hobbs eludes to this with
>> > "..indiscriminate physical access".
>> >
>> >       Even assuming your software IS foolproof you rely on the  
>> hardware
>> > to make it happen, which is tainted the instant anyone has physical
>> > access. You're missing a large point here because you trust the
>> > hardware.  Regardless if it "would be difficult to do" to hack your
>> > game in hardware I have no doubt it could be done.  If not to
>> > inject code/control characters, then to make a physical robot move
>> > the mouse,press keys, etc all for the user's enjoyment.
>> >
>> >       As a further aside, if you have root access you'll always  
>> be able
>> > to get at the memory addresses of whatever is running.  Using an OS
>> > that doesn't allow you to do that is a slippery slope and you no
>> > longer own this device.
>> >
>> > As an academic exercise I'm sure you can improve the security of
>> > the system to an acceptable level, but you will never be able to
>> > make the game non-cheatable.
>> >
>> > Have fun :),
>> > Theorem
>> >
>> > David Jackson wrote:
>> >> This is untrue, on many levels.  It is a software engineering
>> >> problem; admittedly, a very hefty one, but it can be done.
>> >> At it's very core, you have to be able to protect your program
>> >> code and program data.  A good start would be to -not- use
>> >> dynamically-linked libraries.
>> >> David Jackson
>> >> On May 14, 2007, at 2:03 PM, Mike Hobbs wrote:
>> >>> I don't mean to throw cold water on your research and I don't
>> >>> know what your proposed approach is, but I'm 99.999% certain that
>> >>> it is impossible to absolutely prevent cheating on any system
>> >>> that the cheater has indiscriminate physical access to. (As an
>> >>> aside, this is one reason why DRM will never be effective on
>> >>> consumer devices.) Access to the source code makes it very easy
>> >>> to cheat, but even without access to the code, a hacker with a
>> >>> decompiler can do a lot. Even if you encrypt the binary and all
>> >>> messages into and out of it, the secret will have to be decoded
>> >>> and into the client's memory at some point. A hacker can then
>> >>> inject whatever he wants at that point.
>> >>>
>> >>> From a different perspective, it is possible for a server to ban
>> >>> a client that it "suspects" is cheating, but there is no way to
>> >>> absolutely prevent it in the first place.
>> >>>
>> >>> - Mike
>>
>>



From kloppenburg at snt.utwente.nl  Thu May 24 19:33:04 2007
From: kloppenburg at snt.utwente.nl (Erik Kloppenburg)
Date: Fri, 25 May 2007 01:33:04 +0200
Subject: [quake3] non-cheatable game
In-Reply-To: <24F714AB-28AA-40BA-BB38-756B4BE805CE@bellsouth.net>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org> <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net> <46492E31.2080306@gmail.com> <D9554C3B-3B94-4418-8D5D-2A03913B5D47@bellsouth.net> <4561ec380705151202w368ffeedvdb2e8a2f4db193b2@mail.gmail.com> <24F714AB-28AA-40BA-BB38-756B4BE805CE@bellsouth.net>
Message-ID: <465620B0.3090700@snt.utwente.nl>

David Jackson wrote:
> Rather than reiterate, I will simply take a few steps back and when 
> everyone comes to their senses, and the outrage subsides, I will return 
> to this discussion.

I think the ioq3 devs were pretty clear when they said this discussion 
does not belong on the ioq3 mailing list ;)


From azog at bellsouth.net  Thu May 24 21:25:39 2007
From: azog at bellsouth.net (David Jackson)
Date: Thu, 24 May 2007 20:25:39 -0500
Subject: [quake3] non-cheatable game
In-Reply-To: <465620B0.3090700@snt.utwente.nl>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org> <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net> <46492E31.2080306@gmail.com> <D9554C3B-3B94-4418-8D5D-2A03913B5D47@bellsouth.net> <4561ec380705151202w368ffeedvdb2e8a2f4db193b2@mail.gmail.com> <24F714AB-28AA-40BA-BB38-756B4BE805CE@bellsouth.net> <465620B0.3090700@snt.utwente.nl>
Message-ID: <206024AB-BC13-49D2-82DD-6192011B0D26@bellsouth.net>


How thoughtful of you to point that out.

On May 24, 2007, at 6:33 PM, Erik Kloppenburg wrote:

> David Jackson wrote:
>> Rather than reiterate, I will simply take a few steps back and  
>> when everyone comes to their senses, and the outrage subsides, I  
>> will return to this discussion.
>
> I think the ioq3 devs were pretty clear when they said this  
> discussion does not belong on the ioq3 mailing list ;)



From f0rqu3 at gmail.com  Fri May 25 04:05:47 2007
From: f0rqu3 at gmail.com (mister fork)
Date: Fri, 25 May 2007 11:05:47 +0300
Subject: [quake3] non-cheatable game
In-Reply-To: <206024AB-BC13-49D2-82DD-6192011B0D26@bellsouth.net>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org>
	 <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net>
	 <46492E31.2080306@gmail.com>
	 <D9554C3B-3B94-4418-8D5D-2A03913B5D47@bellsouth.net>
	 <4561ec380705151202w368ffeedvdb2e8a2f4db193b2@mail.gmail.com>
	 <24F714AB-28AA-40BA-BB38-756B4BE805CE@bellsouth.net>
	 <465620B0.3090700@snt.utwente.nl>
	 <206024AB-BC13-49D2-82DD-6192011B0D26@bellsouth.net>
Message-ID: <7cd2d9980705250105x4a3c04a7p75f4a5476f1c61cf@mail.gmail.com>

If you want it, do it yourself. That way you can prove your statement.
http://ioquake3.org/?page=status
don't read the bottom of the page.

On 5/25/07, David Jackson <azog at bellsouth.net> wrote:
>
>
> How thoughtful of you to point that out.
>
> On May 24, 2007, at 6:33 PM, Erik Kloppenburg wrote:
>
> > David Jackson wrote:
> >> Rather than reiterate, I will simply take a few steps back and
> >> when everyone comes to their senses, and the outrage subsides, I
> >> will return to this discussion.
> >
> > I think the ioq3 devs were pretty clear when they said this
> > discussion does not belong on the ioq3 mailing list ;)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/quake3/attachments/20070525/9ab01df7/attachment.htm>

From tim at ngus.net  Fri May 25 04:38:50 2007
From: tim at ngus.net (Tim Angus)
Date: Fri, 25 May 2007 09:38:50 +0100
Subject: non-cheatable game
In-Reply-To: <24F714AB-28AA-40BA-BB38-756B4BE805CE@bellsouth.net>
References: <46447ABC.9070305@itc.it> <4648B277.5000402@hobbshouse.org> <81089F30-7D5A-4FFE-9022-7F32D066582D@bellsouth.net> <46492E31.2080306@gmail.com> <D9554C3B-3B94-4418-8D5D-2A03913B5D47@bellsouth.net> <4561ec380705151202w368ffeedvdb2e8a2f4db193b2@mail.gmail.com> <24F714AB-28AA-40BA-BB38-756B4BE805CE@bellsouth.net>
Message-ID: <4656A09A.60502@ngus.net>

David Jackson wrote:
> I am unsure as to why this has devolved into derisive comments and 
> veiled insults.

Here are your options:

a. Lose the gigantic chip on your shoulder and actually contribute some 
concrete ideas rather than just making outlandish unsubstantiated claims.

b. Fuck off.


From s.smid at chello.nl  Fri May 25 12:16:07 2007
From: s.smid at chello.nl (Sander Smid)
Date: Fri, 25 May 2007 18:16:07 +0200
Subject: [quake3] quake 3 bots
In-Reply-To: <46559A3D.5090203@gmx.net>
References: <46532BAB.5060808@chello.nl> <46559A3D.5090203@gmx.net>
Message-ID: <46570BC7.6040404@chello.nl>

uwe koch wrote:
> Sander Smid wrote:
>> if (BotTeam(bs) == TEAM_BLUE){
>>    BotAI_BotInitialChat(bs, "kill_praise", name, NULL);
>>    bs->lastchat_time = FloatTime();
>>    bs->chatto = CHAT_ALL;
>>      BotAI_Print(PRT_MESSAGE, "There should be some chatting 
>> here...\n");
>> }
>
> BotAI_BotInitialChat() does not send the message but constructs it 
> from the strings in botfiles/teamplay.h (in pak0.pk3) and stores it 
> engineside (bot_chatstate_t::chatmessage). to actually send it, call 
> trap_BotEnterChat(). for implementation details see 
> botlib/be_ai_chat.c: BotInitialChat() and BotEnterChat().
>
> the easy way for sending arbitray text is using trap_EA_Say() and 
> trap_EA_SayTeam().
>
> btw: a better place for modding questions would be forums like:
> http://www.quake3world.com/forum/viewforum.php?f=16
> http://www.quakesrc.org/forums/viewforum.php?f=20
>
> hope that helps
>

Thanks a lot for your reply.. this and some help on the IRC channel have 
been a huge help!

Cheers,
Sander


From defsyn at gmail.com  Mon May 28 13:12:22 2007
From: defsyn at gmail.com (Henry Garcia)
Date: Mon, 28 May 2007 13:12:22 -0400
Subject: mingw fails to compile on Windows 2000: svn 1089
Message-ID: <a387ed40705281012t4ea95955mf261f31dd876581@mail.gmail.com>

Windows 2000. 512 MB
Mingw fails to build ioquake3. Receive message Not enough memory for the
heap. No output for stdout. Takes about 10 - 15 minutes. CPU is under load,
no output, and then finally receive message that there is not enough memory
for the heap.

Last successful build on Window 2000 that I have is SVN 1085. SVN 1085
builds fine right after a failed build on 1089, using same parameters on the
Makefile.

BUILD_CLIENT     = 1
BUILD_CLIENT_SMP = 0
BUILD_SERVER     = 0
BUILD_GAME_SO    = 1
BUILD_GAME_QVM   = 1

Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/quake3/attachments/20070528/7b1a0836/attachment.htm>

From tim at ngus.net  Mon May 28 13:41:51 2007
From: tim at ngus.net (Tim Angus)
Date: Mon, 28 May 2007 18:41:51 +0100
Subject: mingw fails to compile on Windows 2000: svn 1089
In-Reply-To: <a387ed40705281012t4ea95955mf261f31dd876581@mail.gmail.com>
References: <a387ed40705281012t4ea95955mf261f31dd876581@mail.gmail.com>
Message-ID: <20070528184151.06ed21ba.tim@ngus.net>

On Mon, 28 May 2007 13:12:22 -0400 Henry wrote:
> Last successful build on Window 2000 that I have is SVN 1085. SVN 1085
> builds fine right after a failed build on 1089, using same parameters
> on the Makefile.

Could you double check it's a problem in the code please? There is
really very little betweem 1085:1089 that I can see causing a problem.
Assuming you still see a problem, could you identify the exact revision
where the build starts to fail? Thanks.

(It could be that your computer is genuinely just low on memory too...)



From defsyn at gmail.com  Mon May 28 16:30:10 2007
From: defsyn at gmail.com (Henry Garcia)
Date: Mon, 28 May 2007 16:30:10 -0400
Subject: [quake3] Re: mingw fails to compile on Windows 2000: svn 1089
In-Reply-To: <20070528184151.06ed21ba.tim@ngus.net>
References: <a387ed40705281012t4ea95955mf261f31dd876581@mail.gmail.com>
	 <20070528184151.06ed21ba.tim@ngus.net>
Message-ID: <a387ed40705281330k5da8ba0byfccc1d27d87547cf@mail.gmail.com>

On 5/28/07, Tim Angus <tim at ngus.net> wrote:
>
> On Mon, 28 May 2007 13:12:22 -0400 Henry wrote:
> > Last successful build on Window 2000 that I have is SVN 1085. SVN 1085
> > builds fine right after a failed build on 1089, using same parameters
> > on the Makefile.
>
> Could you double check it's a problem in the code please? There is
> really very little betweem 1085:1089 that I can see causing a problem.


Looks like a corrupted SVN on my side.  Downloaded a fresh SVN. Compiles
fine.


>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/quake3/attachments/20070528/b8232d16/attachment.htm>