I sat down tonight and wrote a new skip removal tool from scratch, which seems to work correctly with my problem map. Only thing it doesn't do right now is remove skip faces from brush entities (did the Tyrann's tool do that?)

Still got to give props to Tyrann for the proof of concept though; I wouldn't have been able to code this so fast if I didn't have a basic idea of how his tool worked. 

The Tyrann skip tool certainly removed faces from brush entities. I can't say for sure if it never caused problems, but I've certainly made a few maps and encountered no problems with this aspect of it. It's very good news that we've got a tool that works for the world model though. 

and it causes a HOM in GL engines. And I have plans for this feature. 

and it causes a HOM in GL engines. And I have plans for this feature.

what makes neg|ke the awesome-est. I would never think of HOM as a feature. 

well, i'll see about adding brush entity support tonight, and generally clean it up so other people can use it.

Oh, and I still have to test it in various engines, since the basis of the tool is a hack that works only because of the way quake renders bsp models. 

he's a hom-osexual 

Going to beat off in front of those mirrors over and over again. 

and it causes a HOM in GL engines. And I have plans for this feature.

Will these plans be ruined if I play with gl_clear 1? 

PLEASE add support for liquid brush types! I need that for my basemap which is having a few problems with Tyrann's tool, but I can't have glass+water if I don't use a skip removal tool. 

right, i forgot about that. So we want removal of *skip as well as skip, basically? 

actually I guess i'd need:

*waterskip
*slimeskip
*lavaskip
*skip

for all three contents types, plus *skip when you don't want the water ambient sound. 

To make ambient sounds disappear ingame, just use aguirRe's vis tool: there are -noambient<lava/water/slime/sky> option that allow to remove them, check http://user.tninet.se/~xir870k/readmevis.txt .. It has been added since rvis 2.30 ;) 

i meant removing ambient sound for certain brushfaces, not the entire map. 

Not necessarily. Since I use gl_clear myself, I will keep that in mind - some trigger_command trickery will probably do the job. Furthermore, software engines might be driven out by clever use of the limits. 

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.