I can see how -quoth makes the task simpler from a coding standpoint, so maybe your idea is the right one :) 

ever was a standard in handling add-ons to add-ons, it *is* the -hipnotic, -rogue, -nehahra syntax. All engines work like this and should therefore be able to add this option without problems.

My proposal is a simple and neat solution to a growing problem. Once you start generalizing it, it'll just be more convoluted and less coders will be interested in adopting it.

A few simple lines in a few source files, that's it. In my engines, it's actually only two files and the header file is optional since the var is only used in common.c.

It should also be noted that a Quoth mod that's distributed in this way, will not shut out all other engines that don't support it. The player will then just have to re-arrange the pak files in the main Quoth dir instead, and this is something they'd have to do anyway.

The only drawback I've seen so far is that someone (like me) that regularly swaps engines while testing mods, will have to make some arrangements when using engines that don't support the -quoth option.

But I think I'd rather have that, than the pak file mess in the Quoth dir that I have now. 

i meant standard in the sense that the only engine that can currently load quoth + another mod is darkplaces, so if we copy that then all engines do it the same way.

However, I support your plan for its simplicity. You could probably convince lordhavoc to implement it in DP as well, since he often adds things to DP that are motivated by the needs of specific mod projects. 

of course the question of Quoth2, should it be put in the main Quoth dir or should it always be included in newer Quoth mods?

The former is the most space-saving alternative, but it basically requires that Quoth2 is completely backwards compatible in order not to break existing Quoth1 mods. Also, it requires that any further Quoth core development has the same characteristics.

The latter requires more duplicated files in newer mod distributions, but OTOH it'll not break anything and is the preferred route if Quoth is going to be further developed. There's a lot more freedom in this alternative.

Naturally, both routes will quickly become a seriously complex mess if new Quoth mods are placed in the main Quoth dir (which is the current situation).

There are of course more alternatives; e.g. to rename the existing Quoth dir to quoth_old and put together a new Quoth dir that essentially is Quoth2, which then can be used as the base with the -quoth option. Or add yet another engine option -quoth2 that automatically will include both dirs in correct order.

But all this is probably stretching it too far, this is not a proposal to solve any and all potential problems in the bright future when there are dozens of new Q1 mods in various versions being released each month ... 

The way I handle multiple pak files is with symlinks.

I name my extension pak "plaguespak.pak" and make a symlink like this:

ln -s plaguespak.pak pak(number).pak

That way I always know what is inside a pak file.

It's the same with progs. dat and (Q2) gamei386.so files; I have a progs.dat.qdq linked to progs.dat, a gamei386.lazarus.so linked to gamei386.so etc. The expansion pak retains a meaningful name _and_ the engine thinks everything is OK.

In my mod directories (like BB, hipnotic etc) I have the corresponding speedrun demos; I just dumped the paks in there, named them nhrun.pak and linked them to pak(number).pak. So I can easily watch a NH run of the map I'm on without changing gamedir or using complicated command line switches.

I guess that's expecting too much from the average windows user though :-/ afaik symlinks are practically unknown in that culture. 

I don't know what the hell you're talking about ;)

Now for wikipedia . . . 

No problem. At least you didn't ask if I was taking drugs.

A symlink is practically something that looks like a file, has a name like a file, but in reality only links to a file.

You can have a file called pak0.pak whose single purpose is to link to another file. If your Quake engine calls for pak0.pak, the symlink pops up and says "Hey! That's me!" and in reality only redirects the Quake engine to "quoth.pak" or whatever (any path really.)

Thus your Quoth pak can keep a name that means something instead of being renamed to pak0.pak (where you quickly forget what the hel is inside it.) Pretty neat feature.

When you combine this with shell scripts, you can do all kinds of stuff with files (create a symlink before you start your program, delete the symlink on shutdown, automatically... anything. You can redirect binaries to a number of different config files etc.)

For example, I have extra X11 config files for games in fullscreen mode. The game gets their own X server, their own config... and afterwards, everything looks like normal again. (X11 is Linux' windowing system.) The benefit is that nothing else uses that instance of X11, so the game runs faster/better. Symlinks are used to redirect the X11 program to non-default config files.

yadda yadda :-) it's practical for PAK file housekeeping purposes, that's all.

I also use symlinks to my Quake config in my mod folders. 

any details, I assume it's an OS/FS feature available in *nix? I don't know if Windows' NTFS has a similar feature, otherwise maybe upcoming (Vista++?) versions of it might.

Sounds useful if you know what you're doing. 

Sounds useful if you know what you're doing.

That pretty much sums up the *nix experience :) 

any details, I assume it's an OS/FS feature available in *nix? I don't know if Windows' NTFS has a similar feature, otherwise maybe upcoming (Vista++?) versions of it might.


There are NTFS hardlinks, which are basically the same thing I beleive, and I don't think they're officially supported. It's one line of script-code in AutoIt, I've used them to get around certain apps that don't tolerate root directories well (so I hardlink a subdir somewhere to that root dir and all is well) 

While testing the new -quoth engine option, I noticed that in Quoth2 (beta from Nov 2006), there's one h_scourg.mdl that's required from the hipnotic paks to work.

