Hi
I finally got around to putting all my bugfixes up on my webpage:
http://games.chruker.dk/enemy_territory/modding_project_bugfix.php
Some of the bugfixes are already fixed by the 2.60 patch. Some are just typos. Some are cleanups. But there are some genuine fixes in there.
Any comments?
Wow thats some nice work 
. Haven’t looked had a chance to look through it completely, but a couple comments:
http://games.chruker.dk/enemy_territory/modding_project_bugfix.php?bug_id=002 It may have been a bug to start with, but many players would miss it if removed.
Also, backstab is for all players, ‘Assassin’ is LVL 4 covops.
Assuming you leave backstabbing dead players, Assassin (LVL 4 covops) did have a problem in 2.56… It uses take = ent->health, even if the player is dead. Thus gibbing with a knife at lvl4 covops was hard. (it could still be done, because of the random factor later in the code, but was highly unpredictable). That is fixed in 2.6 (lvl covops get backstab on dead players just like anyone else)
Finally, it would be nice if you offered this in a patch format.
First about a patch/diff file: I haven’t worked much with the diff/patch tools so I’m a bit uncertain about it.
Second about the backstab: Perhaps people would miss it, but there are other exploits that people would miss too. Rains fix in the 2.60 code is flawed in the way that players get backstab damage like before. There isn’t any logic in that. Rains fix only fixes the bug that level 4 coverts didn’t get the backstab damage.
Anyway it is up to the modders to implement the scheme they want.
It is fairly easy to make a diff. Just take a clean ET tree, and your tree, and
diff -r -u [list=1] <new_dir> > filename.patch
You can get native win32 gnu utilities here: http://gnuwin32.sourceforge.net/
Or use subversion and tortoisesvn, as a I mentioned here:
http://www.splashdamage.com/index.php?name=pnPHPbb2&file=viewtopic&t=11967
Then you can just right click and ‘create patch’
For those who know how to use it, it makes a much easier and less error prone way to get your changes.
I wouldn’t call it flawed. It is an intentional choice to leave it the way it has been since RTCW, while fixing the flaw with level 4 covert. The backstab corpse ‘bug’ adds a neat gameplay element (you can get a quick gib if you jump on their head with a knife, but that usually involves risk…), while the level 4 covert thing is just plain annoying.
An alternative ‘fix’ would be to show the knife backstab icon correctly for bodies :moo:
Just because something wasn’t intended doesn’t mean that it can’t turn out to be a worthwhile gameplay features. (strafe jumping in quake games, skiing in tribes, TK/revive and airstrike steering in RTCW/ET etc etc)
Why don’t you make a PK3 with all the know problems fixed??
I think you did a great job here!
Greetz Way2Evil
Chrucker, I merged most of your fixes into etpub. I noticed 2 typos:
http://games.chruker.dk/enemy_territory/modding_project_bugfix.php?bug_id=068
filename should be “g_local.h” not “g_local.c”
http://games.chruker.dk/enemy_territory/modding_project_bugfix.php?bug_id=049
cg_loadpanel.c @ 530
shows the removal of x, w, and h, but should only be removing y and h.
Another bug fix that needs to be added is this one:
http://linespeed.net/projects/etpub/changeset/282
http://linespeed.net/projects/etpub/changeset/283
It causes crashes on the custom maps glider and 1944_beach (probably transmitter too).
http://games.chruker.dk/enemy_territory/modding_project_bugfix.php?bug_id=001
client side engine is fixed, as i explained in other threads.
tjw: Thanks for notifying me about the typos. I have changed the g_local.c to g_local.h. However in cg_loadpanel.c it should only keep the w, variable. X isn’t used in the code.
bani: The reason I phrased it as ‘should be’ was because I have no way of checking if it was actually fixed. In retrospect it wasn’t needed. Anyway I wasn’t able to reproduce the crash by the time I copied rains code in the first place, however now I think I am. So I installed a clean 2.56 and used a clean 2.56 sdk, where I only added this command to g_svcmds.c:
if (Q_stricmp (cmd, "testssc") == 0) {
// | 1
// | 1 2 3 4 5 6 7 8 9 0 1
// | 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
// trap_SendServerCommand( -1, va("print \"Testing very long server commands: This one should work. 100 200 300 400 500 600 700 800 900 1000 1010 1020
\"") );
trap_SendServerCommand( -1, va("print \"Testing very long server commands: This one should crash. 100 200 300 400 500 600 700 800 900 1000 1010 1020a
\"") );
return qtrue;
}
When using the crash line, the game disconnects with this error:
] estssc
********************
ERROR: CL_ParseServerMessage: Illegible server message 0
********************
When I add the command to a clean 2.60 source tree. And disable the longer-than-1022 check in trap_sendservercommand the 2.60 ET crashes in the same way that the 2.56 did.
Am I missing something here?
@chruker
Yup, if I just comment out the return in the check in g_syscalls, I get the exact same thing in 2.60 as 2.56 did. Note you don’t need a custom command, vsay <1024*a> will do the trick. The console may not let you input that much on one line, but you can do it in a .cfg
Which means it’s not fixed in the client engine : (
The crash bug is still possible on shrub servers as it’s based on 2.56 server source, I tested that on my local server. Would have been nice if it was fixed in the client engine or the 2.60 client.
jaybird: Yeah. I don’t yet get why and why tjw’s updated one is fixing it. But I was tired when I looked at it. I’ll have a look again and update the webpage.
The code I posted in the other thread is correct. tjw likes to rewrite functions to make them cleaner. I wanted to leave the code as is as much as possible, and that’s the result. The way you have it now, client 0 gets duplicated if more than 32 players are connected. This is the result of the function telling the client that there are one more players in the string than there really is, and since the client doesn’t have information on this specific player, it defaults to slot 0, with 0 ping and 0 xp. It will just display client 0’s name. The correct way is to leave the checks where they are, but change how i is changed. In the first check, the decrement is not necessary. In the 2nd, the decrement was causing the double names. Doing an i-- would result in the last 2 players getting redone. In actuality, that needs to be an increment of i, since the data was already put into the string. If you’d like proof that this function works, check out Clan FU’s server (et.clanfu.org:27960). We’re consistently over 32 players and can be easily checked.
sry bout the bump but the bugfix:
http://games.chruker.dk/enemy_territory/modding_project_bugfix.php?bug_id=029
the new added weapons work underwater but it still plays the sound or most likely the whole event. anyone know why?
jaybird @ you’re right about it. keep structure as is. remove i-- from the first one and change i-- to i++ in the second one.
ensiform @ are you making a server side only mod? If only the server side gets the update, the client will continue to display the wrong events. However you can arm stuff and revive players.
well i wanted a client also maybe optional… and i have a compile client yet it still plays the sound. (making a minimod with some fixes and some goodies (pm, doublejump for now)
Here’s another one:
src/game/bg_pmove.c:PM_AdjustAimSpreadScale
increase = (int)(cmdTime * viewchange * AIMSPREAD_INCREASE_RATE);
The cast to int makes spread growth due to turning extremely FPS dependent, with higher FPS getting far less (as viewchange becomes smaller, the discarded fractional component becomes more important). Taking it out gets rid of the FPS dependency, but also makes spread grow more quickly for everyone. That is probably the ‘intended’ behavior, but might cause some complaints.
At some point in the past (pre-rtcw release) more of the calculations were done on ints, and somehow this cast got left behind, despite the fact that ‘increase’ is a float.
Another pair of spread related buglets:
I’ll try to post code for those later.