the way Quake does it is for performance reasons - back in 1996 it was a big deal to make collision as cheap as possible so reducing all entity/world tests to point tests was desirable.

Of course, expanding the bsp tree on the fly was too expensive so they settled on using just 3 pre-baked versions of the tree, with the tradeoff that you only get 3 sizes of entity wrt the world. 

That concept sounds like a wicked hack... and it makes sense too. If he did indeed do that then its rather amazing.

Its nice to have some quakeC coder brains to pick and ask all these questions. 

I thought the 3 hulls were point , player and shambler. Anhyow, why could not the hull limit versus world/ bsp map entity be overcome by using code like this:

(This was originally Lord Havocs Idea)

float (vector loc, entity subj) Inbounds =
{
if (loc_x <= subj.absmin_x
|| loc_y <= subj.absmin_y
|| loc_z <= subj.absmin_z
|| loc_x >= subj.absmax_x
|| loc_y >= subj.absmax_y
|| loc_z >= subj.absmax_z)
return (0);
else
return (1);

};

Where subj would be the world entity, and the loc would be a spot on the hitbox. I believe you could use the ents absmin or absmax as loc and still get it to work, or to be sure, run it on the other 2 corners of the hitbox as well.

Theres also the stock ID function EntitiesTouching ()

Which is for the doors, and since they are models with their origins hard coded, with respect to world, they use mins / maxs, however I have modified it so you can check absmax and absmin, pretty easily by defining an operating mode:

float (float mode, entity e1, entity e2) EntitiesTouching =
{
// Cobalt mode float - modifies to cover absmin/absmax, else do normal mins/maxs

local vector low1, high1, low2, high2;

low1 = e1.mins;
high1 = e1.maxs;
low2 = e2.mins;
high2 = e2.maxs;

if (mode)
{
low1 = e1.absmin;
high1 = e1.absmax;
low2 = e2.absmin;
high2 = e2.absmax;

}


if (low1_x > high2_x)
return FALSE;

if (low1_y > high2_y)
return FALSE;

if (low1_z > high2_z)
return FALSE;

if (high1_x < e2.mins_x)
return FALSE;

if (high1_y < e2.mins_y)
return FALSE;

if (high1_z < e2.mins_z)
return FALSE;

return TRUE;
}; 

Darkplaces allows this: mod_q1bsp_polygoncollisions 1

But it is a bit buggy, the player can get stuck sometimes on any vertical surface such as walls. I was using it for a while for my Citadel mod to do crouching and prone and to size enemies better but it was just too unpredictable. Thats why I had to chamge it to use Unity, sadly. 

You could, I suppose, use point for your monster size, but it would look wierd whenever it ghosted halfway through walls. And of course there's the issue of you being able hit it with your point sized bullets. 

Thats why I had to chamge it to use Unity.

What do you mean by Unity? 

 

Any link to your project? 

Is Unity good enough as an engine to make a Q1-like that looks similar to UT99/the Half Life HD pack? 

yes 

I'm currently "preparing for"/designing a game inspired by Blade Runner with Quake-like graphics.

Most problematic is non skeletal animation and making game modable.
First problem you can solve with blendshape animation, or by writing your own animation system (just loading vertices states).
Second problem is more challenging... Easiest way is to let people create and script maps in Unity and export them as Asset Bundle, then load them in your game. This delivers few problems:
1) You have to open part of your source so people can use and modify logic - for example adding some functionality to existing door script;
2) C# Scripts must be compiled into assembly - not a big problem, but pain in the ass when you test stuff;
3) If you give people access to C#, you have no control what is executed in your game - I can create a map that will delete or acquire some important data from your hard drive.

But... few days ago I have discovered nice Lua integration for Unity and .Net in overall. It's opensource, easy to use etc.
So instead of C# we can use Lua scripts = much easier editing and testing, easier to avoid malware behavior.

For mapping you can use free version of Pro Builder: https://www.youtube.com/watch?v=0yB_Q7yECwk
So all your mod tools stay free.

Rest is piece of cake... 

As well as ragdolls in tandems with actual death animation for avoiding flat lifeless bodies hanging on ledges and whatnots (and also for doing high-impact on deaths a bit more convincing). Half Life did skeletal animations on low-poly models right and Metroid Prime did the animation/ragdoll tandem well, so it's possible.

