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 :) 

How to avoid trigger_relay to emit a sound ? I have 4 choices in QuArK (i.e 0: none, 1: secret, 2:beep beep, 3: large switch). I selected the "none" option, but I still have a "beep beep" like sound ingame... Is it the normal behaviour, or am I missing something ? 

Don't put anything in the "message" field. Right? 

But 0 should work - different editor. Maybe try editing the .map direct with notepad.

Another question, similar;

How do I stop a door_secret playing its touch sound after it's opened? Using in the case of ones that remain open.

If all else fails I can just embed it in a wall recess or clip brushes. 

I checked the .map file, and the sound filed is set to "0"... pretty weird.. any idea where it could come from ? 

 

Yes, it has a message field... is it the cause of the "issue" ? 

Oh, and one of them doesn't have, but the beep beep sound is here BTW 

when they have a message field, unless it's completely empty ("" no space).
If yours also beep without, check the trigger/button firing them. 

OK, I have a single trigger_realy that causes the issue: it is generating a beep while triggering a sound, and it is not really the effect I wanted... I have this one to check particularly: thanks for the info ;)

BTW, as I already launched a fullvis run, is it possible to hack the BSP to remove the message field, or is it mandatory that I recompile all the stuff from scratch in order to obtain the wanted effect ? 

Set the trigger's sound field to an invalid value then, like 4.

You can easily recompile the map with -onlyents if you only edited entity flags. Remember to run light -onlyents too if there are switchable light styles in the map. 

I'll try it... and even if it doesn't "work" as I want, I can launch again my fullvis, as it was running only since 12 hours... so not a big waste of time...
Anyway, thanks ! 

Sorry for flogging a dead horse:
Would it be too much work to add support for detail brushes to Qbsp? After all, it has been done before by Alexander Malmberg - the source code is available too http://quest-ed.sourceforge.net/files/mapc/qutils_2_src.zip
Are there obvious reasons why this would be unfavorable, technical issues or the like?

Func'ing architecture does work, but it has disadvantages too. Detail brushes (not splitting geometry) might be better in certain situations. 

those versions, they're introducing new file formats (e.g. map and prt) and AFAIK require modifications of all tools (possibly engines too).

I don't like messing with the original formats; I want to keep the stuff open-ended so you always can use whatever step that works best for you.

There are already "Q1" maps/mods that require specific tools and/or engines to work.