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. 

Trigger once and trigger multiple can have health too.

with a trigger once the collision box is removed once it has been fired too, so it won't block the player either. 

check the 'doors_dont_link' spawnflag on the func_doors. 

It should be possible to tweak the 'lip' value for the button so it doesn't move. Maybe there's an easier way though.

To get the button's texture to change when pressed/shot, use one with a "+0" prefix. When triggered the button will switch to the corresponding texture with a "+a" prefix. If you have more numbered and lettered textures it will animate in the cycle (+0foo, +1foo, +2foo, etc) and then switch to (+afoo, +bfoo, +cfoo, etc.) when pressed/shot. 

I'll try that later.

This is what I have so far. Requires rmqdemo2. Just unzip in the rmqdemo2 folder and playdemo metaldemo. 

when ever i create something it can never load the textures (Texture load failed: "textures/"). im doing a trem map.
what do i do? 

i have a problem. when i click cs it says:
Wad file gfx.wad doesn't have WAD3 id.

Helllpppp me pleaase 

small: Doesn't the Tremolous website have a guide on how to set up the mapping tools? You need the game pack with entity information (trem.game folder) and the game path has to be set correctly in Radiant. If it doesn't read the textures from the pk3, try extracting the textures and the scripts folders into tremolous/baseq3 (or however it's called) dir.

Alban: Err, install HL/CS properly then? The HL engine uses the WAD3 format, Quake has WAD2. 

What are the circumstances for losing weapons between maps e.g. is it automatic, can it be set on/off with a flag.

I have had to split my final map into two (this makes three in total including FMB_BDG) and I will need to to account for the loss of weapons as the maps are continuous.

(This is the map that I released a couple of years ago where I was over every limit so split it into two and only released part of it. The other half was finished some time ago and I am now populating it with meanies and will release it later this year) 

By Preach - its in this: http://www.celephais.net/board/view_thread.php?id=37116&start=201 thread somewhere. 

quake only resets weapons if you enter a map called start.bsp. this is the only case.

the alternative is if you use the console 'map xxx' command via a custom trigger entity. 

yeh i found out what to do thanks 

Trying to make a trap that shoots lava balls in an arc. Got everything working nicely except it refuses to display progs/lavaball.mdl as the projectile model...

So what am I doing wrong? :E