I added entity support and liquid support last night. 

you are a god.

Does it have options so that only skip on entities may be removed? I have a feeling it was the removal of skip from world brushes that was causing the problem with Tyrann's tool, so it might be sensible to at least have an option to disable it if it starts to cause problems with your tool too. 

no, but i'd rather try to actually fix the bug if we discover that my tool is buggy.

Of course if it turns out there's a bug I just can't figure out, adding that feature would be an option. 

what is the method you settled on using to make glass? 

I'm using glass at the moment under a Warp Version of Nehahara made by AguirRe - I failed to do this for warp through oversight.

I was reading through the documentation again and realised alpha could still be applied to any entity - func_wall glass. I haven't made it shootable yet but thats just a case of a snfx and trigger_once. And you can't spawn glass gibs because that's from the progs. 

I've got a few random thoughts for coding things in a simpler way, using wrappers on some of the built in functions, and before I forget them I figured I'd share. Putting it in mapping help because it doesn't belong anywhere else really.

The idea of putting wrappers comes from frikbot, at least that's where I saw it first. Entities that aren't players can't receive messages like centerprints. But instead of put exceptions for the bot in every weapon pickup, ammo pickup, etc, all the mod does is rename the function centerprint to centerprint_true, then make centerprint a function to check if the target entity is a bot, and send the message to centerprint_true if it's not. So the credit for the idea goes to Frikac.

The functions I'd put a wrapper on first are the precache functions, something like:

string(string s) precache_model_true = #20;

string(string s) precache_model =
{
if(framecount)
return "";
return precache_model_true(s);
}


This very simple wrapper doesn't run the precache if you've past the initial window, frame 0. In one fell swoop you've protected yourself from the game ending error that occurs when you precache things late.

This sounds like it's not much use in itself, because if the model isn't precached you're still gonna have problems if you try to setmodel, and you surely shouldn't be writing code that tries to.

Suppose though, that you were trying to spawn a key at some point in the game(that feature is done btw). It would be really nice to use the regular key spawn function item_key1, as it already does all the stuff you want it to. Plus if you ever update the code for the normal item_key1, you'd probably want to have the same changes applied to your later spawned key, so copy-pasting the code isn't ideal. But if you try to re-use the spawn code, the precaches end the game with a console error.

The first way to fix this would be to just add exceptions
if(framecount == 0)
precache_model ("progs/keymed.mdl");
to each instance of a precache, but the wrapper saves you a lot of time and effort. It does add an extra if statement to each precache you call, but that's a negligible effect, as it's only an extra load in the pre-game stages, and isn't called all that often even then. So I think it's a winner really.


So that's not precaching when you don't need to, but we can also go the other way. There's no need to take the risk of setting a model that isn't precached during frame 0, because we can precache it then. Rename setmodel to setmodel_true, and then add

void(entity e, string m) setmodel =
{
if(framecount == 0)
precache_model(m);
setmodel_true(e,m);
};

below precache_model. This allows you to write more compact spawn functions, you can setmodel directly without bothering to precache. Of course, you still need to precache any other models that might be needed in the course of the game, and any sounds, it can't do all the work.

The really useful part of this one comes from brush entities. Once you've made this change, you can add a point entity with classname, for instance, func_wall. Then give it a model field of "maps/shelf.bsp". Then you instantly get the ability to load the external model shelf.bsp into your map. This would allow you to create prefab func_walls that are used many times in your map, but only use up one precache. You could do the same thing by adding a precache_model(self.model) line to the func_wall code, but this way it works for all your brush entities, for free!

