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. 

I believe WC 1.6 only uses the first 8 letters of a texture name when matching names. 

i *think* the way it works is that when you're replacing the texture, if the first ~8 or so digits of the new tex's name are the same as the old one, it doesn't save properly and reverts to the old texture when you reload. next time it happens try renaming your new texture to w_brickegbnv1 or something like that 

 

In the mapping contest thread you wanted to know how hard it was to add monster spawning to the standard progs. There's a tutorial on how to do that at:
http://www.inside3d.com/showtutorial.php?id=171

It might not be exactly how it's done in quoth, but it will probably do what you want. 

i'll just go step quietly back into my corner.. 

a so called spawn64 progs for JPL's CDA map, it has basically the same spawning as Quoth (or Zerst�rer actually).

If you wish, I can update it to my latest std id1 fixes and you could check it out. 

i don't think the quoth spawning is that good... in fact, it's probably the worst way to do it. preach's looks a lot lot better and a lot simpler too.