I actually think that in terms of features FitzQuake is pretty fine. Maybe it errs a little on the side of features for maps/mods while in development at the expense of features useful for actually playing the game, but that's understandable enough given the author's background, and overall there's nothing dramatically *wrong* with it (in terms of general features that is; I do think that there is some room for improvement elsewhere). A few nips and tucks in places is really all that it needs (let's have mouselooking enabled by default in the next version *please*). 

I welcome these types of requests... if I haven't added a feature to fitzquake yet, it's usually because my to-do list is huge; not because I think the feature is a bad idea.

Also Baker: Thanks for the bug report; is it consistently repeatable? I'll see if i can track it down. It seems unlikely that it's a cache/crc problem (player skins are allocated specially) but it could be anything at this point. 

I am serious. I used a bind to fire grenades with a key for ages but it felt like cheating.

Also I played with FOV 120 for a long time (because I was like OMG I CAN SEE SO MUCH MORE AND IT FEELS FASTER TOO!!!1), then I realise that it was idiotic. So I gradually went down again. 110 for a while, then 90. Now I have a widescreen monitor where ~110 is like old 90 according to some list by LH. 

I haven't tried to cause it to do it again, but I'll try to repeat the issue to verify it wasn't some one-time weirdness.

There is an outside chance it could have been caused by something silly like FitzQuake briefly losing focus during startup while video initialization was going.

@ Spirit

The reason "bestweapon" is "acceptable" to a Quake conversative is because the behavior is already attainable via other methods. It just reduces the number of keys you have to use and makes it so you don't have to write complex aliases.

So the effect of a bestweapon command is:

1. Reduce the number of keys you use
2. Reduce the complexity of binds
3. Make that kind of functionality available to non-experts in easier fashion.

It's kind of like impulse 10 and impulse 12, really. Of video mode switching. It doesn't offer anything new, it is just less of a pain. 

I have nothing against people using it, I just think it is kinda lame. And potentially bad. If you eg have the SSG or SNG as "better" weapon than the SG/NG, then you are wasting ammo. How do people actually use it?

I am obviously talking about singleplayer. 

I like using 3 keys:

1. One that switches the strongest non-explosive weapon. Lightning gun, SNG, etc.

2. One that throws a grenade and then switches me back to some safe weapon that won't kill me in close combat.

3. Something that switches to the rocket launcher or a fall back to the grenade launcher. To deal with clusters of enemies or zombies.

Pressing 1 through 8 is a bit slow and inconvenient. And impulse 10 and 12, while very useful and bound to my mousewheel, aren't always a good fit.

Not having those available just means I have to play more conservatively and save more often instead of playing more naturally.

I'm sure different ppl have different preferences. 

Reading back through my last post it sound a bit harsh. I like to emphasize that Fitzquake is great and I'm thankful metlslime made it. It's just that I once read stuff about this 'bestweapon' subject and people where very nagative (and ignorant) about it.

So Spirit, since you are one of the ignorant people (heheh :P) I'm going to answer your question in this lengthy post:

The whole point is to have MORE then one weapon priority script for as many buttons as you'd like to use. I'm a QW player mostly, and I like to keep my SP config similar to my QW cfg.

I'll post some examples from my QW config. 'impulse' can be replaced by 'bestweapon' if you use Qrack or DarkPlaces:

alias +boomstick "impulse 2 1; +attack"
alias -boomstick "-attack"
bind MOUSE2 "+boomstick"

The above simply makes me instantly fire a long distance shot with MOUSE2. If I'm out of ammo, I hit with the axe, which makes no sense in this case. The boomstick is VERY precise and pesky long range weapon. With Quad, this is basicly the Railgun for Q1, which shouldn't be underestimated. In other words: you need a script and button for it so you can fire it instantly at any given time.


Next:

alias +rocketlauncher "impulse 7 5 3 4 2 1; +attack"
alias -rocketlauncher "-attack"
bind MOUSE1 "+rocketlauncher"

The above simply makes me instantly fire a rocket. If i'm out of rockets, I'll switch to the SNG and keep firing with that. Don't have nails? Then I instantly shoot with the SSG, etc. All by pressing just 1 single button. How cool is that?

But... what if an enemy is standing too close to me? I'd damage myself with the rocketlauncher... therefore:

alias +shaft "impulse 8 5 3 4 2; +attack"
alias -shaft "-attack"
bind SHIFT "+shaft"

The above simply makes me instantly use LG. Don't have it or don't have cells? I shoot with SNG, etc. All by pressing just 1 single button. This is my main button for close encounters. Why shift? Because when I don't put pressure on my mouse by holding down a mouse button, I can aim better with LG.


alias +supernailgun "impulse 5 4 3 2 1; +attack"
alias -supernailgun "-attack"
bind MOUSE5 "+supernailgun"

So I already had a button for close encounters, right? But what if I have LG and I'm in the water? I'd discharge myself. The best weapon underwater is the SNG... you can figure out the rest by now.


alias +supershotgun "impulse 3 5 2 1; +attack"
alias -supershotgun "-attack"
bind MOUSE4 "+supershotgun"

The SSG is awesome for close encounters, especially when you got no LG and even better when you got Quad (obviously) and want to take out most enemies with one single bang without damaging yourself.


THIS, ladies and gentlemen, is why you see these insanely good players change weapons so quickly and efficiently. It is superior to the old way.

Tere's one problem:

The only downside is when you play a SP mod that includes NEW weapons that sometimes replace standard weapons or toggle between standard and new. This can screw up some of the weapon scripts since a certain number will now stand for a different weapon that has a different function (long range instead close range, etc.).

