I knew modding with the Q1.qc can lead to a story without end. After changing the one line, others seem to jump up.
I had to change the fight.qc also and of course now other unknown punctuations appear.

I didn't change CastLightning in the monster.qc and changing it to CastNewLightning seems to help. Now it comes to a broad stroke, only the behaviour of the

function Monster_JumpTouch was not defined

breaks up again.
So I'm plotting further again.

Thanks for your advice, lurker! 

What the problem is:

The compiler will only let you call functions that it already knows about, functions that you've already written earlier on in the code. If you want to call a function which you haven't defined yet, then you must do something called prototyping. A prototype is where you just tell the compiler the name of the function, warning it in advance that you are going to define it.

What to do:

The error you're getting tells you that you need to create a prototype of the function Monster_JumpTouch. The prototype looks like this:

void() Monster_JumpTouch;

Add that line at the top of your qc file(or anywhere above where you first use the function) and the error should go away. 

thanks for your attention, preach.

to keep it simple, the monster.qc is identic to the demon.qc , except the lightning beam addition.
This means, as in the demon.qc it starts with the

void()Monster_JumpTouch;

statement, and further on in the jump function

ai_face();

self.touch = Monster_JumpTouch;
makevectors (self.angles);
self.origin_z = self.origin_z + 1;
self.velocity = v_forward * 600 + '0 0 250';
if (self.flags & FL_ONGROUND)
self.flags = self.flags - FL_ONGROUND;

so I can't find the reason why the compiler bumps. 

That bit looks in order, so the problem might be elsewhere. Check that Monster_JumpTouch isn't defined in both monster.qc and demon.qc, even though the error message doesn't sound quite right. Also, what are you using for compiling? If you use something recent like FTEQCC(http://www.fteqw.com/) then you get more informative error messages, as well as warnings that can help you pinpoint errors. 

thanks for the link, preach! Suddenly I've got a progs.dat Only the messages run so fast I have to turn back to dos to watch them. I'm testing now how far things run.

I have two different prototyping for them, so I used Demon_JumpTouch and Monster_JumpTouch.
But as I copied them, their statements are the same.

I use the old proqcc and fastqcc as compilers.
They give a clear overvieuw of what's going on, but tend grimm for giving a progs.dat when errors appear. 

There is a GUI version which allows you to read the output of the compiler in a window, and gives you a full windows interface for selecting optimisations etc. You can nab it from http://downloads.sourceforge.net/fteqw/fteqccgui2770-win32.zip?modtime=1153182266&big_mirror=0 

That's better. Although now I get 81 warnings from all kind of errors I suppose I don't have to take need of.

Now I'm so far I have two monsters, the demon and the gnerk seperated in one level. I had a rude job to model the head of the thing, because one can't just cut them off from the base part in Qmle.

The strange error occurs that the gnerk stands alright, but at leap moment it freezes for 3 seconds and then starts jumping again. Also the ligtning beam doesn't appear, although it doesn't give a message error.
For your convienent I have the two altered qc files from the fresh Q1.qc downloadable.
Maybe you could be so kind to take a look at them. I can't think of a line that's wrong.
The Gnerk_JumpTouch keeps bumping.

http://members.home.nl/gimli/gnerk.qc
http://members.home.nl/gimli/FIGHT.QC 

Don't worry too much about the warnings, they are in fact mostly from the original ID code, only two from your own code, and 1 of them is harmless. The other one tells us what the problem is:

gnerk.qc:52: warning: function Gnerk_JumpTouch was not defined

You may be thinking that you did define such a function, a copy of the Demon_JumpTouch function. However, you renamed it Demon_GnerkTouch rather than Gnerk_JumpTouch. Fix that and your monster should work, somewhat. It won't freeze up when jumping in any case.

The problem you'll next encounter is that your monster isn't ever going to use lightning. This is a much knottier problem, discussed in the next post. 

Preach the lurker map of vertical event crash in the 2 new progs.dat in old quoth works nicely 

Trinca/Preach: My map was pushing precache limits in id progs and Quoth progs due to func_illusionary (and func_wall?) abuse. It originally crashed Quoth but worked in id progs due to a couple of extra Quoth precaches. If more were added since the official Quoth release, that would do it.

I'm not sure it's a big deal, however, since the map uses no Quoth features and works with id progs.dat . 

I'm still looking to much to the outcome of fastqcc. If i see errors I want to devoid them.

I had overcome the freezing of the gnerk by changing line 110:

void() gnerk_jump10 =[ $leap10, gnerk_jump1] {

self.nextthink = time + 3;
// if three seconds pass, assume gnerk is stuck and jump again
};

into

void() gnerk_jump10 =[ $leap10, gnerk_jump11] {

//self.nextthink = time + 3;
// if three seconds pass, assume gnerk is stuck and jump again
};

so by changing the gnerk_jump1 to gnerk_jump11 and adding two slashes for the self.think the error faded.

I now tried your way by changing Gnerk_JumpTouch into Demon_GnerkTouch, which also works. But it still gives that nasty error in fastqcc. I don't mind, but as I worked on the NewBoss earlier I found myself only content by getting a clean outcome.

And yes, why doesn't it struck its beam?
Seems that Shambler doesn't give pass to his magic laserbeam so easily! 

I lost a really long, nicely formatted post about the various systems that govern ai decisions, then the computer crashed. Here we go again:

It's quite hard to follow how the various functions that govern the decisions the monsters make. The functions involved for any given monster are spread out over 3 qc files, so here's a summary of how a monster goes from running to attacking. It starts in the running animation frame functions, which call ai_run().

ai_run(float dist) (ai.qc)
The first thing this function does is check if the current enemy is dead, and find another target if so. Once satisfied with the enemy, the function checks self.attack_state. If it is set to AS_MISSILE the function runs ai_run_missile, and if it is AI_MELEE it runs ai_run_melee. Otherwise the function runs CheckAnyAttack to see if the monster should attack yet, and if that returns false the monster runs forward the distance specified by dist.

CheckAnyAttack() (ai.qc)
This function asks the question "is this a good moment for the monster to start attacking the player?". If it is not then the function returns FALSE. If it is, then the function returns TRUE, but also starts off the attack sequence, in a way that varies from monster to monster. If you look at the function you will find lots of lines like:

if (self.classname == "monster_shambler")
return ShamCheckAttack ();

So it's actually another function that determines whether an attack occurs. If a monster is not on this list then it uses CheckAttack to decide.

CheckAttack (fight.qc)
This generic function checks if the player is in line of sight, and then if they are in melee range executes self.th_melee. If the monster does not melee attack, then there is a chance it will enact a missile attack from self.th_missile. The exact probability of an attack depends on the range. Otherwise the function returns FALSE, so the monster will go all the way back to ai_run and run forwards.

ShamCheckAttack() (fight.qc)
It's interesting to note that ShamCheckAttack has a slightly different approach to CheckAttack. Although the decision process of whether to attack or not is similar, if it decides to missile attack, it just sets self.attack_state = AS_MISSILE. Then the next time the monster runs ai_run(probably the time of it's nextthink), it will run ai_run_missile.

