You mean like a kind of gill-man or creature from the black lagoon?

http://img05.deviantart.net/4982/i/2013/187/9/9/gillman_profiles_by_dominicqwek-d6cbgdx.jpg

http://images-cdn.moviepilot.com/image/upload/c_fill,h_812,w_609/t_mp_quality/creature-from-the-black-lagoon-remake-the-creature-from-the-black-lagoon-remake-jpeg-96956.jpg 

A fiend with a fish tail would be cool. It could swipe at you from the water, then jump out when you back away and behave like a normal fiend on land. Then when he falls back in the water he could swim. Make him tougher than normal fiends, color him different and put gills on his skin, and make a good environment sort of like e4m1 with lots of water (but of course medieval). I like it. :). Could also do a variant that does the TEelzap if you get too close in the water. 

I tried once with Harpio, a kind of waterdragon.
Hard to get the coding right, as I needed two kinds of attacks, on land and in water. In the end it was easier to get them in water then back out again.

view 

i wonder if you'd need something like trigger_monsterjump to get the guy to come out of / go into the water. 

you could use a version of the player get out of water code. 

It is something in the qc code.

I made a land type(harpo) and a water type(harpi)that change with a void() harpo_to_harpi; and a void() harpi_to_harpo;.

The land to water function goes right:
void() h_jive1 =[ $djive1, h_jive2 ] {harpi_to_harpo();};
but for some reason the other one doesn't return the call:
void() h_mour1 =[ $mour1, h_mour2 ] {harpo_to_harpi();};.

Maybe a monster_jump would help but I think it will stay swimming on dry ground.

I looked at the water code and how the positions are defined, but I couldn't get a rig on it. 

Tried the code Preach and I collaborated on a little, seems to be working, heres a screenshot.
http://i.imgur.com/T8feCWg.jpg

I guess a skull or head model has a low chance of sticking in a wall before it breaks up, so will have to code in that case.

Im using DP so I was able to assign the gibs a bloodtrail modelflag, even though these dont have any. The blood dont last very long but I suppose thats the engine setting kicking in.

Would be neater if they had a flattened area contacting the wall , so that it might look more realistic. I suppose maybe what could be done is the model have more scenes made into it that flatten it different percents and at some random angles....then we align it to the wall with that angle...? 

that looks worse than it sounded like it would. :(
at least don't make skulls stick, that's silly. and you need to put blood decals or something to make it blend into the wall more or something. 

The water dragon / fiend with tail indeed is the type of thing. I find water so empty in the game when it comes to enemies. But then again your ability to stay under water is vague and short on time. Still I like the idea of some more things to worry about besides rotfish and air when traversing the depths of quakes rusty waters. 

The expansion had electric eels. Scrags look OK underwater. Zombies don't need to breathe ;) 

spawns... at least underwater you won't get quite so annoyed at them.

if you're jumping out of water, you need to move at least far enough to get your monster's bbox to leave the water and then progress past any ledge above the water surface too. and after all of this, it then needs to also go forwards if it somehow managed to avoid impacting the wall and losing its sideways momentum...
which is why the quake player keeps trying to move forwards while waterjumping, regardless of what the player wants or really anything else. the player must a: be next to the side. b: far enough up that a tracebox can go up, leave the water, move sideways slightly, then move down again and hit ground that is actually viable (ie: somewhat flat). c: then the upwards velocity is set, a teleport_time flag is set, the player looses control of their sideways velocity. d: that upwards velocity takes the player out of the water, the forced sideways velocity that ignores walls takes the player sideways once he's far enough out of the water, and when the player gets control of their velocity again then they've successfully left the water.

because, quite frankly, teleporting out of the water is stupid.

if its a monster, be careful about FL_PARTIALGROUND, if your monster didn't get fully onto land, the monster will be able to casually walk over the ledge and fall straight back into the water.

the problem with just casually hopping out of the water like the player does it is that it lacks presence or menace, its just another monster to kill. you might as well just teleport them in if you don't have that.
some sound effects or cool animations might do the job.
slowing the transition down so the player gets a chance to panic at 10 of them getting out of the water while he's got no ammo. that's the way to do it.

alternatively you could have fish that move fairly fast and spit, which means they'll keep sniping the player while being impossible to see/shoot thanks to the opaque water surface.
the player then has the option of either trying to ignore/dodge said spit/whatever, or jump in and get eaten by the fishies. 

There is def a lack of them, the Eels in Rogue were neat. As for spawns, you could put them inside a secret door of sorts that they exit out of, on the walls or the floor, or a tunnel that leads inside the wall to their home.

I always thought movetype_fly was better for swimming monsters...simulates no gravity. flymissile will make em bounce off the wall for more accurate physics with the right velocity calcs. Just have to make sure you dont break the surface and are in empty air. Air pockets could pose a challenge tho... 

because a spawn that is really thin and wide on the ceiling, and then drips down into a blob on the ground would be cool. 

No...all monsters are one of two sizes. 32x32x56 or 64x64x88. If you assign a size other than these the engine will round it to the nearest size. This is because of the way the engine handles collisions. Every level has a hull0 and a hull1 for the two sizes above. When a level gets compiled the compiler creates 3 versions of the map geometry, one for what you see and shoot, one for what you and other hull0 sized creatures collide with, and 1 for larger monsters. The hulls are all shrunk in from the walls by half the width of the bounding box so that collision only happens as if every solid object were only a point.

You can, though, make it visually different sized, but the collisions will stay the same. 

The size with respect to the level collision can be of 3 values; the two mentioned by Qmaster, or point size.

However, for the purposes of entity/entity collision, the bbox will use its actual size, not the hull-rounded size. 

ok that is a rather gimped limitation wow. no way to hack around that I guess without changing the engine itself?

How the heck do you do large boss monsters then? 

e.g Have a main model (the legs) and have a secondary model "attached" to it (the upper body) 

I may be imagining things, but a very clever solution was used by necros in Altar of Storms (necros please correct me if I'm wrong) that went something like this:

1) have a fuckoff huge monster in big arena-like environment

2) build a dummy small version of the arena environment somewhere player can't reach. In this small environment there's a normal-size version of the big monster (let's say it's shambler-hull-sized) The size of this small environment relative to the shambler hull should be in proportion to the size of the big environment relative to the intended big monster size.

3) The small monster moves around the small dummy environment fighting a dummy player entity (whose position is updated based on the real player's position. Similarly, the big monster in the real environment gets its position set based on what the small monster is doing.

Hope that makes sense. The concept is simple really, it's just about setting up master/slave entities at different scales to each other. 

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?