Hi
I’m trying to debug the flamethrower, and noticed this behavior:
Notice how the flamechunks appear by the waterpump instead of around me. I’m also not burned despite the fact that I’m flaming the wall.
This was with a pure 2.60
Debugging the flamethrower
Chruker
(Chruker)
#2
lol, I just tried again and the flamechunks appear to ricochet between the walls in the city…
has anyone tried debugging flamethrowers?
has anybody any other oddities with flamethowers?
What I wanted to check with this is whether the flamechunks displayed by the client match the servers view, cause sometimes it doesn’t.
zinx
(zinx)
#3
We (the ET Pro team) are well aware of this… Server side flame chunks use entirely different code from the client side, and yes, the server’s flame chunks are VERY BROKEN, and do not match the client at all in many cases. Server flame chunks can go clear across the map, if aimed properly.
It’s on the TODO, but there are more important things 
Jaquboss
(Jaquboss)
#4
I wonder if you have done debugging code , or if you want to have it …
Yes it is buggy , but it is nothing serious
And players cant learn any dirty tricks so well cos they cant see serverside chunks…
BTW: you may try to make server chunks use their own model ( just make some simple autosprite shader) and you can see it better…
EDIT: uch all i said was stupid…
Prolem is just with hitting walls , it may be buggy , also server-side lasts when clientside is almost invisible…
KillerWhale
(KillerWhale)
#5
Ya, the ET flamethrowers are really nice…
It’s even stranger when you put cg_drawgun to 0, then it screws up the client sided flames too: patch 2.60 may have fixed the flame tank but you can still move pronely and infinitively fire the flamethrower (client sided error) and if you fire short bursts it will display a whole line of (client) firechunks across your screen. I think ETpro still has these same bugs.
Chruker
(Chruker)
#6
Thanks for the feedback. Its nice to have a sort of list when trying to debug this.
About debugging code. The red boxes are the serverside flamechunks displayed with g_debugbullets 7. The client side sprites were, in the case of this screenshot, displayed properly. Ie. bounching back in my face.
I wonder if the programmer who cooked up the distance falloff algorithm also made this part of the code …
bani
(bani)
#7
iirc the code is the same as rtcw. so you’d blame someone at greymatter or nerve or something 
but yes, the flamethrower is very broken in many cases. the server flamechunks behaviour is also sv_fps dependent…
Chruker
(Chruker)
#8
Found the root of one of the bugs. In g_missile.c :: G_RunFlamechunk there is this code:
// TAT 11/12/2002
// vel was only being set if (level.time - ent->timestamp > 50
// However, below, it was being used when we hit something and it was
// uninitialized
VectorCopy( ent->s.pos.trDelta, vel );
// Adust the current speed of the chunk
if ( level.time - ent->timestamp > 50 ) {
speed = VectorNormalize( vel );
speed -= (50.f/1000.f) * FLAME_FRICTION_PER_SEC;
While TAT is correct about his fix, he forgets to normalize the vel vector So the vel vector gets insanely large when aimed properly
The fix is pretty simple. Move the speed = VectorNormalize (vel) line so you get this:
// TAT 11/12/2002
// vel was only being set if (level.time - ent->timestamp > 50
// However, below, it was being used when we hit something and it was
// uninitialized
VectorCopy( ent->s.pos.trDelta, vel );
speed = VectorNormalize( vel ); // CHRUKER: #059 - TAT forgot to normalize it :-)
// Adust the current speed of the chunk
if ( level.time - ent->timestamp > 50 ) {
speed -= (50.f/1000.f) * FLAME_FRICTION_PER_SEC;
One bug down a couple more to go:
This one seems purely visual, since the serverside chunks when fixed with the above, won’t light anybody on the other side of the door on fire.
The serverside chunks gets the wrong start height when viewed in 3rd person. When viewed in 1st person of the shooter they appear to follow the flames.
When making a ring of fire by spinning rapidly the ring is there clientside, but the serverside chunks are far from forming a ring.
SCDS_reyalP
(SCDS_reyalP)
#9
Nice catch on the normalize 
The thirperson muzzlepoint issue is true of most other weapons as well, the bullets always come out near the top of your neck. I would be wary of moving the real muzzle point.
Jaquboss
(Jaquboss)
#10
Oops i must found my change cos it just spam one point and it is simply bad…
I can remmember i changed some stats ( range , size…) but no other changes , so i have to experiment…
aslo it is normalized already , or not ?
speed = VectorNormalize( vel );
here is my result …
Chruker
(Chruker)
#11
Jaquboss, sorry but I’m not sure I understand the two first lines of your reply. But on the question of whether its normalized. The answer is sometimes. This is the original code:
// TAT 11/12/2002
// vel was only being set if (level.time - ent->timestamp > 50
// However, below, it was being used when we hit something and it was
// uninitialized
VectorCopy( ent->s.pos.trDelta, vel );
// Adust the current speed of the chunk
if ( level.time - ent->timestamp > 50 ) {
speed = VectorNormalize( vel ); // <<<<<<<<<<<< This line, Jaquboss
speed -= (50.f/1000.f) * FLAME_FRICTION_PER_SEC;
if ( speed < FLAME_MIN_SPEED )
speed = FLAME_MIN_SPEED;
VectorScale( vel, speed, ent->s.pos.trDelta );
}
else
speed = FLAME_START_SPEED;
// Move the chunk
VectorScale( ent->s.pos.trDelta, 50.f/1000.f, add );
VectorAdd( ent->r.currentOrigin, add, neworg );
This original code only normalized it when it got inside the if statement. This wrong vector only gets used when the flame is reflected.
Chruker
(Chruker)
#12
some stats ( range , size…) but no other
also did you change both the server side and client side code? They don’t really share them so you have to make sure they are equal. This could be an explanation to why the flame is so long in your screenshot, but the red server chunks only has half the range.
Chruker
(Chruker)
#14
Damn. This one:
is kind of hard to overcome. In bg_misc.c find the ammoTableMP. Find the row of the WP_FLAMETHROWER and the column NEXT SHOT. Presently it is set to 50 ms. So the server waits at least 50 ms before spawning another flamechunk. By settings this value to 0 it closes most of the gaps between the flame chunks, but its far from all. Also it makes it dependent of the clients framerate. Depending on the clients framerate the flamethrowers ammo is gone very fast. And finally the server creates a lot of new entities. Close to 200 new entities. So some high framerate flamers could break the server with a couple of flamers 
This could perhaps be overcome by merging flamechunks which aren’t far apart, and perhaps enlarge them.
Anyway