It's also a relief modding is possible, it's one of the thing I was looking forward when developping my game.
And as long as that Pro-Builder has a grid and surface texturing I'm fine. 

That's a cool idea, but not how I do huge monsters.

I make 1 bmodel that becomes the clip brush for huge monsters, I basically pad the walls out with it.
Then at level start it is non-solid.
Everytime the huge monster moves, it sets it's bbox to shambler size, makes the clip model solid and then walks. 

Aha! So I was kinda imagining things :) Or, I half-remembered it and tried to fill in the blanks myself or something.

I guess the problem with the method I mentioned is that it could get messy when you have more than just the boss and the player moving around in the environment - you need a master/slave setup for every entity that the boss's movement needs to know about. 

http://www.indiedb.com/games/citadel 

Patrick Martin had a special trick for large BBOXs in his Drake mod and the Dragons patch.

http://www.quakewiki.net/quake-1/mods/dragons/

I love his code - so many interesting and creative monster improvements. 

Any way to disable this: warning: Model progs/clutter/bookclos.mdl was used but not precached
I'm using Preach's wrapper that magically fixes this problem, but now fteqcc yells at me for being clever. :( 

you mean other than this?
precache_model("progs/clutter/bookclos.mdl");

Note that you can also use this, for instance:
precache_model((self.mdl = "progs/clutter/bookclos.mdl"));
yup, assignments in function calls are evil, but it will do the right thing, and only need the mdl named once (you could also make some macro, eg preset_mdl).

And of course, if you just want to hit it with a sledgehammer instead of playing whackamole:
#pragma warning disable F210
note that doing so will of course hide any other instances (which may be more significant).
you can use this method to disable any warning that fteqcc gives a code for, but you run the risk of shooting yourself in the foot if you just disable everything, so use with caution. 

doesn't seem to work though? where do I put the #pragma line? I tried in defs.qc (the first file in progs.src) and also in one of the files where I get this warning, but neither had any effect. I also tried #pragma warning off F210 from here: http://fte.triptohell.info/wiki/index.php?title=Precompiler_definitions&action=edit

btw, preach's trick is thus:
void(entity e, string m) setmodel_builtin = #3;
//preach's wrapper function for setmodel!
void(entity e, string m) setmodel =
{
if(framecount == 0)
{
if(m != "")
precache_model(m);
}
setmodel_builtin(e, m);
};

which neatly stops you from ever having the problem! 

that mod folder had an ancient copy of fteqcc. :P
all good now, I think.. thanks! 

oh... btw, warning F304: unary-not applies to non-unary expression
I liked the warning in the old version where it just told you warning: You may wish to add brackets after that ! operator. 

seems that warning only got a code in revision in july, hence why its not present in the warning message you gave.
you'll need to update your copy of fteqcc if you want to blanket-disable that warning.
alternatively, because the warning is generated regardless of whether setmodel is a builtin or a qc wrapper, you can just do:
#define setmodel setmodel_spanishinquisition
#define precache_model precache_model_omgninja
before your builtin/wrapper definitions.

of course, that hack won't stop you from ever having the problem, and implies that you'll be lazy and forget the cases where it won't work as expected - ie: outside of initial spawn functions.
even fte+dp will display a warning if you setmodel without precaching first, despite them both supporting precaches any time (there may be some edge cases in dp regarding bsp models, iiuc).
either way, triggering auto-downloads mid-map is bad. hurrah for PREcaching. 

regarding unary-not, !a&b always looked wrong to me, as a C programmer. The brackets don't change anything, but they do clarify things for people more familiar with C operator precendence. :P 

of course, that hack won't stop you from ever having the problem, and implies that you'll be lazy and forget the cases where it won't work as expected - ie: outside of initial spawn functions.

If you've forgotten to precache a model you need, you're screwed either way. What it does is threefold:

1) Allows for external model files in e.g. func_wall (and since you can't know from the QC if the model will be "*10" or "progs/cog_lrg1.bsp", precaching everything that comes through just in case is the only safe way).

2) Permits you to reuse a spawn function which you've already called at the start of the map to create a fresh instance of e.g. a monster mid-game. This is a Don't Repeat Yourself principle thing.

3) Makes spawn function code a little bit shorter and tidier

The part 3 on the end there is more of a bonus, not the point of the code. 

thanks, spike! just picked up the most recent version (feb 11 2016)!