Remake Quake Winter MP Demo

[goldenboy]

Ah yes, Frikbot uses scratch*. We used the NQ version of Frikbot of course.

QW engines which fully support NQ progs should have no problems.

[mh]

I think if you have compatbility with Fitz, FTE and DarkPlaces you've satisfied 100% of expected compatibility levels.

This sums it up roundabout nicely. You could put huge efforts into compatibility with everything and end up spending more time on compatibility work than on the project itself.

[Supa]

By the way, RMQ seems to get a QC error in ZQuake (the NetQuake compatible Quakeworld client).

Which error exactly, how can you reproduce it and could you please link to the client in question? I know it'll still run with reduced functionality without the scratch* cvars, but I'd still like to know if it crashes on a particular client. That isn't to say that I'll work on support for every client (and it most certainly isn't!) - I'm just curious if it's our fault or theirs. :)

So it should work in all engines? ... When something can run unsigned code then Quake is almost always ported to it. ... Also, Is Remake Quake going to remake all of single player and multi-player?

Regarding console ports, we can't really support any unless someone is willing to donate the relevant hardware and devkits to at least one programmer and one mapper on the team. It's kind of hard to develop on a platform you don't have access to. :P I do doubt that the PSP would have enough memory to handle RMQ's sound assets, though I'd worry more over tripping stock NQ edict limits.

And yes, RMQ is both a SP and MP project.

[goldenboy]

I think the problem with models is that no editor supports properly placing them. Please tell me I am wrong and tell what editor nicely shows them.

Radiant. Able to place them very exactly where you want them.

Edit: No collision though, of course.

[Chip]

So, Radiant shows you the md3 or mdl model inside the other? That's just great!

Is there any special configuration or does it work out of the box? I always thought Radiant was a bit too complex.

[goldenboy]

mh want chain, urre make chain, gb put chain in map and make nice shiny!

Radiant was a bit hard to setup, first it wouldn't load the texture wads (had to symlink them into quake/id1) and then it wouldn't load the RMQ .def file.

This is on Linux:

- go to the gtkradiant folder (/opt/gtkradiant)
- edit games/q1.game and change

"entityclasstype" "xml"

to

"entityclasstype" "def"

- in the same file, set the "enginepath" key to your Quake folder, but don't change anything else in that file
- go to the gtkradiant/q1.game folder
- make a subdirectory for your mod, same name as the gamedir in your Quake folder (in my case "svn")
- put the mod's .def file into that (in my case gtkradiant/q1.game/svn/remakequake.def)
- put your texture wads into quake/id1 (or symlink under Linux)

When you start radiant, set "Project Settings" to "Custom Quake modification" and in the fs_game field, enter the name of the mod folder you created earlier (in my case "svn"), radiant should now load the def file. It is picky about the def file syntax; you're not allowed to use /* and */ for comments, so use // instead.

Radiant has a console, which will tell you which files it tries to load etc.

Now, to get the .mdls into Radiant (I use 1.5):

Create a misc_model entity in your code (it has to be misc_, because func_ is assumed to be a brush entity and thus Radiant doesn't let you simply place one), this is RMQ's version:

Code: Select all

/*QUAKED misc_model (.5 .5 .5) (-8 -8 -8) (8 8 8) ? 
Places a static model.
Static models just hang at the origin.
Static models don't collide (surround it with clip brushes, or func_nodraw if this is a problem).

"model"         Path to the model
"mdl"           Can be used, too, for path to the model
"frame"         Animation frame
"mangle"        X Y Z Orientation
Messing with any angle other than the Y (yaw) angle is usually asking for trouble (unless you know what you're doing).

*/
void() misc_model =
{
        if (self.model) // radiant does this
                precache_model (self.model);

        else if (self.mdl)
        {
                precache_model (self.mdl);
                self.model = self.mdl;
        }

        else objerror("func_model with no model");

        setmodel (self, self.model);
        setorigin (self, self.origin);

        if (!self.mangle) self.mangle = '0 0 0';
        self.angles = self.mangle;

        makestatic (self);
};


void () func_model =
{
    misc_model();
};

The latter is a wrapper for maps that use Extras.

Put the QUAKED part into the def file.

Now in Radiant, right click to bring up the context menu and choose misc_model. It will open the file dialog, select your mdl file (this will automatically set the entity's "model" key).

Done. The mdl will appear at (0,0,0). Select and pull it to the place you want it.

[Chip]

Thanks.

The chains look nice. Especially with some creepy lighting on them.

[mh]

Chains!

(Dies and goes to heaven)

[Urre]

Haha!

About the rotatings though, it depends. I mean, generally speaking it's easier to just make a model for the effect you want, such as the cogs in the new dm2 map, an animation-group on a static model. Great! What it's not so good for though, is solid rotating things. This is in fact a problem no matter if you make them out of brushes or models, since oldschool Quake engines just don't support collideable rotating bmodels. This is why Hipnotic went to such great lengths to hack support for this in. In retrospect they were crazy, seeing as they somehow managed to add other new features into the engine as I recall (correct me if I'm wrong), why not just add support for rotated collisions on bmodels? Anyhow! You could make a collideable rotating door out of aliasmodels just as well as submodels, seeing as you need to add collision entities in either case. When it comes to colliding with trees or whatever, do some clip brush magic or invisible_func wall trickery

And yes, it's nuts how rarely map models are used, seeing as modern games are littered with them, the idea is still the very same.

[Urre]

Wait, isn't .mangle a float? It was in Quake. You should let the mapper just alter .angles instead, no reason to have .mangle if it's not a float.

[Sajt]

mangle is a vector.

It's been a while, but I think that using mangle instead of angles for map entities was a common practice when you want more than just the yaw. I think there was some hack where maps would only store the yaw or something? Maybe it was WorldCraft only? I forget.

[Urre]

Yeah that's right, angle was a float, for yaw.

[Baker]

By the way, RMQ seems to get a QC error in ZQuake (the NetQuake compatible Quakeworld client).

Which error exactly, how can you reproduce it and could you please link to the client in question? I know it'll still run with reduced functionality without the scratch* cvars, but I'd still like to know if it crashes on a particular client. That isn't to say that I'll work on support for every client (and it most certainly isn't!) - I'm just curious if it's our fault or theirs.

Supa, I'll document it and reproduce the issues just for the sake of knowledge at the next available opportunity.

I am thinking it was complaining about an illegible server message (WriteByte ?) but I'd rather add the missing cvars into ZQuake and then see what is going on.

[ijed]

Mh - the water surface not being on the other side isn't an engine issue like I assumed - it's because the volumes in the dm7rq map are entities (triggers), so have all their faces undrawn while the player is inside.

At the same time it lets us have transparent water and non-transparent lava / teleports.

[mh]

Mh - the water surface not being on the other side isn't an engine issue like I assumed - it's because the volumes in the dm7rq map are entities (triggers), so have all their faces undrawn while the player is inside.

At the same time it lets us have transparent water and non-transparent lava / teleports.

It's a neat idea but I'm not sure if it's worth it... engines can and should be modded to support a different cvar for setting alpha for each liquid surface type, whereas this way - it doesn't quite follow the principle of least surprise so far as the person playing is concerned.

I'd vote for going back to regular water with it.

It's the type of arena that Quake isn't geared towards, so needs a machine more powerful than the norm (for Quake) to run.

For reference, I ran this in the January stable build of DarkPlaces on a Athlon 64 X2 Dual Core 4200+ 2.21ghz, 3gigs of ram, and a GeForce8800 GTS 640 meg. I know its not the optimal geometry for Quake, but it really shouldn't be in the 20s with no bots and no action going on, though I could be underestimating Quake's lack of efficiency in these matters.

I'm working on addressing this. Right now I've already got my engine able to handle huge open scenes very efficiently, and it doesn't even bat an eyelid at complex alias models. Complex brushmodels have a solution coming soon, but even on poxy Intel graphics with "consumer multimedia"-quality laptop hardware I'm in the mid-30s for this scene (I expect it to hit 50 shortly).