Are you aware of this issue or should I assume that Quoth2 actually will require hipnotic to be installed? 

we're aware of it, it's just the scorpion gibbed head model we forgot to put in the beta 

.. 

I've simplified the -quoth option handling and removed the global var so it's even easier to add the feature now. With this design, you can still add the -hipnotic option if you want to, even though Quoth normally doesn't need it. Idea copied from JoeQuake.

Code sections below from two areas in Fitz' common.c (leading dots only for indentation):

if (COM_CheckParm ("-hipnotic") || COM_CheckParm ("-quoth"))
{
....hipnotic = true;
....standard_quake = false;
}
==========
if (COM_CheckParm ("-rogue"))
....COM_AddGameDirectory (va("%s/rogue", basedir) );
if (COM_CheckParm ("-hipnotic"))
....COM_AddGameDirectory (va("%s/hipnotic", basedir) );
if (COM_CheckParm ("-quoth"))
....COM_AddGameDirectory (va("%s/quoth", basedir) ); 

thanks. 

I'm working on detailing a Q3 map at the moment, based on a blockout I did for the Raven lunchtime RA crowd. It doesn't need detailing because they play with it as is, but as long as I have the layout I figured I might as well throw some guns in the corners and make it Lun3DM5.

I wanted to go for a similar theme to Strombine, with plenty of brick and metal trusswork, but I'm finding myself getting stuck. I had gone ahead and been as abstract and free as usual with my blockout since surely I can bend any theme to any shape because I'm fucking Lunaran, but I'm finding the proliferation of 26� and 45� angles really don't lend themselves to the boxy functionalism of a factory space. They also make it impossible to do the distinctive sloped ceilings and peaked roofs.

My original plan had been to just go ugly 70's poured concrete everywhere, because the images you see of old bunkers and other structures where the whole building looks like a blank canvas for weathering and decay are really awesome. I thought I might get that kind of variety out of liberal decal use but it turned out to be a lot of decals for very little payoff.

I'm still wanting to do something that's less abstract and fantastical than previous maps, just because doing the same thing over and over is easy, but I'm afraid I might have confined myself to such things by starting with a blockout shell that requires it.

It's probably nothing anyone can help with per se, I just thought I'd vent, and GA is currently wrapped up in a discussion about economics. 

I saw your Q4 Strombine map (thank to PlanetQuake), and I think you should open a news thread for this map: it deserves it IMHO. I don't have Q4 on my PC, but the shots are particularly realistic: Good work ! 

so yeah, i'm working on a map (q1). i've been using glquake to test it, with no problems. i just tried it with winquake though and got the error:

"mod_numknown == MAX_MOD_KNOWN"

when i tried to load it, resulting in winquake dying. any ideas? 

of known "mods" in the engine that's exceeded. A mod is any unique bsp/mdl/spr that has been loaded into the engine in the current session.

The original limit was 512 and you typically exceed it by loading many bsps in sequence that also require many mdls/sprs. My engines and DP have higher limits.

What exactly are you trying to do when this happens? 

I see now that the original limit was actually only 256 in WinQuake and 512 in GLQuake, that's probably why you're seeing a difference. Still, it's not so common to hit that limit. 

well, it was only the 3rd map in the session i'd loaded, was checking round 2 others first (it's kind of an episode i'm working on).. and i'm sure i've played through many many more maps at a time than that! could it be something to do with not allocating extra memory? just realised i didn't do that

still i tried again and got it to load on it's own.. just relieved it's not a prob with the map 

in most engines, i.e. it doesn't help to have more RAM or heapsize. Is it reproducable? Are you using a custom progs that loads a lot of stuff? 

So here I am, mapping away happily in WC 1.6. I make a wall, it has Texture X on it. I replace it with Texture Y. I save, and close WC for now. Upon re-loading the map in WC, the wall that I replaced with Texture Y, still has Texture X on it.

Apparently, this certain wall does not want to change its texture, no matter what I try. I mean, I can change the texture to Texture Y during my current session in WC, but once I save and re-open it, the texture reverted itself back to Texture X. What black magic is this?

Anybody else experience something like this, and have a solution? 

You've got to rename texture X or Y to fix it, inside the Wad. I'm not sure what the proper convention is so that Worldcraft doesn't revert your textures. Alot of Kell's metal textures have the same problem, just for the name, though its not something that was possible to forsee.

Its an irritating bug but can be easily solved in TexMex. 

Renaming the texture in the wad file was not helping. Here was my situation.

I have 3 textures. wbrick_egy wbrick_egyv1 and wbrick_egyv2.

The wall that was reverting its texture was the texture wbrick_egyv1. So I went into Wally and renamed the 2 textures to wbrick_egvn1 and wbrick_egvn2.

So back into WC, the texture name of the wall was wbrick_egyv1. If I changed the texture to wbrick_egvn1, it would look like it changed, but in reality, the texture name was still wbrick_egyv1. So no matter what texture I could have put on that wall, the texture would have always been wbrick_egyv1.

So the only thing I could do to fix it was to delete the wall and make a new one with the correct texture.