InsideQC Forums

ARRRGGHH! my eyes are bleeding!

I've got 99% of this working but, my client craps out during signon #2
the last message received depends on the map. dm1 craps out around svc_time, dm3 craps out at svc_spawnbaseline, others seem to die at svc_spawnstaticsound2...

any suggestions?

client should send 16 bit angles to the server.

'fast updates' have additional byte values, which may conflict with any other protocols you might have tried to add support for in the past.
#define FITZU_EXTEND1 (1<<15) (byte after other bits bytes)
#define FITZU_ALPHA (1<<16) (byte after angle 3)
#define FITZU_FRAME2 (1<<17) (after scale byte, if present.)
#define FITZU_MODEL2 (1<<18) (after frame2 byte)
#define FITZU_LERPFINISH (1<<19) (after model2 byte, says when the entity next thinks, supposedly useful for step interpolation)
#define RMQU_SCALE (1<<20) (1 byte, comes after alpha byte, and yeah, perhaps I shouldn't include this here)

svc_clientdata has a load of extra bytes for 16bit stats.
and of course there's these:
#define svcfitz_skybox 37
string skyname. coulda used a stuffcmd instead...

#define svcfitz_bf 40
no payload. coulda used a stuffcmd instead...

#define svcfitz_fog 41
byte density, byte r, byte g, byte b, short time
coulda used a stuffcmd instead...

#define svcfitz_spawnbaseline2 42
byte bits, short|byte modelindex, short|byte frame, byte colormap, byte skinnum, (coord+angle)*3, byte trans
#define FITZB_LARGEMODEL (1<<0)
#define FITZB_LARGEFRAME (1<<1)
#define FITZB_ALPHA (1<<2)

#define svcfitz_spawnstatic2 43
fte doesn't support this, not found a map that actually required it so can't test it.

#define svcfitz_spawnstaticsound2 44
fte doesn't support this, not found a map that actually required it so can't test it.

dunno what 38 and 39 are... I've not found them to be important...

and of course the protocol version = 666, but that goes without saying.

make sure your client is also able to correctly receive 65k network messages.
I'm not aware of any other changes that are not actually RMQe extensions instead.

Hmm ya I've added everything thats labeled //protocol_fitzquake from 0.85.

i've added this which ALWAYS only returns 1, never 2.

i must be overlooking something

Thanks for your reply Spike ill double check what you've said.
I'm using in the shadows as a test mod, which i have seen use the spawnstaticsound2

signon 2 comes from having received all prespawn buffers.
check that you're actually sending the prespawn commands (should be via a stuffcmded cmd command, hopefully you have a DPrintf for printing stuffcmds...).
Make sure that your netcode isn't dropping weird-sized/large reliable messages resulting in the server constantly resending the exact same data and never getting anywhere with it.

This is documented on quakedev.com's wiki, which of course is dead now. I should post the documentation on my own site i guess, that wiki was pretty much doomed from the start.

I made some detailed notes on files/what changed when I was implementing 666 protocol:

http://forums.inside3d.com/viewtopic.php?t=2450

Just a list of files, what is different in each. Kinda as a check list ... Also here is an online diff file dreadlorde had made: http://ompldr.org/vNXRjNw

im slowly (when i have time) going thru diff between .80 and .85 comparing if i missed anything though not even protocol 15 is working. might be something with the proquake handshaking or something else

got this 99% implemented and InTheShadows runs fine. The alpha brush textures fade at a different interval making it look not as smooth as Fitz. Also the "grate" over the QUAD on the start map isnt showing up at all
guess the texture name doesnt start with a "{"

r00k wrote:got this 99% implemented and InTheShadows runs fine. The alpha brush textures fade at a different interval making it look not as smooth as Fitz. Also the "grate" over the QUAD on the start map isnt showing up at all
guess the texture name doesnt start with a "{"

Load up FitzQuake Mark V:

1) type tool_texturepointer 1 in console
2) Direct your crosshair over texture. Texture name you are looking at is identified on-screen, polygon highlighted --- gum chewed, asses kicked, game over.
3) Mystery solved ... hopefully.

[tool_inspector does some mind-blowing stuff too, but then again you know that ...]

Ya its an entity made up of multiple textures plat_*; that entity isn't even visible.
At 1st I though it was a single texture with an alpha channel. Weird.

The ent->alpha stuff all got wonky. encoding decoding, clamp etc... :roll:
So i just reverted back to ent->transparency, send/recv type FLOAT and everything works properly.
The walls fade like they should. But this breaks the protocol,
as demos would not be compatible with other engines that support protocol 666. Sigh.
I'll have to go back and figure out why this the byte encode/decode doesnt work for bmodels only.

also on a side note i had to do this....

Personally I found the byte encode/decode very messy too, and am still not certain that I've got it 100% compatible - Nehahra support really didn't coexist clean with it either; I would have stuck with a 0-255 range and used 255 for non-translucent myself. I understand that using 0 for non-translucent means that you can memset-0 an edict and have a default state, but it seems quite a small gain for the expense of having to do the encode/decode everywhere as a consequence.

Ive gotten everything added. ITSdemo loads fine. I went back thru and removed the cl_static_entities array and added a dynamic alloc etc...
but after all said and done, flame0 and flame2 do not show on the id start map, though it does, on the ITS start map plus i think i have a race condition error in the release build
i spent 4 hours diffing from a stable (pre protocol 666) build for that flame bug, nothing :#

you're gonna have to debug it the hard way then.
firstly figure out if the bug is in the client or the server (yay standardized protocols!).
then check to ensure the makestatic calls are generated/sent/received.
And make sure they're valid.
then make sure you've got static ents enabled...
and make sure they're being included in the visedicts list.
etc
good luck...

Phew!
first thing i did was jump to the makestatic funtion and found this comment that out and the torches are back! now i just need to clean up all this mess ive made in the past 6 hours

r00k wrote:now i just need to clean up all this mess ive made in the past 6 hours

git. Learn to love it