EXT_CSQC_1

[metlslime]

The csprogs is closed and reloaded on each and every map change. When the client disconnects, the csprogs is shut down entirely....Its not so far fetched that an engine could call CSQC_Init when it first starts up, and then uses calls to CSQC_WorldLoaded for each map change.

I was thinking about this the other day, I think one aspect of this that should be examined is how smart the CSQC is when a new level is loaded because:

- this could also mean you are now connected to a different server
- the cl.protocol might have changed, which could also mean that the list of supported extensions might have changed. (extensions that require protocol support.)

I also wondered about the game/gamedir command, but I suppose switching gamedirs wouldn't be an issue, since the engine would naturally shut down any persistent local VMs at that time anyway.

[LordHavoc]

There's another difference, trailparticles parameter order.

Hmm?

While playing around with models, I noticed that DP's gettaginfo builtin does not interpolate like the renderer will.

That will change when the whole overhaul of .lerpfrac happens (server will interpolate like csqc, will honor .frame1time, .frame2time, etc).

Additionally, Q3 normalizes each tag axis, while DP (and currently FTE) do not. This can result in some outrageously proportioned player models (see openarena's).
LH's stance appeared to be 'don't fix, let the mod do it if it needs to be done'. Certainly the standard q3 player models all work okay.

Normalizing sounds good to me, I'm a little concerned about side effects though.

[LordHavoc]

I also wondered about the game/gamedir command, but I suppose switching gamedirs wouldn't be an issue, since the engine would naturally shut down any persistent local VMs at that time anyway.

Sooner or later DP servers really ought to be telling the client what gamedir to use

[xaGe]

..That would be good LH.

[Spike]

There's another difference, trailparticles parameter order.

Hmm?

I'm fairly sure I've brought that up twice before.
You flipped the two arguments so ent and particle index are flipped, resulting in bad entities and particle effects.

That will change when the whole overhaul of .lerpfrac happens (server will interpolate like csqc, will honor .frame1time, .frame2time, etc).

The fun thing is that frame1time kinda sucks.
Quake animates by default, however, frame1time is an absolute time into the animation, which doesn't really match the way quake works.

Normalizing sounds good to me, I'm a little concerned about side effects though.

Imagine, you have a model holding a gun. In one frame, the gun is pointed upwards, in another its pointing down. It blends between the two.
If you normalize, at all points that gun will be a full square. If you do not, the forwards axis will shorten at the midpoint which will distort the gun.
This distortion shouldn't be significant really as it shouldn't animate that much during a single frame... But it can happen when you're switching between pain and taunt and fire anims etc, and it would only really be noticable in screenshots. But there is at least a valid reason why you might want to normalise even all if your models were properly normalised already. You only get problems when the model was intended to be normalised in the first place and you don't do that, or vice versa. It can be normalised in the mod, so I'm not sure if this is really too important, rather its just another difference between implementations (DP vs Q3).

Sooner or later DP servers really ought to be telling the client what gamedir to use

Then your serverbrowser can start listing more servers.