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.