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 

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

As far as i know, no. For example, I have a map where i cloned a brush and its surroundings several times, and almost every clone is split in a different way, in cases some brushes merged and split again in a different way.

#13682 : thanks for the link, Spirit.

So i have to suppose that the tutorial Iika made has been lost forever. 

I meant the link as incentive to add map performance tricks there... 

Interesting, I haven't looked at the door code much. 

What's the usual entity count for the standard quake maps?

It feels fairly easy to hit the 512 entity limit! 

I hope it's not 512... 

Pretty sure it's 512 entities before you start getting in-game error messages.

(it might even be less because I t hink if you're shooting nails and stuff that adds to the in-game count or something) 

If you're refering to the edicts limits, that's 600. 

so far I've got 2161 entities and no warnings or errors.

I'm using TxQBSP 1.13 and Light 1.43, release 2, the one modified by MH for colored lights and multithreading. Can't remember which vis. 

As far as i know, lights are count as ents by light.exe, but they don�t add to the edicts. 

lights are not edicts, unless they have a targetname.

KillPixel: don't worry too much, modern engines handle well above 600 edicts. It's just that the standard id engines can't go over 600. 

Are things that do stuff during runtime.

A light without a target name is effectively deleted before runtime, and so not an edict.