'doors don't link' spawn flag! rawr! 

a) get rid of the silly clip brushes above the quad
b) make the GA an RA or YA and add in other armors in other places
c) I like the quad placement and the quad teleporter placement
d) the placement of the high powered weapons is not very good:
the RL can see both the GL and the LG... this equals map domination and stuff etc etc

solution: add another rocket launcher on the lower levels, and switch the existing rl and lg positions

see how that plays! I'd suggest more radical changes but 1) i think it will play pretty well how it stands and 2) i dont have a very good qw setup here, so its hard for me to get a perfect grasp on the map dynamics

glhf! it looks really good also...

but make the blackness a sky texture, so rockets die when they hit it, and make it so players die on the vertical walls, not just the bottom of the abyss 

Thanks for the input and sorry for the slow response. I am implementing Neg!ke's "false ceiling/floor" in my latest speedmap, but thanks Mike for the QC idea :) 

Haven't played the map, but it sounds like inertia has some good feedback there.

Except: but make the blackness a sky texture, so rockets die when they hit it

Don't do this. Actually, yeah...go ahead and do it, then see how the map runs while the engine tries to calculate that much sky animation every frame :P
Not very render-friendly if played without a skybox. 

i know!! take away the outer box! nothing beats genuine, grade 'A', grey void! :D 

couldn't he just put a trigger_hurt out there to kill the rockets? i thought some sort of trigger_ would kill things like that... 

Actually, yeah...go ahead and do it, then see how the map runs while the engine tries to calculate that much sky animation every frame :P

This is only really a problem in glquake. Winquake doesn't care, and engines like fitzquake and darkplaces don't care. The solution for glquake (and any gl engine that hasn't rewritten the glquake sky code) is either a really high gl_subdivide_size or, in some engines (like zquake and fuhquake) there is a "fastsky" cvar or something. 

Yeah I know some engines have ways to deal with it, which is why I provided skyboxes for Chapters.

But Maric's map is DM, so I assumed there'd be a different and probably wider array of engines players might be using to play it, and there's also internet play to consider.

Even in FQ, with its efficient renderer and all, turning the skybox off in one of my void maps halves the framerate. 

that are the only real quakeworld clients (well, there's mqwcl but less than 1% use it) have the r_fastsky option as well as skybox support and a software client version. I don't know how well the vanilla sky renders in fuhquake-gl (and it's derivative ezquake-gl) but I believe it's fixed just as much as fitzquake. I understand most of the rendering improvements were made by borisu (qw262) and fuh themselves/together. You could try to run some tests.

So the array is not wide. You are considered a cheater if you don't use one of these clients with a certain ruleset and security module. 

i thought some sort of trigger_ would kill things like that...


hehe, yeah... trigger_void... ^_^; 

fitzquake has r_fastsky also -- though it's a bit obsolete with the r_sky_quality option. Well, unless you're fillrate-bound :P 

One of us seems to be having an email problem. I have received a number of repeated emails from you, and I replied to the first one I received on september 19. Also, I got the second repeated email first and I have only just received the first one today o_O 

I just hope that not too many emails are lost in space. I got your reply a week ago regarding the Rune mod, thanks. I've also got emails in weird order. I strongly suspect my home.se account, maybe it's the seemingly ever-increasing pile of spam that is at fault ... 

I am calling walkmonster_start from outside of the normal monster function. It does exactly what I want although it does not increase the monster count (which is not a problem) but I wondered why? 

The function you're using only updates the monster total on the server. There is a seperate function that tells the client what the new total is.

I think. 

My map, with or without light ents, after a run of light.exe, is 100% fullbright. There are no leaks (the map is in a large cube). I tested the map with -light 40 before I put in lights, at this point, I believe the map acted appropiately, everything was visable but not super bright. I took off the -light value to test the light ents, and with or without ents the map is super bright.

I was told to ask aguirRe because he is a lighting guru. 

I tried something else. I compiled the map with light ents with -light 1. The map was pretty much totally dark, as would be expected with -light 1, but the light ents didn't work.
hmm... 

Metlslime has it right, the infomation is only sent to a client when they first connect to the server by default. If you were running a coop server with your mod as it stands, I believe a player who connected after you changed the monster count would see the correct value.

Luckily, there's a way to update these stats after the fact, by composing your own message to the client, in a similar way to the way that temporary entities are done(ie teleflashes, explosions, lightning). The following code would adjust the monster count for self, assuming self is a player.

msg_entity = self;
WriteByte (MSG_ONE, SVC_UPDATESTAT);
WriteByte (MSG_ONE, 12);
WriteLong (MSG_ONE, total_monsters);

The 12 tells the client you wish to update the client's total_monsters variable, and the total_monsters in the write long is the server's value for total_monsters. There are a few other variables that can be altered in this way, 11 is total secrets for example. 6 is ammo_shells, although this is kept in sync with the server automatically. In fact, most of the possible variables are updated automatically or have functions that will do so, total_monsters is the exception. See http://wiki.quakesrc.org/index.php/SVC_UPDATESTAT if you want a complete list.

One more thing to note is that this isn't identical to the way temporary messages are sent. The message is sent using MSG_ONE instead of MSG_BROADCAST. Broadcast is an unreliable message, and so may be dropped over the network due to lag, but with particles that's not too much of a problem. You wouldn't want an altered monster count to be dropped, so you send it by the reliable MSG_ONE. If you strictly wanted this mod to work fine in coop, you'd want to send the message as MSG_ALL, which is supposedly reliable to all clients, or make the code loop through all the clients with MSG_ONE. 

There are additional info regarding this in my latest ToolTips. E.g. you must also communicate the killed_monsters value to the engine. 

You must have done something weird if basic lighting doesn't work. Take a look at tutorials e.g. here: http://www.planetquake.com/worldcraft/index2.shtm .

Make sure there aren't any light ents with excessive values or keys that saturate the entire area.

Try putting only this light near a wall:

"classname" "light"
"light" "300"

Then run:

qbsp mapname
light mapname 

If a face has a size of 64 x 64 is there any point to a 24 bit texture being larger than 64 x 64.

Is a 128 x 128 texture better than a 64 x 64 texture on a when intended for a 64 x 64 face at higher resolutions face or does it NEVER have an advantage? 

Yes, there is a point in them being larger. It's the same for all games really, it's not uncommon to see a 512x512 texture on a 256x256 face. If you are making a texture that's ment for a 64x64 face, make the 24bit texture 128x128, 256x256 would be overkill. 

i haven't experimented with this idea at all, since i want to know if it's possible before i start.

basically, i want to have two different islands in a void that are fairly far apart from each other. you can see the one island from the other at all times.

obviously, you wouldn't want the island in the distance to be at full detail because most wouldn't be visible and it would probably slow down like molasses in winter.

is there a way to make most of the details in the island that is far to disappear and not be drawn by the game? sort of like how models look shittier at a distance to reduce the number of polys and thus make it faster to draw.

and it is possible to have details gradually appear as you get closer to them?

it wouldn't even matter if the transition from low detail to high detail was abrupt or smooth (ie: if the details could fade in or now) 

if doom3 has LOD you can make the islands in maya or max, rather than out of brushes. 

http://www.saunalahti.fi/dnaumov/e1m2rmx01.jpg

vs.

http://www.saunalahti.fi/dnaumov/e1m2rmx01-new.jpg

I am still thinking that the former looks way better.