It takes 11 rockets to kill a shambler (three with quad <-fun with enough space) - same amount as 11 DBS shots (=22 shells). The RL is obviously not favorable in close combat because of its splash damage, but for sniping shamblers it's fine, especially if there are other monsters around that can take damage from it too. People seem to be stuck on the notion that shamblers are immune to rocket damage altogether. 

But it's still a waste of rockets, that could as well be spent on a bunch of HKnights instead. 

There's mapping for Quake. And then there's mapping for DarkPlaces... 

Well having a skybox does'nt make it so theres a realistic sun that shines. I do use darkplaces.
So if a have a skybox in my darkplaces mod, how would a create a realtistic sun that shines and casts light over the map. I use QuArK! 

I use real time lighting. 

neg:
There's mapping for Quake. And then there's mapping for DarkPlaces...
?

re: 10890
Well having a skybox does'nt make it so theres a realistic sun that shines. I do use darkplaces.
So if a have a skybox in my darkplaces mod, how would a create a realtistic sun that shines and casts light over the map. I use QuArK!

since you're using darkplaces, put a super long range dynamic light then? 

Durr? How would i do that :D 

 

people have been mentioning. Does this include all aspects of the map's geometry, or is it just 'solid' geometry and excludes func_wall/func_illusionary? 

You can get past it by making .bsp files and inserting them with an entity. It works for illusionarys. Wait until you get near the limit then make your illusionaries into extrnal .bsp files. The entity will be the center of the external .bsp. I believe that you can use this feature in Quoth. You need to bear in mind for lighting. Unless you want your external .bsps to show as fullbrights in the map, you need to light them, so they need the lights which are casting lights on them to be there in the external .bsp, in the same positions. So it is something you should do towards the end of your cycle. 

hmm, okay, sounds like this could get painful as you say :p 

"57774 vertexes"
Fun...:E 

You might have to start using the command -hilimit if you are not already ;) 

i'm not sure, but isn't the 65k vertex limit a 'hard' limit, in that, you can't change it without messing with the actual bsp format?
but yeah, vertex limit isn't fun. had to split my current map because of it. 

Well, my map has an intro with a lot of detail in it, I guess that could be split off without trouble :E

After that it gets very hairy. Removing some of that lovely trim perhaps :( 

 

Trust me. Just keep going, get some details onto the really plain areas, try and work with a lot of illusionaries.

I think that the map is very imaginative and deserves to be done properly. I have faith that you can get a lot more details in. Re-thinking the railings is a good idea though, you could probably get something which looks better and saves on verts (and fixes that short cut issue ;) 

r_showtris 1 is a great way to find problem areas. 

new bsp format ++ 

I have a rotate_object with two of the brushes at right angles to each other; one lights ok but one does not light at all, and appears black to the player.

I have moved lights closer and lit the floor but it is still black.

Any ideas? 

The problem is that the brushes making up your rotate object are actually moved by the compiler. The compiler measures the offset of the info_rotate entity from the origin, then moves all the brushes that distance in the opposite direction. So from the point of view of the lighting tool your brushes are hovering very close to the origin of the map (the origin of the map aligns with your chosen centre of rotation).

In your case I think what must be happening is that there are lights near enough to the origin to light one of the brushes but not the other. It's a little bit like toggling the flag on doors that sets whether they are lit in the open or closed position.

So there are two options available. One is to bear this restriction in mind and modify your map to account for this. You might be able to displace the entire map such that the lighting state around the origin matches the lighting you wish to have on your brushes. Or you may be able to displace the map so the origin is in the void, and you can set up a special room to light the rotate_object correctly.

The other option I can think of is to create the rotate_object models as separate bsp files, with all world brushes and no info_rotate. Instead, you position the world brushes so that their centre of rotation is at the world origin in this new map file. This allows you to light the entity entirely independent of the rest of the map. You then modify the rotate_object qc to precache and set an external model, and finally add a point entity rotate_object at the current origin of the info_rotate, with the corresponding external model set.

Whether the second method is more effort than the first depends on how fiddly it would be to pull off the first way... 

Thanks Preach.

OK. After playing around this is what I have:-

- the origin is in the void and the map is completely sealed
- there are no lights near the origin
- if I remove the existing lights from around the rotate object, the object is unlit in game
- I have now set up a room around the origin and lit it with eight lights (each corner top and bottom)
- with the original lighting back in, there is still one piece unlit
- if I remove the lights from around the rotate_object again, and leave the lit room around the origin, the object is still unlit

Due to the size of the map, moving the whole map to get the object to the origin is not practicable. The centre of the rotate_object is @ -2056 3840 748

I'll post some screen shots later - game and editor. 

preach, are you sure of that? that doesn't really make sense to me at all. rotate_xxx entities are supposed to be lit where they are in the editor. if you make a map with two rooms, one room that is on the origin and is fully lit and a second with a rotater that is completely dark, the rotater should be dark as well. 

In my experience Necros is right. I have few large rotate objects and I created special isolated rooms to put them in to light them up.

http://www.zealousquakefan.com/wp-content/uploads/2011/01/zqftest03_construction32b.jpg

(I wouldn't make the texture sky now I'm using a skylight :p )

Texturing is different, that does involve it mis-aligning them due to moving to the map origin :( 

Sorry, I could be wrong about the lighting, I thought that it would be affected in the same way as the texturing is. The second way of fixing it would still work in this case, you would have no problems with texturing or lighting - just a possible headache getting the QC to support it (and maybe a logistics problem of spreading the map information over more than one file).