InsideQC Forums

Chip wrote: You mean the authors, right? I guess the community will be happy to have all these mods available.

Quite a few members of the community are... particular... about copyright law.

Error wrote:I too would like to speedmod. I don't want to host it though, as most of mine weren't too successful.

Mmm, could be fun.

What I'd love to see is a project which really advertises DarkPlaces as a game development engine, rather than just a wiki. The project would include lots and lots of examples, easy to use code snippets which do all the boring things for you, like animation systems, animation blending, physics ...

yup, the cvar sv_maxvelocity is by default set to 2000, so set it higher in autoexec.cfg

That was the original mauvetogoal idea as used in several mods, but the one you linked to uses .movement etc for a movetype_walk entity in DP. Botclient stuff, y'know.

Yay, MauveToGoal got a mention!

btw the easiest way to get rid of the zig-zag of movetogoal is to make movetogoal seconday, something like this (untested).


void(float howquick) MauveWalk =
{
self.ideal_yaw = vectoyaw(self.goalentity.origin - self.origin);
ChangeYaw();

if (!walkmove(self ...

ceriux wrote:is there any type of documentation of FRIK FILE?

dpextensions.qc has a reasonable explanation of how to use it.

Yep, that's the sort of thing I used in Squad. Be careful not to make the smoke too thick or it goes solid white in the center, and of course bear in mind that the particles aren't affected by lighting.

Actually I don't think I ever released the version of Squad with the smoke etc. I'll dig it out today.

The method I used in that smoke grenade is actually pretty ugly and slow; I only used it because it was required to work with all engines.

If you're looking a DP specific smoke I seriously recommend using effectinfo.txt to make particle-based smoke. Here's an example:

http ...

Mouth is too low.

Shrug. I've never had that problem so I can't help.

Downsider wrote:Max 9 doesn't have md3 export, no plugins for it either.

There are HL SMD plugins though, and lordhavoc's DPMODEL can convert SMD to MD3.

Why do you need to preserve the bones? They're lost on conversion to mdl anyway.

Try resizing the model without changing the view angle? Too large models are all I can think of that cause floating point errors in qme

For some reason qme's md2>mdl convertion is a bit bust.

To fix it you have to export from qme as mdl, then load it in quark, then save as mdl, then load it back in qme to import the skin, then finally save as mdl again.

Silly, but it works.