It may be in the QC as both of the official expansion packs came with a patch to the engine but far more likely that it's in their own custom progs.dat otherwise all of the new features would have been carried over so anyone with a 1.08 Quake engine could take advantage of, lets say particle walkways or rotating objects (or anything else that didn't have a special sound or model attached to it) in Vanilla Quake levels (ie in the ID1\maps folder). 

There's a hack to execute console commands like sv_gravity, but it's messy as it has negative side effects which would have to be worked around.

If you go for a custom progs dat with universal gravity support, be sure to also fix some of the common standard bugs like fish count, death solid frames, and so on. 

That fixes it. No idea if it fixes anything else 

Am I using the wrong combination of compilers, or does using func_detail really make it impossible to compile -onlyents? Building BSP with TxQBSP 1.13 XT -onlyents, func_details apparently don't get stripped out they way they do with a normal compile, leading to a corrupt unloadable BSP with extra bmodels in it. 

func_details are added to the map as if they were entities, it's only because the compiler knows to do something special with them that they get removed in a full compile. It wouldn't be surprising that unaware compilers would leave them in for an onlyents compile, and I expect it's just an oversight that an exception hasn't been added to compilers that do support func_detail.

Two workarounds I can think of:
1. Save your map, then select and delete all the func_details before you do the onlyents compile. This should work just as if the compiler had skipped them, and they should appear in the output map because they were included in the original compile.

2. Use adquedit to extract the entities from your map into a text file, make the tweaks, and export them back.

Neither of these workarounds are things you'd want to do regularly (they'd be useless as a way to save time on a "changed lighting" compile as they take longer than you save by using -onlyents). But if you just need a last minute tweak to a few ents on a fullvis'd map they might be just the ticket. 

I should probably roll this out as official soon.

www.voidspark.net/files/bjptools_xt/bjptools_xt_test_130414c.rar 

 

func_detail don't make it impossible to -onlyents, it was a bug. Afaik TyrUtils handles this properly too. 

I'll give that compiler a shot just to give you feedback but I've been strongly considering just going full Tyrutils (already currently using tyrlite, because, who doesn't?) 

Well, those tools work great. Fixing my fucking batch files also helped. :( 

WTF! Who did this? Is there a documentation anywhere? Or a readme? 

in quoth? Can this be done? For example making a forcefield should be a simple case of setting a targetname and adding wait -1 but wait appears to be used for how often the damage ticks.

I am struggling to find the appropriate way to do this. 

give the trigger_hurt a targetname, then setup a trigger_once or trigger_multiple whatever with killtarget set to the trigger_hurt. Can even be set on monsters and only works once, you can�t reactivate it from there i think. 

Helps a lot! 

Alternatively, the func_togglewall you're probably using for the physical part of the forcefield can be made to damage players that touch it with the "dmg" key. Saves an entity or two and a bit easier to set up - it's also the best way to do it if the forcefield can ever turn back on, as killtarget will remove the damage irreversibly.

http://tomeofpreach.wordpress.com/quoth/tutorial/func_togglewall/ 

I can't seem to get togglewall working to be honest. The brush doesnt appear in the game. 

thats intended. Spawnflag 1 + once triggered makes it appear. You can trigger it near the playerstart, when its out of sight, to make it appear. Everything iirc. 

I stumbled across a tutorial using the source engine and Hammer, the topic was optimization. He kept talking about visleafs and func_detail... which started to make me paranoid.

Some time ago I released a small part of a map in its early stages on QuakeOne. Of the complaints, the one that really disturbed me concerned high r_speeds.

I've been going through the map, merging wherever possible, mitering convex corners, making new textures in places where I had originally used several brushes to do the same job, using func_walls where appropriate, etc, etc.

However, my ignorance of the way quake works is allowing my mind to wonder and assume the worst.

When running around with wireframe I see some (sometimes rather large) areas being drawn even though there is absolutely no way it could be visible.

In some ports (DirectQ) some doors/illusionary disappear at certain angles. I'm not sure if this is because I'm doing something wrong, or if it's just quake/DQ. I don't get any errors when compiling.

Here is the lates bsp log (TxQBSP), does anything look odd? Like some number being too big or small in relation to another? This is my only map so I have no point of reference.

http://www.killpixel.com/kpcn/bsplog.jpg

Now that I think about it, a vis log probably would have been helpful...

Any insight would be appreciated, I just want to correct anything I'm doing poorly/completely wrong. 

Logs aren't very helpful in this respect. The best data you've got is r_showtris 1 in engine.

First off, are you doing fullvis? Thats a requirement for properly vis blocking your level. The -fast option should only be used for testing, and to be honest if you're using hint brushes properly then you won't even need the -fast option any more.

I've seen some great tutorials on this down the years, but can't seem to find many good quake specific ones now due to the various websites closing.

Here's a short one which gives you the overview:

http://www.quake-1.com/wc16a-tutorial/speed.html

But from what you've posted it might be the exact same one.

This is a programmer's guide to the format;

ftp://ftp.sgi.com/other/bspfaq/faq/bspfaq.html

And here's a non-quake visual discussion;

http://jheriko-rtw.blogspot.com/2010/04/visibility-testing-and-bsp-trees.html

Basically, there's tricks used playing off certain factors of the Quake engine and BSP format.

- vis does not respect vertical height (if its open at any point vertically it's considered completely open)
- switchbacks help, multi-tiered arenas hurt
- Doughnut corridors (a pillar in a corridor that is wider than the entrance / exit of the corridor
- ALL decorative stuff can and should be hint brushes, the bare bones structure being solid brushwork (this includes pillars, free standing or part of the walls)

There's a lot to add to this of course. 

"- vis does not respect vertical height (if its open at any point vertically it's considered completely open)"

Isn't this just a more confusing way of saying "it's using portals"? Meaning, if you can see the portal, then you can see everything that portal can see. 

Yes, fullvis.

Thanks for the literature.

Quake1 uses hint brushes?

https://developer.valvesoftware.com/wiki/Hint_brush

IIRC r_speeds on my system are fine.

Makes me wonder how many people are still using a 386 to play these maps...

I should probably use func_wall more often, 99% of the decorative stuff is made of normal brushes. 

"ALL decorative stuff can and should be hint brushes"

No. Hint brushes are meant for manually influencing the vis portal generation. Their implementation in Quake is experimental at best and there hasn't been conclusive testing, yet.

If you meant detail brushes, then no again. These are mainly for speeding up the VIS process, but do not have optimizing effects on the polycount.

If you meant decorative stuff should be func_wall or the like - this isn't a general solution, either. It's situational and may as well increase the polycount or have other negative side effects. 

That cleared several things up for me.

I don't use func_detail as I'm not sure how it's different than func_wall. AFAIK func_detail is only supported by specific compilers?

Also, I've restrained from making all the decor func_wall because of the polycount. So far, I've used this very sparingly. 

Instead of func_wall, func_detail creates so called tjunctions in your bsp, which prevent the flickering edges. Iirc.