radiant and qe3 don't set defaults on entities at all - they don't set any keyvalues you don't personally set except for origin and classname.

the 'default' is whatever the compiler, progs.dat, or engine assigns to the value, depending on which of them pays attention to the particular key. 

I'm not sure I understand - how would the compilers recognise any QC code? (e.g. light compiler)

The engine does. Lots of entities have default fields and values set in QC. Lights actually, now that I think about it, are an exception.

The engine runs the QC spawn function for anything it finds in the bsp, and defaults are taken from there (such as the health of the monsters.) 

Ok, thanks, I probably should have been clearer in that I was specifically looking to set defaults on light entities.

Anyway, I guess I'll just copy/paste an existing entity in the map, which should avoid me having to type all the fields out every time I create a new one. 

So I made some bars func_detail in and thought that they wouldn't cut up world_brushes. But appearntly they do. http://i.imgur.com/5oFwsBT.png

So I'm just wondering what's considerd good practice. Should I be cautious of ending up with too much unintended geometry? Is it better to have something like this floating near ground and ceiling not touching or is that over-optimizing?

Made a Q3 level before but still a bit green when it comes to BSP work. 

since func_detail does not affect vis, i think making them float 1 unit away should be perfectly fine.

otoh, that screenshot seems like it is a very closed off isolated area, so likely the performance gain of getting rid of all those extra cuts will be negligible. but if that was outdoors? or the cuts were propagating into other cuts? then it would be worth the few seconds to move the faces away, I think. 

Work a little differently to most other brush based engines. Func_detail in Quake will stick make bsp cuts however they are ignored by VIS.

Good use of detail is basically saving you time when you vis a level. 

Thinking about how your faces will split takes a lot of time to get the balance right. It could be a simple case of having a bar run along the bottom and top of your bars might produce nicer results. 

Func detail is really just to cut down on vis times and not really to cut back on faces. It's a balancing act between the two. If you want to have less faces then "Lift" the bars one unit off of the floor and ceiling when you do your final cut. Nobody will notice anyway.

The main thing to keep in mind about about func_detail is that where it touches the void you "Can" get a HOM effect in some situations so something like trim (and your bars are a sort of trim) is usually a big no-no unless you offset it by a unit (and again, it's not usually noticeable to even the most critical eye).

I'm not too sure about how that might effect "Dirt mapping" though because as I understand it it needs hard corners to properly do the calculations.

I would suggest that you just block out the level first and do a fast vis to check for leaks (and add at least 25% to whatever you think is enough room. It's not like you're paying for the paint, plaster, tiles or a heating bill) and add the "Trim" at the tail end of the process, which is going to eat up that 25% pretty fast anyway. 

if you need it to butt into the world for whatever reason, but don't want cuts, then func_wall that mother.

Just don't go hogwild with func_wall though, for ~*reasons*~ 

 

Detail brushes will not cause HOM as long as you don't use them to seal the void. And if that happens then you get a leak and vis fails. 

if you need it to butt into the world for whatever reason, but don't want cuts, then func_wall that mother.

Just don't go hogwild with func_wall though, for ~*reasons*~

Yeah, sometimes you might be better off making the base that the bars intersect into the func_wall, and leaving the bars proper as func_detail. 

Hello,

I seek a fgd based on a quake 1, which includes extras. "rotation, breakable, etc ..."

Can you help me. thank you very much 

That's for a particular Quake mod called "Extras", which can be found here:

http://www.quakewiki.net/quake-1/mods/extras-r4/ 

extras is pretty neat. I love the gibbable corpes, the sparks from the nailgun, the extra moveable objects, rain fx...

Not too keen on footstep sounds, cartridge ejections for the guns though. Oh well. 

Is there one? 

Texmex will allow me to import a 2048 and save it into the wad, but sikkpin_QE3 won't load anything over 1024. Hacking the 2048 onto a brush manually and compiling works fine in FitzBakerMarkV and QuakeSpasm. Even WinQuake loads the map and displays all the textures (although in the latter case the mipmapping is kind of wonky).

I'm not actually going to use a 2048 texture in Quake, but for the sake of argument: is there an upper limit? Are there secret but horrible side effects to large textures? 

there's no official upper limit but probablty each engine or tool will break in undocumented ways when you make something big enough.

For example in GLQuake the limit is width x height <= 307200 

... or 1024x300.

So, in GLQuake, that's 1024x256 or 512x512 tops. Curious if there are engines that have raised other bsp/netcode limits but left that one. 

correct, the line of code looks like this:

static unsigned trans[640*480]; // FIXME, temporary 

lol 

Is it ok to make brushes with liquids (lava/water) intersect with world brushes, and go outside of walls? I've noticed that if I use multiple brushes for water the edges where the brushes meet becomes visible in-game. I've read somewhere to never let brushes intersect so were a bit hesitant to do so. 

Intersect away, no problem. 

made it one big lava brush, but the geometry around cuts it up on compile with quite noticeable edges... Any tricks to get around this? http://i.imgur.com/YVzHLKL.png 

I've noticed that if I use multiple brushes for water the edges where the brushes meet becomes visible in-game.

This shouldn't happen.

Nor should the thing in the pic you posted.