ai_run_missile() (ai.qc)
This calls self.th_missile only if the monster is facing the player, making it slightly different to the CheckAttack method.


So at the moment the Gnerk is using CheckAttack, and so leaps at the player before it is facing the right way(DemonCheckAttack uses the AS_MISSILE method). The first thing to change would be to add a line
if (self.classname == "monster_gnerk")
return GnerkCheckAttack ();

to the function CheckAnyAttack. That way you use the GnerkCheckAttack function you added. You have to prototype it before CheckAnyAttack.

There are a number of ways you could add the lightning attack. One would be to add lines like

chance = random();
if(chance < 0.1)
{
gnerk_magic1();
return TRUE;
}

just after the lines

if (enemy_range == RANGE_FAR)
return FALSE;

of GnerkCheckAttack. This directly calls the attack. The problem is that it misses out on the AS_MISSILE bit, so the gnerk will attack before it's facing the player. Another way to do it would be to set

self.th_missile = Gnerk_ChooseAttack;

in the monsters spawn function. Then write a function Gnerk_ChooseAttack which randomly selects either gnerk_jump1() or gnerk_magic1(). You could even make it select the attack based on effectiveness, but that would be contrary to the tradition and style of Quake... 

My god, Preach, if I had the knowledge you had I probably made my own Quake mod of Hellboy. I'm only joking of course, although the idea won't leave me alone. But this little creature took already 825 verticemeshes of my time, so.. let's get on with it.

First let me thank you for your thouroughly explination of the source code. I'm beginning to understand it has more to do with comparisions than with logical copying. And me maths are a wreckage, but right.

I'm glad someone took the time to make an odd fool like me to understand how things work and I'm really gratefull for that. This qc can't stand a wrong aphostrophe and that hurts.
I hope it wasn't my code that crashed your computer.