The saving of a few precache slots or lines of code may not seem that helpful on it's own, you might never need such external bsps. There's an idea I've been playing around with that would suddenly make this a much more useful tool, but I'll have to save it for another day(once I've coded/tested it). Hope there was something useful in this long, rambling post, have fun now! 

Almost like you're thinking of a form of mapobjects there, Preach. 

is there a way to do it that isn't weird and complex (like the original rotating stuff in the first expansion pack)? 

I explained it in the basepack thread (or perhaps this one) already, but basically it involves using a liquid brush as the visible glass with an invisible (by using skip) func_wall for the collision detection. Using skip you can remove surfaces of any water brushes near the glass and create the impression that the water is butting up against the water.

The main problem is that it only works on gl engines and requires the user to set wateralpha, but using Quoth you can set it automatically when the map loads so it isn't a problem for my basepack map.

Another problem is that the water and glass will share the same level of transparency, but using lighting and fog intelligently around windows can hide this problem well.

Alternatively you can require Nehahara or whatever, but I'd rather try and support all GL engines and software if possible. The map actually loads fine in software, but you can't see through the glass. The only software engine that supports transparent water that I know of is tochrisquake. I am not sure if Bengt has added it to his SW engine or not. 

ok thanks :D 

So, the cunning application of the external bsp files is this: rotating entities. Once you have the two wrappers described in the last post set up, add the following entity to misc.qc

void() func_illusionary_rotate =
{
setmodel(self, self.model);
self.movetype = MOVETYPE_NOCLIP;
}

Now you can easily set up a rotating entity in your map. First thing is to make your rotating model. Start a new map, and make the object you want to rotate. The important thing to do is to make the origin of this new map the axis about which your object will rotate. Set up some lights around it, to match the area of map - you don't need to be too precise about this, since it's rotating you can't sensibly have one half shadowed and one half light. Just give it about the right levels. Then compile it and leave it in the maps directory.

Then you just add a point entity to your actual map, with classname func_illusionary_rotate, avelocity set to how you want it to rotate and model to the path to the bsp model you just made. Position it so the point entity is on the axis you want to rotate about. Nice and simple, and it avoids the difficulty aligning the textures and setting up those origin brushes or whatever hipnotic had you do.

Obviously this is a simple example, but you can use it as a base for the more complex rotating things. For instance it's not a solid entity, but quake can't do solids rotating without an engine fix, so anything you'd do would be some kind of hack. I'm sure it's possible to adapt the hipnotic hacks to this method. Hopefully soon I'll have one of my own hacks worked out, and I'll post that too. 

Copied from Base Pack thread: On my current project (I used Quoth) I have a weird effect when (quick)saving, and reloading the map. The monster count (at the end of the level) doesn't correspond to any of the skillset.. Any idea about this issue ??
Is it something that is Quoth related, or simply a Quake bug ? Or could it come from my map ? 

The total monster count is saved directly in the savegame file, you can see it by opening it as a text file. It might be that somehow the server and client parts of the game are becoming desynchronized, you have to do a bit of work to update the client if the total number of monsters has changed. It's possible that somewhere the client is getting a (correct) update to the number of monsters, but the server isn't. Then when you save the game, you're going by the server's record of things, so you run into problems.

Anyway, I'd have to see the map and the save file first, it's not a issue known to me before now. 

actually one of the most common bugs in many mods; monsters are being spawned, resurrected or killed without being accounted properly (via killed_monsters and total_monsters vars plus updating the client).

It can be pretty tricky to track down these issues, but in all progs that I've fixed, the killcount should (hopefully) be correct. 

does DecodeLevelParms() get called when you load a save game? it might be messing up with left over data in parm11 and parm12... 

DecodeLevelParms(): Err, how can check its use ?

As far as I understood, it comes from the Quoth mod, so how is it possible nobody saw it before ? 

nm, i checked and it can't be because of decodelevelparms. 

As I'm developping a new Quake1 monster I want to give it some crossed over functions. So I altered the demon fiend in a kind of tribolitus creature, gave it a new skin and now I'm working on a qc for it.

As far things went right (had 15 vertice meshes in 81 frames) and now I see the creature everywhere...but nevermind.

I wrote a qc, which is a mix of the demon fiend and the lightning bold of the shambler. I'm almost done, but the last vexing problem is that by imitating the shambler's blast the qc compiler keeps bumping on

shambler.qc:194:Castlightning redeclared

The creature.qc compiles right now but shammy not.
Is there a way to relay this message or is the Castlightning an unique statement in the qc. I mean can it only be used once? 

If you copied and pasted the Castlightning code from shambler.qc with no modifications, try adding
void CastLightning();
to the very beginning of your new monster's .qc file. Then, delete the copied CastLightning code from newmonster.qc .


If you copied Castlightning but modified it, give it a new name like Castnewlightning in your new monster's .qc . 

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