however I've removed the stupid limits that I'd accidentally left behind
in my panic to comment out the messed up code in r_part.c so software
clients now can use a setting of zero. Particles in sw clients will not
default to 2048 if you use a number less than 1 - it will now use 0.
Otherwise, I made comments to myself for when I actually fix this and
cleared up some silliness in comments I'd made. Nothing special.
Special note: To use cl_max_particles *right now* you can either set it
while playing and then restart the client (I think this should work,
it's archived. May not however) Or do this which I absolutely am
*positive* works:
clientname othercommands +set cl_max_particles number othercommands
So, again, while changing in game does not work, it at least is still
useful somewhat.
Misty-chan
I goofed up my code. cl_max_particles will not dynamically update with
this change, but ATM, this is safer until I can grok what I need to know
to fix the code I wrote.
Sorry guys,
Misty-chan
new cvar: cl_max_particles. This cvar is archived, has no lower or
upper limits (well, less than 1 is not allowed) and can be changed in
game at any time.
BUGS:
Only one so far. I can't figure out why it's doing this, but in software
clients, (well, at least X11) if you set it to 1 particle, it acts like
you set it far higher. 2 acts like you set it to zero... Or maybe
it's showing 2 and I just can't see it on my 320x200 window. In any
case, the vagary must be something in the software particles code,
because I basically used the same code from the GL particles code for
this as I used for the software renderer.
If nobody can find fault with my code, I'll just make a special note in
the console help.
In any case, let me know of any problems.
Misty-chan
nq, with the exception that some things were removed and others added. I
could have merged this, but I don't feel the system's ready for merging at
the moment. The quakefs code needs a bit of a cleanup and a tuneup before
it goes common. Like so many other things, that's dependant on other bits
of the puzzle being completed first.
function. There's probably some use for it later on anyway (probably for
metadata defaults or something), but the -hipnotic and -rogue checks are
now in quakefs.c.
external to the progs file are now malloced and then freed at progs reload.
All that needs to be implementd for gc to work is the scanner and deallocator.
slight api change: the getkey and free functions now take a user data
parameter (which is an aditional parameter to Hash_New.
cmd.c, cvar.c, quakefs.c:
clean up the resulting errors.
pr_edict.c:
use hash tables for lookups of function, global and field definitions.
should speed things up a bit, ESPECIALLY when type checking is enabled.
replaced the menu structure with just the binds listing so whoever does
that doesn't forget a binding we never use (run key? My forwardspeed is
600, wtf do I need a run key for?)
thinks:
o Full progs modularity
o CSQC should now be just a matter of creating the builtin functions and
loading the code.
o total independence from progs globals, functions and entity field layouts
on the conditoin that their definitions have not been stripped from the
progs file.
o optional (though currently forced on) type checking on access to progs
entity fields from C
o the progs engine is fully shared between nq and qw.
(or now unconditionally nothing since I killed the menu), it works as the
console. In the future, when the new menu is implemented, it will fall
back to console if there's a problem with the menu (like there isn't one.)