As far I can understand I tried your first attempt on the GnerkCheck Attack, and I hope it was in the fight.qc and not in the ia.qc(?)
Changing the line gave me a few errors as the compiler doesn't want the gnerk_magic1. I have reposted the fight.qc so you can see.

It has gone deep in the night as I rearranged new gnerk sounds from the hellboy dvd, and my nerves started rumbling the same.
But the change from Gnerk_jumpTouch to Demon_GnerkTouch was a good hint! So far things run great, even in fastqcc. Hope my language also... 

You also need to prototype gnerk_magic1 before you use it in GnerkCheckAttack. Once you do that it should work fine. The usual thing to do when you get that error is check whether the function is defined before or after in the code. If it's defined after then you need to prototype(or move the order of the functions around, but not a good idea when they start in different files). If it's supposed to be defined before, then check for a typo - remember function names are case sensitive too! 

Good Old Quake has got an new monster coming!!!
Tricerops Tribolites combines demonfiend attack with shammy's lightning bold.

Fox must have been mad to make this attempt, but succeeded and becomes madfox again! 

So my problem is HexenII related, but I thought that is a general problem too.
The first is that I need years to vis my map (several hours on my celeron 700)
The next thing is that the water is not vised. Usually it is vised on default. (=now it looks like quake1 with r_novis 0 and r_wateralpha <0)
So I checked the log-files of the compiling tools and have only one error in the bsp.log: "r_cutnode new portal was clipped away"
Does anybody How do I fix that? 

I know nothing about, but if:

- it was a Q1 map
- fullvis was slow
- by "not vised" water you mean transparent

then I'd say thet you've a leak that the compiler isn't telling you about, a very common error in old build tools.

If the map format is reasonably similar to Q1, you might be able to try one of my qbsps, just to see if it finds a leak.

Otherwise it's probably time to pull out the old leak hunting tricks, e.g. put big solid blocks over parts of the map and rebuild until you've nailed the leak. 

I guess the hexen bsp-format is very similar to quake1
I will try it 

TreeQBSP v2.04 -- Modified by Bengt Jardrup

Input file: ./maps/mymap127.map
Output file: ./maps/mymap127.bsp
---- LoadMapFile ----
*** ERROR 03: Line 17: Invalid brush plane format

Elapsed time : 0:00

Peak memory used : 1.4 MB

!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!
Build failed, because it did not create the (+BSP) file: C:\appl\spiele\hexenII\
UhexenII\tmpQuArK\.\maps\mymap127.BSP
Build failed, because it did not create the (+PRT) file: C:\appl\spiele\hexenII\
UhexenII\tmpQuArK\.\maps\mymap127.PRT 

my qbsps can't read the format, you may be able to export the map from the editor (e.g. QuArK) to Q1 format and then rebuild.

Or if you can find more recent tools that can build HexenII bsps, maybe they'll work better.

You can also verify that your map leaks by noclipping outside, if you can see the textured outside of the map, it leaks in hull 0. 

indicates that the brush face format is incompatible with Q1. Since I see you're using QuArK, try exporting the map to Q1 format if possible.

If you can't proceed, send me the zipped map and I'll see if I can figure out what's going on. I don't have HexenII though, so I can't check it out in-game, but I've QuArK. 

I can't see the textures outside the map.

Maybe it has something to do with:

a) It's a big outdoor map
b) It's the map I started mapping so almost everything is off grid 

Its the grid; It's a bastard to fix as well because the errors can be all over the place.

I'd advise adopting a preferred grid size in future for all walls / floors and sticking to it, only going smaller for details or different mapping techniques - curves, terrain etc.

I don't know QuArK much but I'm assuming theres a vertex manipulator - that'll allow you to snap everything to grid, although it'll be a gruelling task.

Another option would be to cut out a piece of the map and copy paste it into a new file, correct it and make sure its not leaking and then c+p the next section until you've got all the important features. Fairly primitive way of doing it but you'll be sure to have a very clean mapfile. 

the mymap127.prt file, again if it's similar to Q1 then there are two numbers on the first two lines of the file. The first is #leafs and the 2nd is #portals.

If they're high (>10000), then you've probably too much solid detail and need to simplify or turn into func_walls or similar.

Having a messy outdoor map is a good start to a major vis headache ... 

tidy up the mess end compile it later and also with other tools. Apart from the off grid there are a lot of microbrushes too
(There is a lt of work to do)
I might ask later if that does not fix the problem

Thanks a lot for advice :)