RANT: What's wrong with CSQC

[ceriux]

how would you use this model viewer?

[Spike]

the lack of a space was intentional.
modelview progs/foo.iqm
or whatever.

[LordHavoc]

[Nahuel]

[Spike]

electro was using psk models a while back, he said he found them easier to create (wasn't a DP project though, so they were all animated properly).
there's a psk shambler model around too, unfortunately it only has one framegroup in it.
either way, you can fix it with a .framegroups file so there is at least a path for backwards compatibility. any old/buggy models can be fixed up by almost anyone with a suitable example of how to do it.
psk requires more work to load, so if you have high vertex counts, iqm is definitely the better choice. this assumes you've got a working exporter in your editor that doesn't require lots of tweaking for each and every export, anyway. having to depend on an external tool like neosis is a bit crap really, so yeah, psk is just easier, assuming everything gets treated the same by the engine anyway.

also, model formats is a bit off-topic, this topic is meant to be about all the fuckups in csqc, not other junk in the engine.

[Baker]

The best and scariest Shambler I have ever seen in Quake is a psk.

http://quakeone.com/forums/quake-mod-re ... mbler.html

[toneddu2000]

[goldenboy]

Yeah, you can use .think in csqc.

[toneddu2000]

ah ok thanks gb. So can I use most of the SSQC constructs even in CSQC? For example all the fields like .solid, .movetype, etc?

[goldenboy]

I haven't personally used those yet, but I'm pretty sure you can. Try it! For a definitive answer about what you can and can't do with entities in CSQC, Spike or LH will be needed though.

[Spike]

.solid works in both engines. tracelines will just work as you'd expect. afaik this should work fine in both engines.
.movetype is more complex. it doesn't do anything at all in dp. in fte, you can configure various different engine behaviours via a global (the name of which currently escapes my mind). with fteextensions.qc included, this global has the value 2, which gives csqc the same physics as ssqc has. a value of 1 will vaugely emulate dp. a value of 0 will disable all movetypes (and unfortunately also .think too, as was intended in the original spec, as it is dependant upon movetypes).

hud-only engine implementations of qc might not even support traceline/tracebox etc, in which case all of these are just dead fields as far as the engine is concerned. for partial implementations its really the engine's choice as to what is omitted. :s
the original spec omitted movetypes because I wanted to be lazy - in an ideal world, sv_phys.c+sv_move.c would be shared between both modules in some way. explicitly allowing those to be omitted with the engine still considered 'complete' was intended to make engine uptake easier, or at least simpler anyway.

[r00k]

[Spike]

my opinion is that any csprogs.dat that reads the vid_conwidth cvar expecting it to affect anything but the console (which is outside the scope of csqc) is a buggy csprogs.dat.
read VF_SCREENVSIZE if you want to know the current virtual screen size (without depending on the width+height args), read VF_SCREENPSIZE if you want to know the current physical screen size.
@baker: note that these were not in csqcwinquake. you should probably consider adding them.

fte's cvar() builtin has a hack in it so that vid_conwidth and vid_conheight queries return the current virtual size, regardless of the cvars. this allows a 0 value to be used for auto or whatever.
cvar_string() doesn't contain this hack, so you can still use that to work around the work around.

any mod that uses vid_width+vid_height expecting it to be the physical width+height is buggy too (vid_restart may have failed, or simply not been used yet, or vid_mode overwrote it or whatever). DP requires it for certain things. this annoys me.

needing to depend on the engine recognising ANY specific cvar is a bad thing, imho. Oh, and its a pain to document...