A Quake C Exercise [EDIT]

Posted by Teknoskillz [73.142.34.180] on 2016/02/07 22:38:53
We seem to have alot of good QC coders here, so wanted to see if any are up to collaborating on a new modification for the gibs, where (and heres where its kinda gross :o) ) we give the gibs a .touch field and check for an impact against a solid where we look for vlen (self.velocity) > a certain value, and if its moving very fast and hits say the bsp, we do 1 of 3 things:

1) Make it stick partially in the wall or the ceiling. (sort of like the nails stick in walls mod)

(I believe I have played a Doom mod out there that does this)

2) Same as 1, but make it slide down and or maybe fall off the wall with a seperate think.

3) Create a "splat" effect , either using a new sprite which is sorta a flattened image of the original gib, or perhaps use a decal?

I have no knowledge of decals, not really sure if its possible to use QC for that, as it may be an engine only effect. 

1) Make it stick partially in the wall or the ceiling. (sort of like the nails stick in walls mod)

This is easy. Make this the .touch function of a gib

void() gib_touch =
{
��if(vlen(self.velocity) > 300 && other = world)
��{
����self.velocity = '0 0 0';
����self.movetype = MOVETYPE_NONE;
����self.avelocity = '0 0 0'
��}
}

2) Same as 1, but make it slide down and or maybe fall off the wall with a seperate think.

This will be a bit harder, and I don't think the request is fully specified yet. For example, what happens if the gib hits a ceiling? How about angled surfaces? Sloped up or down?

Regardless of the answers to these questions, there are some concerns which always apply. There's no simple way of determining the facing of the surface we collided with. We could try and traceline backwards but this may be inaccurate in corners. There's also a bug with MOVETYPE_BOUNCE entities moving down slopes just get stuck.

However, in the simple case where we have determined that we've hit a proper wall, one which is not sloped but perfectly vertical, you could probably simulate sliding down the wall quite well by setting self.velocity = '0 0 0' and self.gravity = 0.4.

3) Create a "splat" effect , either using a new sprite which is sorta a flattened image of the original gib, or perhaps use a decal?

Gonna pass on this, there's no actual decal support in normal engines, and there are loads of pitfalls in using sprites. 

if(vlen(self.velocity) > 300 && other = world)

^_^; 

One day I decided to peek at trace_plane_normal while in a touch field..and like I thought, it was returning the correct value corresponding to the type of plane it hit, with respect to world. I was using DP of course, but according to Lord Havocs response, it seems like all the other engines would replicate this. Of course give it a try and see.

So if that turns out to be true, then could we not use this to determine the angle we need to align the gib? Im guessing it only makes sense to do this if its a perfectly straight wall or ceiling, but I suppose we could do sloping cielings without a problem. Sloping floors not so important, as that would boil down to more of a rolling effect.

Yes vlen > 300 and touching world is a start. However I might reinforce that code to also cover non world ents which also have a bsp solid, such as exploboxes, doors and I suppose plats that are doors...and I guess buttons. 

http://collabedit.com/phw6e

Neat site I think will let us collaborate code.
Would vectoangles of the normal set the angles on the gib correctly? 

As necros kinda pointed out, that should read

if(vlen(self.velocity) > 300 && other == world)

You don't want to use things other than the world, because those things might move. This code doesn't attach the gib to a moving object, it just stops it from moving. You might end up with a gib suspended in the air. 

True, however I suppose we could look for that case where its already a movetype 0, and is contacting a bsp != world...or like I have seen in some other code in my travels, somoene had marked the origin it stuck to and used setorigin I believe in the doors think to find it. Maybe more complex, but for now I guess we can think about it for later. 

So what compiler to use if I want to start wandering into Quake coding?

FrikQCC 2.0 I read was one of the later versions correct? Other than reading all 2000 posts in this thread which will be a good start I guess.. any more focused coding site for quake? :)

Thanks in advance! 

if you're on windows, fteqccgui.
tell it to debug with fteqw and you get breakpoints and other nice debugging stuff.

http://triptohell.info/moodles/win32/fteqccgui.exe
place in your quake directory and set up a file association for .src files so you can easily start/update it etc. making lots and lots of copies also works, but yuck.

imho frikqcc is kinda obsolete now, but there are still people using it, it was good for its time.

if you prefer commandlines/alternatives, there's also (non-gui) fteqcc, gmqcc, or qfcc.
gmqcc is used by xonotic, whereas qfcc is kinda dead and unused.


the bigger issue is which mod you use as a base. that mod may depend upon specific features of the qcc it was written for.

if you're targetting either fteqw or dp, these engines have their own FOOextensions.qc files so that you can quickly get started with their various extensions. note that the inclusion of either of these extension def files does not automatically rule out compatibility with other engines, but you may still find you end up using extensions without realising it, resulting in issues with engines that don't support them. 

Also has support for arrays and other cool stuff that isn't available in standard qcc compilers. I used proqcc.exe for a while, but FTE is the best. It even gives you a warning if you have added variables up too high in your defs.qc file. You can double click errors to open the file right at the error line. It's great. 

Is this possible? A monster that can swim and lurk in the water but also jump out and follow you on land if you get too close? I would love a big sort of lurker type water monster that stays near the surface and mainly attacks from the water or under water when you are spotted underneath but if you are on the shore it could jump out and maul you / run after you. I find Quake's water to be very empty except for the rot fish :P 

some logic to detect if enemy is on land and jump out if close to surface, and then just take off the swim flag, should do it

Jumping in would be similar.

Obviously the devil will be in the details 

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.