cool! thanks! :D 

Hey, just d/l'd FQ 0.85 the other day after wanting to run through a little Quake SP and remembering I didn't really like DarkPlaces last time I messed with it.

Anyway, FitzQuake has just replaced DP for me. :D

I'm having one problem, though - can't seem to get my fog settings to stick (tried it in both autoexec and in config after figuring out that scr_crosshairscale had to be changed there :D. Anyone have an idea why fog density wouldn't stay set? R,G,and B seem to stay set, fwiw.

System specs: XP Pro, A64 X2, 2GB DDR & 8800GTS 512.

Other than that, FQ works a lot like the UGL Quake I loved back in the day, but MUCH nicer (love the working fullbrights and gamma)- Thanks for the updated version! 

That's a known issue, the current behavior is for each map load to set the fog based on it's setting, and if it has no setting, it gets reset. 

I should have guessed it was something like that, since everything else works quite well. I'll just make a keybind for it if I find myself really missing it. :D Also wow, your update feels like Quake the way it was back in '95, thanks again!

(Now, time to drop some of CZG's, Vondur's and Elek's maps in to try 'em all out again...) 

Travail, Quoth and Tronyn's latest efforts :) 

I receive an error I didn't know, as it appears only in hard skill

8062 byte signonbuffer exceeded the standaard limit of 7998

Aguier's glquake doesn't give a message.
Is it the same as too many eddicts? 

no, it just means the overall level has enough stuff that the initial message to new clients is too big.

BUT: if you don't get this warning in aguirre quake, it might be okay. Try in fitzquake using sv_protocol 15 for a more accurate test, or just try it in regular quake (glquake or winquake) and see if it crashes. If it doesn't crash, i think you're okay. 

I was surprised it was only in hard skill.
easy/159 normal/169 hard/175

So it seems hard skill has 6 entities over the limit. 

and yes, the map is rather full.
925 entities, 263 lights, 26288 faces. 

to give more explanation, the "Signon Buffer" is basically a snapshot of the initial map state, which includes the initial state of all edicts, plus any static entities in the level. So you could reduce it by reducing edicts or by reducing static entities. 

The signon buffer has to detail every entity which spawns with a model set. One of the ways you can reduce the size of the buffer content is to have some entities set their models a few frames after the server starts.

It is possible to do this with a hack that works in virtually any quake mod that contains a func_wall and an info_notnull, but it relies on you having some func_walls to apply this to. Take one of these existing func_wall entities, and change it's classname to info_notnull(without making it a point entity). Then add the following keys:

"nextthink" "0.5"
"think" "func_wall"


This will make the func_wall spawn 0.5 seconds after the server starts, which removes it from the signon buffer. Instead it gets sent as one of the first update packets. You need to be careful picking a func_wall to use for this trick. If some other entity will spawn on the wall or may move into it before it spawns, then this trick will probably trap that entity inside the wall. So be a little careful.

This trick cannot be used on any entity which requires a precache, which limits it a great deal. Brush entities have the advantage of getting their model precached automatically. A silent func_plat is possible, although those will give you warnings about sounds, so not a good idea. A func_illusionary will not work, as they are made into static entities which must be in the signon buffer for players to see them.

Incidentally, this trick can be easily adapted to make func_walls spawn in levels when triggered. Take the info_notnull wall, and instead of think/nextthink, add "use" "func_wall" and give it a targetname. Just be careful about entities getting trapped inside... 

Is Fitzquake-SDL likely to run on an ARM-based device (Nokia N900) running Debian Linux, assuming the required libs are present? 

It would have to be recompiled for ARM, that's for sure. AFAIK, SDL can be compiled for ARM, so there's no problem there. What about GL support on that platform? I'm not sure, but I doubt that OpenGL ES is enough to run Fitz. 

Considering that even much "lesser" phones like N95 and even N80 could run accelerated GLQuake and Quake2, I would be surprised if this wasn't the case for N900. 

It seems that Nokia N95 has OpenGL ES 1.1 while the N900 ships with ES 2.0. 

#290 should have been posted in Phone Thread :P 

for the explanation.

I changed six func_wall ents but for some reason the signon buffer keeps alerting.
Think I delete some entities as it seems the most simple solution. 

Talking to a friend about playing Quake on Linux

fitzquake has horrible issues with x86_64
namely using unsigneds to store pointers, VERY BAD PRACTICE

Thought whoever is going to be working on the next version might want to know about this... 

yeah, pointers are treated as 32-bit in various places. Maybe if 64-bit becomes important, I'll figure out what is needed to fix it. 

Since when did quake need to address more than 4 gigabytes of memory? 

For the sake of keeping FitzQuake 0.85 stuff where it can easily be found:

FitzQuake085_rotate.exe (with source)

http://www.quake-1.com/docs/rotate/fitzquake085_rotate.zip

Sample rotating object map (rotate.bsp and rotate.map compiled with LordHavoc's new version of hmap2)

http://www.quake-1.com/docs/rotate/rotate_map.zip

Rotation support (avelocity) added from this tutorial:

http://www.quake-1.com/docs/quakesrc.org/129.html

YouTube video of spinning object in DarkPlaces, appears to work and look the same in FitzQuake085_rotate.exe:

http://www.youtube.com/watch?v=Bke3wPWsH38 

What the hell is going on in that video? :) I can't tell what's rotating ... the player? But why is the room turning ... I .. ARGH!! 

the player is not rotating, but the thing he's standing on is.

How is this different, in technical setup and/or mapper use, than Hipnotic's rotating stuff?

Could be a big boon if the texturing of these rotators is more sane. 

no func_movewalls 

I've been following the thread on i3D as you guys discussed this. The remaining things I think would be ideal:

- engine: rotate player orientation as the object they are standing on rotates.

- compiler: origin brush support for ease of use

- compiler: fixed texture alignment on rotating models (right now it's all wrong because the brushes are moved to the world origin during the compile process without locking the textures)

Also I believe the way collision is being done for this is not correct, rotating the collision hulls can have some pretty non-optimal results, especially if you rotate a bmodel onto its side, since player bounding boxes are taller than they are wide. But doing it correctly would be pretty hard. I think what quake2/3 do is, save the original brushes in the bsp file and expand them to collide as needed, and don't use hulls at all.