why is it required to disconnect clients when they connect without disconnecting (for example, because of a client that was "kill -9"d)? Tremulous uses this opportunity to let a player continue playing without impacting its entity (ie., the player will continue to play from the same location, with the same amount of health and armament, etc.).

(In reply to comment #1)
> why is it required to disconnect clients when they connect without
> disconnecting (for example, because of a client that was "kill -9"d)? Tremulous
> uses this opportunity to let a player continue playing without impacting its
> entity (ie., the player will continue to play from the same location, with the
> same amount of health and armament, etc.).

I am not sure why, but I sometimes got a blue screen if I disconnect and/or 
reconnect from/to a game hosted on the same machine where to connect (yes, I 
know this is no common scenario, but anyway...) it was there since 1.32b on 
Win 2000, Xp... until now. Since I applied the above solutions, the blue screen
never happened again. I never figured out why, because the problem is that the
whole connect/disconnect, map restart/configstring thing is critical in some
situations. I still think there must be "one evil bug" which does many bad
things but was never discovered. This "one evil bug" breaks configstrings
on map restarts and after disconnecting.

Here are two scenarios where you can see how critical a restart could be:

1. Fire up a CTF match and add a bot to your team.
2. Command the bot to follow you.
3. Do a map restart.
4. Now watch the bot you commanded to follow!

The silly strafing the bot will do is because of the function 
"BotReadSessionData", where the teamgoal.mins/maxs/origin will be called but 
was never set correctly. The interesting thing here is if you correct those 
values accordingly (which is a lot of wasted work) and another human player 
will disconnect and reconnect the bot will not find this player to follow. (and
if I remember correctly, the game sometimes will crash) So, DON'T DO THIS! I 
only wanted to discribe how reconnecting can break strings! Or, if I am wrong,
how at least disconnecting players can affect things that should not been
affected (in this case players (entities) and there origin).

Another thing I never ever understand is the problem with the function 
"SetLeader" where CON_DISCONNECTED will return no leader vs."SetTeam" where 
"CheckTeamLeader" should set a leader. Sometimes no leader is set, and with 
"g_teamAutoJoin" (or was it "g_teamForceBalance") there was (is) a bug I can't
remember. Anyway, interesting here is, if ever I tried to fix this, I had 
problems with already disconnected players. I never found a solution for this 
problem, but I bet that a not correct connected/disconnected player infostring
caused problems here again.

And finally, bots still hunt for disconnected clients...., but maybe that is 
another story!

Anyway, I am more concerned with AI programming, so if you tell me that I did 
(or understand) something wrong, I will respect that!
... and thanks for your response,

Tobias Kuehnhammer

The views of /dev/hc do not represent those of the project.

ah, i actually forgot about this bug report. long ago, i failed in a short try to add Tremulous-style seamless support for reconnecting, and i don't care much to try more. since
- the said support can be added later (if someone decides to), and
- the proposed patch does fix gameplay bugs like the flag disappearing,
i am not against the patch.

Created attachment 3082 [details]
version 2

What code is from GPLv3 projects?  And what is from the ET SDK?  I don't think the licenses are compatible.

The ET SDK license can be found in the downloads here:  http://wiki.splashdamage.com/index.php/Wolfenstein:_Enemy_Territory_SDK

3.a. of the license seems to block it from use in ioq3.  And using the GPLv3 coverage for the whole source isn't compatible with ioq3 remaining GPLv2.

ETXreaL is GPLv3, I think, but I don't recall what version of GPL that XreaL's original codebase started from.  Might have to ask Tr3b.  WoP states GPLv2 so that stuff is fine.

I'm not trying to rain on your parade, I just want to make sure ioq3 doesn't accidentially incorporate code that would force it to change license to GPLv3.

Ah sorry, beside of your question, I saw that I didn't comment the new version, or at least my comment was accidently deleted by myself.

In response to your question about GPLv3, I have to admit that I never understood these GPL things...
If someone fixes a bug, and there is only one solution for that, does this mean that you are not allowed to fix this bug, because someone already did fix it that way?
I already mentioned that I'm no professional programmer or lawyer. So what I can say is:

Bugfix 1: (bots on jumppad) is also seen on World of Padman. I fixed my own AI
          project independent from WoP, although in WoP the bugfix is nearly 
          done the same way as I did, or vice versa! (as already mentioned 
          because of the reason above)

Bugfix 4: The small precision update to the movement code was from Xreal and
          is no longer in the diff.patch (It seems that it will only fix issues
          if you work with a more accurate movement code)

Bugfix 5: The problem with disconnected "ghost" clients is fixed in Tremulous:
          http://svn.icculus.org/tremulous/trunk/src/game/g_client.c?r1=1999&r2=2009
          http://svn.icculus.org/tremulous/trunk/src/game/g_client.c?r1=1974&r2=1991

         But this bug is also fixed in World Of Padman. I bet that both 
         projects did find and fix this bug independent from each other. (Or 
         maybe "/dev/humancontroller" knows more about that) But here it comes:
         I noted that parts of this bug were also fixed in other projects. I 
         think one was called "qfusion" or something (maybe today nobody 
         remember this project). Anyways, AFTER "qfusion" fixed this problem, 
         the same bugfix was seen in ET-Wolfenstein.
         This leads me to the point that nobody could say today who first fixed
         this bug, moreover there seems to be no other way to implement this
         fix. (Personally, I think that again more projects found and fixed
         this bug independent from each other)

         Here is exactly what is written in ET-Wolfenstein:

	 // Gordon: porting q3f flag bug fix
         // If a player reconnects quickly after a disconnect, the client 
            disconnect may never be called, thus flag can get lost in the ether
	    if ( ent->inuse ) {
                G_LogPrintf( "Forcing disconnect on active client: %i\n", ent -                g_entities );
		// so lets just fix up anything that should happen on a
                  disconnect
                ClientDisconnect( ent - g_entities );
         }

         If I remember correctly, I think the project "qfusion" started before 
         Wolfenstein-ET was there. And as I already said, the bugfix was
         written in the same way in "qfusion" or whatever it was called.
   
         I don't want to say that somthing is wrong here. All I want to say is
         that sometimes a bugfix looks the same because its a bugfix and not an
         enhancement or some new cool feature!

         This part is the only part which corresponds with Wolfenstein-ET!
         And I have no clue if this is good or bad!

Everthing else in this diff.patch is fixed by myself (although I don't follow every other idtech3 project anymore!)

Now to version 2 of this diff.patch, as I already mentioned the changes in the movement code aren't there anymore, because in plain ioquake3 there is no benefit from it, and why should someone change something which doesn't do anything? This was the only part from Xreal!

Second, a new bugfix was added which fixes the view if a player was standing on rotating platforms. The bugfix is from OAX which is based upon ioquake3. OAX is:
"The source code is GPL v2 or later but some of the tools are not"

Okay if you think that "ioq3 DOES accidentially incorporate code that would force it to change license to GPLv3" than please delete everything which I accidently did wrong. All those bugfixes are not worth to apply if ioquake3 would be in danger!

Now if you wonder why I always come with bugfixes from other projects or Quake3World.com, than please note:
The only reason why I always want to stay in sync with other projects is that I always want to make sure that mods (even older ones from 2001/2002 or so will still work with ANY ioquake3 project out there (Q3Rally, Open Arena, Entity Plus)). I do this for my own pleasure and to work on my own ioq3ztm/ioquake3 based project! I'm not sure how important all these bugfixes are for ioquake3, this decision can only made by ioquake 3 maintainers, and not by me!

So I totally agree with you, and it is okay if we delete everything from here,
if this patch is not compatible with ioquake3!
--------------------------------------------------------------------------------PS.: It seems that you know much about the GPL thing, so please give my a tip 
     on that. What is about this bug here on bugzilla:

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

     Once I had this in ioquake3, but I'm confused with the new modular 
     rendering system!
     Beside of that, is it NOW allowed to apply foliage support or not?
--------------------------------------------------------------------------------
Thanks for your response,

Tobias Kuehnhammer

Well, your bugfixes are not a copy and paste from GPLv3 stuff, you reimplemented it yourself, so I think that's fine.  That was my only concern.

As for the foliage stuff, yeah, at the time it was written, I assumed that it would go GPLv2.  But, it didn't.  So I guess someone can reimplement a compatible solution or just do a copy/paste (if applicable) from the ET code.

For projects based on ioq3 that want to use ET code, they are free to make their codebase GPLv3 so it's not a concern.  Some people and distros prefer GPLv2 stuff, though, which is why an attempt is made to keep the engine purely GPLv2.

Bear in mind I am not a maintainer for ioq3 so the ultimate decision on this stuff doesn't lie with me.  I was just voicing a concern.  :)

Created attachment 3141 [details]
version 3

version 3: patched against ioquake rev. 2244

Two new small bugixes added:

1. first_gauntlet_hit.wav was not played (ops/ps) bug
2. capturelimit not hit (from OAX)

fixed r2294