http://user.tninet.se/~xir870k/tooltips.txt
http://user.tninet.se/~xir870k/readmegl.txt

Hint: Search for "clipnode" ...

Clipnodes are only generated in hulls 1/2 (the clipping hulls), since they specify what entities "clip" (i.e. collide) against.

If you have a leak in either of these hulls or order qbsp not to fill them, the clipnodes will increase a lot.

I don't think illusionaries generate clipnodes as nothing collide against them, but all normal brush entities do. 

but the compilers don't know how the func_illusionary is going to be used; it doesn't know anything about the quakec code. So it should be treated the same as any other brushmodel. 

I think I do know what a clipnode is. I've probably got so many because of my rock-work. And archways. Maybe I can block some parts off or something...

I might just tune my map so it hugs the limit. Its not at the limit yet. 

I always assumed illusionaries didn't add to clipnodes, so the infamous spiky pit automatically became one (the spikes).

If this is wrong then does it mean that a door creates clipnodes from its starting position, even though it will move? I'm thinking of multi-part doors that could potentially produce alot of nodes. Also func-trains - only their starting position? 

I think brush models are their own BSP trees inside the the master one, aren't they? In that case they would have their own set of clipnodes inside of them, independent of the rest of the level. 

Does anyone know how to get the SVC_FINALE message to accept more than one string at a time? I changed the signature for centerprint and others to accept multiple strings like this:

void(entity client, string s, ...) centerprint = #73;

However, that doesn't seem to work for the WriteString function. I want to customize the text that gets displayed at the end of a game of Qonquer but I don't see how to do it. It only ever displays the first string when I do this sort of thing:

WriteByte (MSG_ALL, SVC_FINALE);
WriteString (MSG_ALL, "[qonquer]\n\nfinal stats:\n", "blargh" );

Or:

WriteByte (MSG_ALL, SVC_FINALE);
WriteString (MSG_ALL, "[qonquer]\n\nfinal stats:\n" );
WriteString (MSG_ALL, "blargh" );

The first example just plain doesn't work and the second example causes Quake to crash with an "illegible message" error or something.

Help? 

Sorry, I mean the first example displays the first string but not the second. It doesn't totally fail or anything like that. 

Just wanted to say thanks for the info.
I know I already said thanks, but I was pondering what has been explained and realized that I can probably reduce my clipnode count by changing some func_walls to func_illusionaries! I have some pipes and bars with 12 sided cylinders func_walls where they touch walls/floors. So in theory if I turn them into illusionaries than they wont clip. I will test this l8R!

PS sorry Willem that you might have thought I was Preach. I dont know how to program C. People who do seem very clever to me!! ;P

PPS while your hot, why not knock me up a blood splat progs? I'll love you for ever!!! Also sod Quoth2 if you do, Ill put my map out with standard Quake + blood splat progs!!!! 

Only some of the QC functions can be overloaded like that, it all depends on how they were coded in the engine. I did exactly the same thing yesterday as a test to see if it could be done. In the first example WriteString just ignores additional string parameters, so you only get the first one. In the second case, your first string is null terminated, so the game thinks the command is over. It then reads the first character of your next string as a byte, assuming that it will be the start of a new message type. Unfortunately, "b" = 98 as a byte, and there is no SVC message with that number, so it causes an error.

So what can you do? Well, if you're willing to do a lot of messing about then the way forward is to send each character of your message as a BYTE rather than as one big string. So for instance, to send a finale print saying "killed n" where n is replaced by the number of monsters killed, you would send the following bytes:
31 //the SVC_FINALE code
107,105,108,108,101,100,12 //the codes for the characters 'k' 'i' 'l' 'l' 'e' 'd', ' '
floor(n/100) + 48//the code for the hundreds digit - assuming the number is between 100 and 999
floor( {n - 100 * floor(n/100)} / 10) + 48//subtract off the 100 column and work out the index for the 10s digit.

I'll leave how to get the units column for you to figure out. I've uploaded a mod that will let you test out what numbers correspond to which characters:
http://people.pwf.cam.ac.uk/~ajd70/char.zip
Bind 9 to "impulse 9", 0 to "impulse 10" and p to "impulse 16". Then simply type a number between 1 and 254 to get that character.

