wow, there's even more going on than i realized...

thanks for the clarification, i'll just go ahead and start suggesting a 2mb zone or something from now on. :) 

I'm in the process of porting protocol 666 into QuakeForge, and I ran into this (in SV_WriteEntitiesToClient):

//johnfitz -- don't send model>255 entities if protocol is 15
if (sv_protocol == PROTOCOL_NETQUAKE && (int)ent->v.modelindex & 0xFF00)
continue;

Shouldn't that be sv.protocol? 

sv_protocol is the cvar, IIRC. 

> Shouldn't that be sv.protocol?

I suspect that you're right. sv_protocol is the command whereas sv.protocol is the currently active protocol which only gets updated when a new server is spawned. Using sv_protocol here would mean that server messages would go all wacko if the protocol was changed while a server was running. 

that's a mistake. I'm not sure what happens if you compare the cvar directly rather than cvar.value ... it's a struct which means are you comparing the first element of the struct? 

.. is not a cvar, it's a global associated with the sv_protocol console command which sv.protocol is assigned to at server creation. So the comparison in SV_WriteEntitiesToClient() really needs sv.protocol and not sv_protocol. 

Yeah it's been a little while since i looked at the code. I guess it works as written but is unsafe. Should be sv.protocol. 

Ha ha ;>

Nice to see QuakeForge is getting updated. 

Due to a series of unfortunate events, QF more or less went into hibernation for a few years, though I kept poking at it occasionally (there is no year with 0 commits). I've been fairly busing hacking on things this past year, and lately, the maps on quaddicted have given me some real motivation :). git helps a lot, too (easy branching and stash).

I'm glad to have been of help. 

When running Fitz 0.85 with -quoth, it's impossible to switch to the id1 gamedir with game id1, because the engine thinks that the Quoth dir is the id1 dir, and thus nothing changes. 

If it weren't like this, certain releases wouldn't work they way they do. Those that come with an extra pak/mod dir but still require quoth as a base. 

I'm just saying that typing 'game id1' in the console should probably revert that behavior. 

that was implemented by request because BJP quake has it. ideally there would be ways to turn that stuff on/off in the console. (maybe multiple gamedirs like darkplaces would do it.) But to get the alternate hipnotic/rogue statusbars, you'd also need special variables for those. 

i was really happy you added the -quoth thing, but i guess it does make more sense for a more generalized multimod loading order thing.
maybe there'd be a way to detect what kind of hud layout to use based on what the gfx.wad contains? or are they all the same? 

if (hipnotic || quoth)

???? 

it would be awesome if it wasn't determined by folder name of the mod so you can make other mods that use the hud without having to get people to do a -hipnotic -game mymod.

checking quickly, the gfx.wad in hipnotic has all those extra weapon icons and id1 doesn't, so they do use different gfx.wad files. is that possible then, to look at what entries are in the wad file and then use an appropriate hud? 

Hey, I have a widescreen monitor (1920x1080) and changed my resolution in FitzQuake accordingly, and it works fine, except the UI (HUD, console, main menu) is terribly tiny. Are there any commands to prevent them from being downsized while maintaining the proper resolution? 

scr_conscale
scr_menuscale
scr_sbarscale


pretty self-explanatory... '1' is the default value, '2' doubles the size and so on. i find 1.5 a nice value 

Just what I was looking for, also nice to be able to adjust the speed of the console. 

what's that command? :) 

Also, when I started up FitzQuake just now everything suddenly moved twice as fast, as if host_framerate had been altered, even though it hadn't. What gives? 

you must have a 64bit system and dual core (or more) cpu.

atm, there isn't a solution that i know of apart from using a different engine. you can use quakespasm for now, which is basically fitzquake, except it uses some sdl stuff for timing which gets rid of the problem.
apparently, the way glquake (and by extension fitzquake) calculates time is with some method that doesn't take into account more than one processor. 

Yeah, I do. I normally use DarkPlaces anyway, just thought I'd give FitzQuake a shot. There was nothing wrong with it earlier today though, and I didn't disable any cores or anything in the meantime. Strange... 

i think i recall some people saying disabling additional cores worked for them, but that didn't work for me. 

> Also, when I started up FitzQuake just now everything suddenly moved twice as fast, as if host_framerate had been altered, even though it hadn't. What gives?

Quake's default timer is shit and Fitz still uses it. :( 64-bit, multi-core or power saving will wreck it, and it really needs an engine-side fix.