but its not just this, ijed.
I always wanted to know how the ending sequence works in particular, the slow camera ride and that fog and the awesomeness in general. 

 

no, the code isn't included (just the .map file)
here's the camera code and the associated portal trigger scripted entity:
http://pastebin.com/A1fjNpDz (no warranty) 

http://quakewiki.org
http://quakewiki.org
http://quakewiki.org
http://quakewiki.org
http://quakewiki.org 

really appreciate that! 

needs so much love. I needed to know a bit of info for some lights (needed the slow pulse style)...

There isn't even a page for the light entity! I really haven't got the first clue about wiki page editing though otherwise I might spend a bit of time on it. 

Very situational when it comes to marksurface improvement, depending on the map it may even increase marksurfs / cause leaks. Use when feeling adventurous or desperate ;) 

Great advice so far. I'd like to read more about what determines how faces are split so I can make more informed decisions instead of just throwing brushes around.

@necros, I did not know you could use external bsps in that way. I can think of like five instances off the top of my head that I can go back and do that way. Other than not being affected by light from the map or weapons, explosions, etc. are there any drawbacks?



Every link to mapping tuts on quakewiki are dead :\ 

they draw slower. I once tried to make a huge purely decorative terrain section into an external bsp. Looked fine, collided fine, got about 10 fps though.

but that was a very extreme case.

if you're just replacing out of the way geometry that is just for looks (like the tops of distant towers or something), then external bsps are the way to go.

they just take more work to set up. you need to be a little careful with your lighting so that it matches up.

a final draw back: skip textures won't be removed when the bsp is loaded as a model.

however, faces removed as part of the qbsp filling process are still removed as a bsp model.
AND faces which are not facing the player don't cause collision.

so you can make concave models whose outside faces are culled:

http://mobile.sheridanc.on.ca/~jonescor/temp/spasm0206.jpg
this is the external model, has a lot of useless faces removed due to bsp culling

http://mobile.sheridanc.on.ca/~jonescor/temp/spasm0207.jpg
as a model, all the skip faces are visible, sadly.

http://mobile.sheridanc.on.ca/~jonescor/temp/spasm0208.jpg
but from the bottom (where the skip face is facing away from the camera) we can't see it, so it looks fine! 

they draw slower. I once tried to make a huge purely decorative terrain section into an external bsp. Looked fine, collided fine, got about 10 fps though.

True, the code for drawing brushmodel faces is different than for drawing the world, it might be less optimized and worse if drawing thousands of polys.

http://mobile.sheridanc.on.ca/~jonescor/temp/spasm0207.jpg
as a model, all the skip faces are visible, sadly.

Yes, i never did add proper support to newskip.exe for creating external bsp mapmodels. :( 

What's the best approach?

All I need is a collection of brushes to appear once triggered, they don't need to do anything.

I think in Q2 it was a behaviour of func_wall; if given a targetname then they would start 'off' and wait to be triggered.

Glancing at the QC, the use function is this, basically;


// change to alternate textures
self.frame = 1 - self.frame;


Not sure what that does... although it makes sense that it would change to different animated +textures. Might have to try that out with some signposting monitors.

Anyway, my though on spawning func walls was to add a spawnflag START_OFF which decouples the startup functions from the creation of the entity if set (and will disable the skin changing).

Is this the optimal method? I assume any entities inside it when its created will become stuck, and if the player can see the thing pop into existence it'll look pretty goofy, but aside from those drawbacks it should work, along with proper collision. 

it makes sense that it would change to different animated +textures

That is exactly what it does, it works just like func_button where +<number> swaps to +<alpha>.


As for your question... perhaps just a really fast func_door with start_open and toggle? 

"classname" "info_notnull"
"use" "func_wall"
"targetname" "t1"
{
brush
} 

But the hackery options are going to be pretty high maintenance for what I'm planning. Basically I want to reconstruct large parts of a level once the player reaches a certain point.

Doors I've used before and they work ok, but do have the downside of crushing and moving stuff around.

Writing the entity type into the mapfile / entity entry in editor would work, but if I have, say, 20+ of these and need to modify them then it'll turn into a headache pretty quickly.

From the rambling post before really I'm asking if there are any problems turning on lumps of brushwork during run time. Apparently not.

Only time will tell :) 

