"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). 

I have mocked up a simple level to test this, and have come to the conclusion that the light tools are all unreliable when it comes to lighting rotate_objects. Necros is right that rotate_objects are affected by nearby lights, but I believe the code contains some kind of bug. My test map contains a brush entity whose lighting can be changed by toggling its classname from rotate_object to func_wall. In func_wall mode the lighting is identical to the world brush lighting, for rotate_object it looks off.

What is particularly worrying about this situation is that in Fitzquake some of the incorrect lighting is showing up as coloured even though there is no .lit file for the map. This seems to indicate a memory offset error - the light program is setting the pointer to the lightmap data incorrectly and so the lighting appears offset - and in the edge case escape the lightmap data segment completely to read random memory instead.

This is supported by replicating the coloured light effect - which can only occur on the last brush entity in the map, and then adding a func_wall to the map. Compiling with the func_wall added makes the colours go (although the lightmap is still incorrectly shaded), and then removing it restores colour again. All of this is consistent with a bug setting the lightmap offset too high for these rotate_entity objects - I assume that the lightmaps are stored in ascending order in the bsp.

I've never really looked into the source code for the quake compiling tools, so I might not be the best person to actually nail this bug. But if anyone thinks they could, I'd be happy to send them the maps that reproduce the problem in the way described above. 

that is all 

Hi folks, I got this eternal doubt:

-If I create a Q1 sp episode changing all textures/sounds may I charge for money(a small fee) those who download from my website ?

-I guess a standalone project is out of question.. but simple levels ?

* I've read all ID legal blah-blah but I'm more confused than ever ! 

The editor view:-
http://img703.imageshack.us/img703/7003/bspeditor1.jpg

The compile result:-
http://img839.imageshack.us/img839/5452/compile1.jpg

In game and lit:-
http://img834.imageshack.us/img834/4684/ingamelit.jpg

In game and fullbrite:-
http://img854.imageshack.us/img854/8459/fullbrite.jpg

It will have to stay as it is. 

-I guess a standalone project is out of question.. but simple levels ?

A more important question before that issue would be, how would you convince people to pay for a few quake levels?

That kind of thing was done in the mid-90s but not now :P 

If the next brush entity you add to the map is lit fully on all surfaces, you'll probably find that the unlit surface goes away - it'll start drawing the lightmap from the newly added model. You might even consider adding a superfluous func_wall which is lit on all sides in a box outside the map, just for this purpose. It's a huge hack to work around a compiler bug, but better than nothing. 

Unfortunately, no joy.

Nevermind, the rest of the map is of such astounding beauty, with gameplay to test and please the most ardent fan, whilst the cognoscenti of fantasy architechture will be in raptures for the entire time. Yeah, right!

Que Sera Sera 

noticed you had texture alignment that got trashed by the compiler.

an easy way i've found is to first build your brush and align the textures. next, make your info_rotate origin entity.
now, with texture lock ON, select both the rotater and the origin and move it so the origin is on '0 0 0' (or whichever axis is relevant).
then turn texture lock OFF and move it back to the proper position.
this effectively does in reverse what qbsp does.
i don't understand why qbsp can't have it's own version of texture lock when it's moving bsp models around. :( 

Not perfect, but kilometres better than jet black. It now looks as though the outer ring is oak and the crosspiece is walnut. Nice.

I'll go with that - thanks. 

So I have a set of bars blocking an area that can only be opened once a computer is destroyed. I think I need to make a func_button with health set to something, so when the player shoots it, it triggers the door (bar) to open. I think there's some problems with this though:

1. don't func_buttons also move when triggered? Having the computer move when triggered would be weird. Is there a way to change the texture (or if it's an animated texture go to a different frame)?

2. How can I target multiple multiple doors? Setting the bars to all have the same name seems make them all move in the same direction, regardless of the direct I've set them to move. 

I figured out issue 2, I should have been using a trigger_once, which I'm doing now and it's working fine.