News | Forum | People | FAQ | Links | Search | Register | Log in
Fitzquake 0.85 Released At Last!
New in this version: increased map and protocol limits (can load all known limit-breaking maps,) model interpolation, per-entity alpha support, new network protocol, more external texture support, hardware compatability improvements, many bug fixes, and a cleaner source release to make it easier to install and compile.

Go! http://www.celephais.net/fitzquake

(Thanks to the beta-testers: Baker, JPL, negke, Preach, and Vondur.)
First | Previous | Next | Last
 
> 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. 
Yeah... 
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? 
Sv_protocol 
.. 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. 
Ah... 
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. 
Bug 
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. 
Not A Bug 
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. 
But I Know That 
I'm just saying that typing 'game id1' in the console should probably revert that behavior. 
Yeah... 
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)

???? 
Ideally 
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? 
Sort Of 
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 
Cheers 
Just what I was looking for, also nice to be able to adjust the speed of the console. 
Ahh 
what's that command? :) 
Scr_conspeed 
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? 
Ah 
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. 
 
iirc, during the discussion, it was mentioned there's an alternative to the way stock glquake does timing without having to switch to sdl. 
Sure 
But pasting a .dll in the Quake folder is easy... 
Yeah 
And QuakeSpasm is simply FitzQuake + a bunch of nice fixes. If you like Fitz, you'll like QS as well. It doesn't alter the look and feel of FQ. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.