A solution for that is either create a new .cfg or just change the MOUSE1 into the good old +attack and cycle through the weapons with mouse wheel or by pressing the 1-0 keys, which is very in-efficient but, I suppose, more realistic since in real life you also must take some time to switch weapons.

But then again: Quake isn't about realism because irl most ppl wouldn't survive jumps from great heights while losing only 5% of their 'well being' and you can't carry all these weapons either.

So I hope this clears up the big mystery about weapon scripts. It can be a lot of fun to experiment with them, including when you're playing against bots because bots can switch weapons REALLY fast.
I remember that, back in the day, the good old Reaper bots by Steven Polge gave me quite some problems. Nowadays, since I can switch just as fast as they can, I laugh about it and they are no threat to me at all. In QW I practice against Frogbot level 20 (highest) and I almost always win (1on1). 

I find I set up different binds for the keys around the wasd keys for different maps -- but then I am (or was, realistically) a speedrunner, so have a rather different outlook :-) 

Seems to me that it's best to have the weapon binds organized in such a way that pressing them won't stop you from pressing movement keys at the same time... So having these weapon buttons around your movement keys doesn't sound smart for a speedrunner 'cause it will interfere with your movement.

Anyway, I've decided not to play (much) anymore, so I don't really care if the support gets added to Fitzquake. 

why instant weapon switching is not a good thing. 

Z_Realloc: failed on allocation of 38912 bytes in quakespasm-20100821.exe

i know this is for fitzquake, but quakespasm is based on fitzquake.

happened in a mod and custom map. events that were going to occur as the crash happened:

a monster was about to spawn a new entity with a model that was precached but never used until that point.
it was also going to play a sound that was precached but never played till that point.
model was a standard quake model, but fairly large (maybe ~512 units across?) and used alpha settings.
sound was 44khz 16bit mono .wav file.

dunno if that's helpful. i was unable to reproduce the crash and have fought said monster many many many times before without ever crashing either. 

Z_Realloc: failed on allocation of 38912 bytes
It appears you're hitting the Z memory limit for some reason. You can use "-zone 512" in your start-up script (default is 256k), or we could bump it in future versions whenever that is. If it's not reproducible... 

what is z memory? is this specific to quakespasm? 

On desktop operating systems there is really no reason to default the zone allocation in the engine to less than 1 MB.

1 MB provides compatibility with all mods.

I mean, the FitzQuake protocol uses a lot of memory itself and defaulting an extra 3/4 of MB for zone is nothing in comparison. 

...not to mention that lightmaps require 16MB...

To be honest, scrimping and saving on zone memory in that kind of situation is like fretting over a pinhole in a leaky bucket when there's a great big gaping wide rent on the other side of it. 

ok, so it's safe to just suggest to people playing my map to use, say, -zone 2048 just to be safe? 

The zone memory system can be replaced outright by standard malloc/free, and doing so shifts the technical burden from the player (where it shouldn't belong) back to the developer (where it should). I think there's one potential crash condition in the command processor with this, but can't remember specific details right now. It's easily worked around anyway.

True, memory fragmentation might become an issue, but the Big Dirty Secret of zone memory is that it is already prone to fragmentation as is (and actually contains code to deal with it).

One has to remember that Quake's memory system was developed under the constraints of running on a machine with 8 MB RAM and no virtual address space. A lot of the decisions made with it may have been valid for those constraints, but they're not so valid - and indeed limiting - today. 

what exactly does the engine use zone memory for anyway? it already has the -heapsize memory. 

as far as i know, the 'zone' command somewhat related with a large/messy .cfg files 

-zone

Type: Parameter

Syntax: game.exe -zone (bytes)

Description: Specify the amount of memory in bytes to allocate to holding dynamic information such as aliases.

Note: You will need to specify a value such as 512 if you experience game crashes because of too many aliases being loaded into memory. It is not necessary specify any larger value, since this value will work suffice.

Example: game.exe -zone 512 

Key bindings, the command buffer (used for every time you press a key in-game, includes cfg files which go through the same system), cvar strings, aliases, and certain types of file loading. -heapsize (known as "the hunk" in the engine) is used for loading models, maps and other big things. A part of this "hunk memory" is also used for keeping permanent copies of a part of MDL files so that they don't need to be reloaded between maps.

This isn't the only memory that Quake uses. GLQuake in particular uses several fairly large fixed-size buffers for lightmaps and texture loading (about 8 MB total; Fitz uses more for lightmaps but less for textures), and all versions of Quake use other memory buffers outside of this system for console prints, network traffic (also applies to SP games which go through the same code; will use more if large map support is enabled, and also allocates for up to 4 players as standard, even if you never run an MP game) and other bits and bobs.

OpenGL itself will keep backup copies of all textures in system memory which are used to recreate the hardware copies if you Alt-Tab away, and which were also used for texture swapping in the Bad Old Days of low video RAM. The framebuffer itself may even be backed up by system memory; I haven't found anything to indicate either way.

Windows Task Manager shows a standard unmodified GLQuake with no command-line params as using about 66 MB of memory on my machine, and I doubt if it's much different on yours.

So in other words the amount of memory specified by -zone (or even by -heapsize) is really mickey mouse stuff compared to the overall memory usage of Quake. Being conservative about them seems to be a waste of time and effort these days, in particular when more or less everybody is guaranteed to have 256 MB as an absolute bare minimum, and 95% of people will have 1 GB or more. 

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.