ijed: if you are using standard progs (or progs that hasn't modified SUB_CalcMove), then as long as the speed setting on the door is high enough that the move would be completed in less than 0.1 seconds, the progs just does a setOrigin() call instead of normal physics movement, so Scampie's suggestion would work fine.

see if (traveltime < 0.1):
void(vector tdest, float tspeed, void() func) SUB_CalcMove =
{
local vector vdestdelta;
local float len, traveltime;

if (!tspeed)
objerror("No speed is defined!");

self.think1 = func;
self.finaldest = tdest;
self.think = SUB_CalcMoveDone;

if (tdest == self.origin)
{
self.velocity = '0 0 0';
self.nextthink = self.ltime + 0.1;
return;
}

// set destdelta to the vector needed to move
vdestdelta = tdest - self.origin;

// calculate length of vector
len = vlen (vdestdelta);

// divide by speed to get time to reach dest
traveltime = len / tspeed;

if (traveltime < 0.1)
{
self.velocity = '0 0 0';
self.nextthink = self.ltime + 0.1;
return;
}

// set nextthink to trigger a think when dest is reached
self.nextthink = self.ltime + traveltime;

// scale the destdelta vector by the time spent traveling to get velocity
self.velocity = vdestdelta * (1/traveltime); // qcc won't take vec/float
};

void() SUB_CalcMoveDone =
{
setorigin(self, self.finaldest);
self.velocity = '0 0 0';
self.nextthink = -1;
if (self.think1)
self.think1();
};


 

I'm not quite sure I understand func_detail. Does it just turn the brush into an entity? Is this something that's fairly safe/advantageous to use? Any tips or knowledge on the application of func_detail?

I realized making floor grates/grids from regular brushes is really expensive. Each "hole" is just as pricy as a cube, minus two faces. I went in and removed some from a small room and got about 5k verts back. The effect was cool, especially the way it cast light, but too expensive.

Now that I'm pressed for space I'm going back and seeing how I put high detail in the wrong areas.

From now on, action packed or dark areas will be relatively low detail, while slow, well lit areas will be for the scenic stuff. I know this is a no-brainier but it's also my latest epiphany...lol...

tangent: is it possible for one to manipulated the way light is cast with an "invisible brush", in other words, is there a brush that only effects light, so no visibility, collision, etc.

On could use low detail invisible brushes to cheaply cast light that looks as if its coming from behind a grate and just use a texture with transparency as the grate. I think. 

Detail brushes (func_detail) are for speeding up the VIS process. They are brush entities in the editor, but a QBSP with detail brush support will turn them into world geometry while not creating vis portals for them.

Attempting to lower verts/marksurfaces etc, one can use func_wall entities instead, for instance. 

Ok, got it. Not what I was hoping it was. 

Making grates would be good to use a texture, but doing it this way means you dont get the nice shadows.

I'm assuming you're making the grate by making individual brushes and not by using a carve tool. If you're using a carve tool I would stop straight away.

The general rule of making geometry for me is to stick to 16 units as the smallest sized brush and *only* go below that on rare occasions. Quake is a big chunky evil looking game, it's rare that you need fine details. 

In even the worse implementation of a carve tool, you're probably fine using it to create on-axis grate holes.

overlapping brushes get merged during bsp anyway.

it's off-axis carving that can lead to microleaks and such. 

Yeah I know the faces get split during the bsp process but it also makes it a bitch to go back and edit the brush later on if you're relying on the carve tool (I once made a level this way and wanted to change a couple of things and realised what an error I have made, it changed my entire philosophy on mapping)...

Though I knew the faces get split up I thought the way which you made the brushes determine how they split? 

but it also makes it a bitch to go back and edit the brush later on if you're relying on the carve tool
definitely. if you're making a grate or something similar, i recommend putting it in a func_group and then doing your carving so that the resulting dozens of brushes are still part of the func_group. you still can't edit them easily, but at least they're all contained.

I thought the way which you made the brushes determine how they split?

Not that I'm aware of? afaik, merging and splitting is all done at once.

for carving, i would say doing things like grates and such is up to you. i'd only recommend staying away from it with things like big world geometry for exactly the reason you mentioned. 

Clip tool is the same thing, or CSG subtract? I'm a nublet, I apologize. Of those, I've only used subtract, and very judiciously for that matter. gets messy. fast. 

We all started somewhere.

I'd offer more useful descriptions but I'm a bit hammered. 

carve = subtract