its a post full-compile tool, and it works just fine, Metlslime made it!! I used it for the fuse part of Slave. you just run:

newskip -mapname

all there is to it (just texture skip-able faces with a texture called "skip")

The old skip tool (can't remember who made it) doesn't like light tools, and the light tools dont like it)

I've got it at home, I can post it later but I'm sure if you google "newskip.exe Quake" you'll probably find it somewhere... 

Well, thanks, but I'd rather implement it at the QBSP level so it writes out a BSP file that is ready to rock. 

when they hit a skipped face. You see it basically removes the faces completely, and from my experience light and vis tools throw fatal errors at you every time :-( , so it can only be done after the process I'm afraid.

Although I can only speak from my level, if you know what I mean ;-P

but if you dont need to vis/light then I guess you could write it into a QBSP tool (?) 

Right. I know the Quest source code is available and they claim to support SKIP textures in QBSP but I was wondering if there were any others. 

Do you mean the one where a monster needs a target in order to fire it's killtarget, or the one where having a killtarget prevents target from firing?

For the former, the code you need to change lies in monster_death_use in monsters.qc. The line that reads

if (!self.target)
return;

should be changed to

if (!self.target && !self.killtarget)
return;

or just commented out, SUB_UseTargets can handle empty strings properly just fine.


The latter problem is a bit harder. The problem is in SUB_UseTargets in subs.qc, find the portion of code that begins
if (self.killtarget)
{
...
}

The do...while bit loops over all the entities, until a return is hit when t is the world entity - which in quake terms means we've gone through the whole list. The problem is we'd like to have it just break out of the loop, rather than return from the whole function - as currently it makes it skip the last portion that checks for targets. Solution 1 is to turn that little loop, everything I cut out from the quote above, into it's own function. Then just call your new function from the same point in the code the loop used to occupy.


Solution 2 is to rewrite the loop so the while condition actually breaks you out of the loop at the right time, without ever removing the world. That would look like:

t = find (world, targetname, self.killtarget);;
while(t)
{
remove (t);
t = find (t, targetname, self.killtarget);
}


Notice how we initialise t to the first found item, and put the while(t) at the front of the loop. This is so that if there are no entities with that targetname, the find returns world, and we skip the first iteration of the loop. Removing world crashes the server, so we really want to avoid that. 

I'm beginning to suspect that I'm the only guy writing tools anymore - aren't I? :) 

There is no compiler that currently supports skip faces, so for now it's done as a post-processing step. Everyone uses either tyrann's original "skip.exe" or my "newskip.exe", which both operate on the same principle -- leave the faces in the bsp, but shuffle them around and lower the marksurface and face counts, so that the game rendrerer doesn't try to render them. Example:

Leaf before processing:
marksurface count: 5
markrsurface array: 1,2,3,4,5

Leaf after processing:
marksurface count: 3
markrsurface array: 1,4,5,2,3 (2 and 3 won't be drawn)

The potential advantages to qbsp support is that it could save lightmaps, reduce light time, lower file size, and reduce the global marksurface count. I don't know how easy or hard it would actually be to write.

I suppose the advantage to the current situation is that you can use any qbsp you want and you don't have to forfeit using skip textures. 

This may be obvious, but if you add skip support to qbsp, you should not do it the cheesy way that our tools do it, you should support it the right way by fully deleting / never creating those faces in the bsp file. 

That's what I want to do, metl. Of course, we'll have to see if my incompetence proves too much for the task. 

the old skip tool is a bit buggy and doesn't support skip on fluids. Metls skip tool supports skip, waterskip, lavaskip and slimeskip textures so you can use it for effects like glass using water brushes and glass underwater etc.

It's pretty nice.

Probably best to implement skip at the end so you don't somehow get lighting promblems from missing faces. Still I personally tend to use it only on solidents and water faces. 

here's the thread for newskip, with links. 

http://www.celephais.net/board/view_thread.php?id=60088 

are there any up-to-date tuts on lighting for noobs? 

Does anyone know how far those cheating basta...., I mean trick jumpers, can jump across yawning caverns?

-bunny hopping
-grenade jump
-rocket jump
-vore ball fiend swipe
-double grenade mouse swipe back flip triple sulk ho
-etc

...given a flat surface and decent run up. 

Shambler Lightning Jump Surf. 

I meant the former, but seeing as you answered both I'll attempt the 2nd when I get back as well, the second solution seeming to be the cleaner way to resolve the issue.

Been away for awhile and get back in a few days, will be nice to be mucking about with Quake again. 

Never had that that a digger does not work. But when you have a digger in a group it only affects brushes in it, which is very usefull:

a room= two brushes: one of them is a digger. Group them. Put stuff into that room but not into that group. 

I have a trigger_push jumppad that doesn't work for some reason. It's placed a few units about a func_wall/floor and uses angles -90 0 0</a>. Touching it from the side slows down the player, jumping activates the push; touching it from above works fine.

Does Quoth have the coop item bug (items firing targets) fixed? 

I recreated your scenario, and indeed the same thing happens as you describe.

A quick workaround I found was to set the angles to -90.1 0 0. This pushes the player in a different direction very slightly, but only by about a few units, and it seems to work. 

I tried different angles for all axes. This is likely related to the angle 0/360 thing. All other jumppads work. 

You could try 270 0 0, I can't think why it's not working but if -90.1 works then 270 might also.

Does Quoth have the coop item bug (items firing targets) fixed?

Do you mean things that you touch firing their targets when you touch them, even if you can't pick them up like a weapon you already own? Yes, this has been fixed in quoth, although I remember me and Kell took a while working out what the right behaviour should be. Weapons will fire the first time they are touched by a player, regardless of whether they are picked up by that touch. Keys also work like this now, although it's not easy to have this problem in coop without allowing coop key cheating.

There is one oversight in the quoth fix of this problem to date. It is still possible for an armour pickup to make a trigger impossible - if the player has equal or better armour than what you want them to pick up. This isn't exclusively a coop issue though, it exists in single player too, so it kinda figures why it didn't get changed...yeah. 

i need a door that:

-opens when shot at from one side
-opens by trigger from that same side
-doesn't open from the other side
-displays a message when being shot at from that other side
-does all that multiple times
-oh and it needs to be passable ;)

my problem here is the shootable triggers - they are solid, right? can you disable stuff and then enable it again? 

then use Metlslime's skip tool to make it invisible, or make a shootable door with a set close time which is also invisible. You can make doors and buttons which are invisible, either can be set to be shot to activate, this is how you can make it so that it only works from one side of the door....

hope that helps... :-o 

...that's what you want, megaman.

There's a way to do this, but it's in no way pleasant. Here's how it goes:

You need to split your door into a front half and a back half, and make sure the front door is higher in the entity list than the back. Make both of these entities into func_wall entities. We're now going to trick the game into thinking these walls are in fact doors, although we get to pick what functions they run when hurt or touched.

So to begin, give the front and back doors all of these keys

speed (set as usual for a door)
wait (ditto)
health 1
maxhealth 1
pos2 (offset vector - see below)
takedamage 1
state 1


In addition, give the front door

think LinkDoors
nextthink 0.5
th_die door_kiled
touch door_use
noise1 (path to the sound you want played when the door stops)
noise2 (path to the sound you want played while the door moves)

and the back door

th_die SUB_Null


The offset should be how far you want the door to move when it opens. So if it opens vertically upwards 128 units from where it starts, then set pos2 to '0 0 128'.

At this point, you should have a pair of doors that link together when they spawn, so that if you shoot or touch the front part of the door, it opens. When you touch the back door, it should do nothing, and when you shoot it all that happens is it bleeds.

Once you get to that stage, post on here. The final trick to get a message sent to the player when you shoot the back door. That last part is the most difficult thing, because there's a complication or two which means we can't just paste the normal shootable trigger death function into th_die. I may have a way to do it though, but it's best that you have everything in the map working first. If it does work you'll need to do a bit of editing the ents file for it... 

wow, thank you preach.

I have it simplified a bit, which isn't that cool, but requires less of a hack.

I'll see if i find time in the next days to try your suggestion.