then I could run your lovely tools on random non-windows platforms. 

That clears up some things, especially the fade gate thing.

I was thinking about porting Light to java purely because I suck at writing C, and it'd be cool if I could add my own functionality (read: bloat) to it. 

I have tried to use the vermis from lost chapters in one of my maps.
It looks like the vermis dosn't respond to the flags 'delay spawn'. Since it is a void map the vermis is visible all over the map.
Is this a bug or haven't you given the vermis the spawn- delay/silent/alert flags?

Hi, sorry for taking ridiculously long to respond... the WoW bug still has a hold of me these day. :P

anyway, to answer your question there is no spawning functions for the vermis. the orignal coiling thing was made for the situation you're describing, but we never really planned on having the monster be totally exposed and not hidden away in a little pit or somesuch before activation.

i'm planning on uploading a small 'update' to the chapters pak for qexpo and if you still want the feature, i can attempt to code in some type of spawning stuff for it in the update. 

the orignal coiling thing was made for the situation you're describing,

OK! Just as I thought.
I was planning to use the void map as a 'boss map' with the Lost Chapter map I'm releasing tomorrow, so it will be a little to late to do anything about it now.

I don't know if I will use the void map in a Lost Chapter pack in the future, so thanks for the offer but I'm not sure I need it anymore! 

I tried your suggested default settings for sunlight as recommended to inertia, I must've done it right (light entity with 0 brightness and the keys/values added). Does it look decent?

- http://www.phait-accompli.com/q/s4/pre/sun1.jpg
- http://www.phait-accompli.com/q/s4/pre/sun2.jpg 

the pics are very dark ... 

The joys of different gammas. Eh nevermind about it ;) 

I might have found the cause and fix for the synchronized flame animations. After checking in DP how it's handled there, the problem seems to be that lights are static ents and therefore aren't affected by the mdl sync flag.

I've just put in a simple hack to randomize the starting pose and it seems to work in both Win/GLQuake. Now Mike's and Chapter's torch rows look better. 

since the flag is in the model data and not in the quakec, it seems that from the beginning they intended it to be handled on the client-side. So this is just one of those cases where id screwed up? 

they didn't have separate static ents from the beginning and then forgot about it. It's pretty hard to notice if the torches aren't lined up close. 

I am sure some of you have mapped for RtCW so I have some questions to all of you:

1) I have unpacked models/mapobjects from pak0.pk3 and sp_pak1.pk3 and can now load the models inside Radiant. However, some of the dirs for the objects (mapobjects/bush, mapobjects/clipboard, mapobjects/lion to name a few) only contain textures and no model file, where are they?

2) Say I added a mapobjects/bodyparts/helbody.mdc into my map as a misc/model, how can I choose which skin is used on the model? By default, hel_body1.jpg is being used, how do I make the model use lop_body1.jpg instead? 

As of right now, my models/mapobjects dir is 27.5 mb in size, I am thinking this is too small and I am missing something? 

I need this answered ASAP:

how do i make 45 degree angles on walls in which the player does NOT get stuck on the edges??

im talking something like this:
www.qwplayers.org/inertia/problem1.jpg
www.qwplayers.org/inertia/problem2.jpg 

http://www.qwplayers.org/inertia/problem1.jpg
http://www.qwplayers.org/inertia/problem2.jpg 

1) Make sure you're using aguiRre's latest QBSP.

2) If that doesn't solve the problem, merge the angled wall and its supporting right-angled walls into a single brush.

The problem occurs when QBSP grows the brushes to create the clipping hulls, and QBSP grows the angled brush incorreclty so it extends past the right-angled wall and creates an invisible wall that players get caught on. There's a command in Tyrann's engine that lets you see the clipping hulls, and there's also a command in aguiRre's QBSP that lets you view this clipping hull in normal Quake.

Hopefully this makes sense since I just had some gin and a Sam Adams. 

my picture was wrong in shot #1

here's a corrected version (repalced the old file):

http://www.qwplayers.org/inertia/problem1.jpg

and am using aguire's latest treeqbsp and txqbsps, each gives me these results 

Not sure, but - is the player going to be able to go behind that wall? I mean as you have it built, you can go on the outside and the inside. If that isn't the case, why not just make a brush and clip it at 45 degree angle? Poor example but you may get the idea (# = solid)

___
|##\
|###| 

I don't think this can be solved in qbsp, I think it's an engine bug. I think they had a fix in QuakeForge for a short while, but it had other side effects which made some levels unplayable. I don't understand the engine side of it fully. 

i see that it is a rediculously complex issue! anyway i found workarounds using external clip brushes and other humdickery, but i aprpeciate all the help i got anyway. 

inert: clip clip it 

I enjoyed inert's unhappy guy immensely. 

clarify? 

I have found a whole lot more map models in WolfToolsSDK.zip so this part is getting better. However, there are still many mapobject dirs that have only the model file (textures missing) or only have the texture and not the model. I am puzzled. 

that there is one grey marble like seamless texture used to wrap around a generic 'statue' model. To save space the internal reference for the models may be to one lonesome texture you just have not spotted yet. I'm guessing since I don't have WolfToolsSDK installed, but I remember noticing that in a game pack that came with the GTKRadiant install before. 

I think there are a few RTCW models that don't show up correctly in the editor but do in game. I can't remember if the models' shader files are listed in shaderlist.txt by default, adding it might clear up a few missing textures if it isn't. Or it might not but trying won't hurt :)

there are still many mapobject dirs that have only the model file (textures missing)

Some models may have shaders which point to textures stored somewhere other than the model's directory. Or they might just be broken unused content that got included accidentally.

or only have the texture and not the model.

Like I said before, static mapmodels get baked into the BSP when the map is compiled and are loaded from there not the model file at runtime, thus there was no need to include all the models with the game. Alternatively, some folders might just be textures that are referenced by models in other folders.

There's a fair amount of usable custom models that have been made as well, hunt around for those. Custom models made for Wolfenstein: Enemy Territory will generally work in RTCW as well, although you may need to rewrite the shader.