Special characters worth knowing:
0: null terminates the string, ending that command
1: 'Chat message', makes text red and chat sound play
2: Sets red text without chat sound - possibly a toggle
10: New line character
48-57: digits 0 - 9
65-90: uppercase A-Z
97-122: lowercase a-z

On the other hand, you might feel this is a lot of effort to go just to make things work with the finale text. It'd probably be alright once you've got a function that automatically takes an input number and converts that to the stream of digits required. 

Oh dear god. I'll give that a try once I've worked up the emotional fortitude.

Thanks for the info, Preach! Informative as hell, as always. 

Is there a complete list of byte values and what they mean to Quake somewhere? If I had that, I might be able to work up a small utility program to save me tears in the future. 

Wouldn't it be easier to find/hack a compiler that has string concatenation in it? 

That's a good idea! I'm using FrikQCC. Is there something better that runs on Mac or, at least, has source code available? 

OK, so in the Elder arena I have those gratings that run over the lava at a few points. The gratings are func_walls so I can remove them at higher difficulty levels.

However, monsters would NOT cross them so I covered them with clip brushes in the hopes that they would.

Still no dice.

How can I convince the monsters that, yes, it's safe to walk across the scary gratings? 

That sounds correct, qbsp doesn't know that.

But I can't see how normal clipbrushes (that are world brushes) can help against clipnodes from brush ents, especially since the latter can be moving. The CSG process will only merge stuff within the same model.

And qbsp doesn't like clip texes on ent brushes ... 

Filling the holes with skip func_walls would be the most reliable way. 

Does Quake support skip brushes? I thought it was just clip and trigger... 

I don't think there are any compilers that do this, and I suspect that there is no way to hack it in. You can't create new buffers to store strings in without engine extensions, and there's no way to access the individual elements of a string from QC. A string in QC is really just the pointer to where the array of characters is stored. These arrays are either loaded with the progs, loaded from the map data, or accessed from the 16 char array allocated for each player's name. The last one is about as dynamic as strings get in quake.

What could be hacked into a compiler is some kind of keyword/macro thing called _tokenize(string n) or something, which would do all the work of calculating the corresponding character index for each character in the string you feed it, and then send each byte as MSG_ALL or MSG_ONE. It would still only be useful for fixed strings liked "killed " above, not loaded frlom map data. But it would keep the code looking shorter and neater.

A slight step in that direction would be for each fixed string in the progs, create an array of floats, so killed would become
s_finale_killed[7] = {107,105,108,108,101,100,12}

Then you'd have a loop

while(i<7)
{
WriteByte(MSG_ALL,s_finale_killed[i])
i = i + 1;
}

which writes it, which looks a bit better than a row of 7 WriteByte statements, and is certainly nicer for longer strings.



Additional: The idea of sending strings byte by byte is done to a huge extent in Pyrdon Gate, which is where I first heard of the idea. The source to v1.5 of this mod can be found here:
http://mindart.quakedev.com/code_crazy.zip

Look at menu/print.qc for a good idea of how it's all done there. One of the most valuable tricks you'll see is once you have a function
p4(float a,b,c,d)
which sends those four floats as bytes over the current channel, you can do stuff like
p4('D', 'a', 'm', ':');
which converts the characters to numbers for you, in this case printing "Dam:". This might be a frikqcc only trick, but it's worth a look. 

You need metl's skip tool (which removes all "skip" textures from the visible plane, thus making the func_wall invisible): http://www.celephais.net/files/newskip.zip

I don't know if the monsters were be able to walk on the grate if the clip brush was part of the func_wall. Skip is a safer bet. 

Be warned, if you do fill the holes with skip brushes, then they will also block grenades/rockets from going down the gaps, the holes are blocked in all but the visible hull. 

that way the monsters will be smarter for not walking over the holes.

There could already be fireballs coming out of the holes, I haven't looked at that map yet ;P 

I just gave it a brief test in your qarena map: You can make the monsters cross the grate by making the clip brush part of the func_wall entity. The brush must stay within the volume defined by the visible brushes. 

Preach

That looks usable. Not great, but under the circumstances it seems like the best option.

Thanks again! 

neg

I put a clip brush into the func_wall before and it didn't work but I'll try making it smaller so it just fills in the holes. I'll try that tonight. 

But did you also make it part of the entity?