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. 

Two func_door entities next to each other (touching, door_dont_link NOT set), one for each side of the actual door. First door has to be triggered to open and displays the message when touched, the other one has health and opens when shot (only from one side).
Wouldn't that work (haven't tested it)? 

That will work in a similar way. The message for the back door will disappear as soon as the door is opened either by trigger or by shooting. Also it means you can't hijack the way that the back door behaves when you shoot it, but if you're sending the message on touch, that's less of a problem. 

i'm using that, without message triggers. Wait, can doors have a message?

/me checks

i'm such a q1 mapping noob :( 

it doesn't seem to work here, skip surfaces always stay and it's always reporting
----- newskip version 1.0 -----
copyright 2007 John Fitzgibbons

Filename: megad2lvl3-2.bsp
Removed 0 faces.

and my .map file looks like this:

// brush 646
{
( -2016 352 224 ) ( -2048 352 224 ) ( -2016 224 224 ) skip 0 0 0 1 1
( -1728 352 256 ) ( -1760 320 128 ) ( -1728 352 128 ) metalt2_3 0 0 0 1 1
( -1728 224 128 ) ( -1728 224 256 ) ( -1728 352 256 ) skip 0 0 0 1 1
( -1856 224 128 ) ( -1856 224 256 ) ( -1728 224 256 ) skip 0 0 0 1 1
( -1856 352 256 ) ( -1728 352 256 ) ( -1728 224 256 ) skip 0 0 0 1 1
}


i tried calling it right after bsp or after light. What are the other possible pitfalls? 

I assume your WAD file contains a texture called "skip"? Because if you hand edited the MAP file then QBSP wouldn't find the skip texture and it would assign it the default checkerboard which might cause the skip tool to fail.

That's probably not helpful but there you go! 

ah, that makes sense - why would the bsp replace the texture though? That doesn't seem to make a whole lot sense ;) 

It doesn't replace it necessarily but since it can't find a texture called "skip" in the WAD file it nulls out the reference and the game draws it as a checkerboard (the default texture). You should get an error when you try to QBSP that MAP file saying something about the SKIP texture wasn't found... 

the replacing part doesn't make much sense.

q3map just assumes a default texture size (so the uvs are scaled wrong) but leaves the face intact otherwise. 

Oh, I can't speak for Quake3 ... sorry, I was talking about what I know from Quake1's QBSP code. 

There's a .wad a the shubhub named 'ikbase_r2', is this the definitive ikbase .wad? Are there further variations lurking elsewhere? 

basically, if a texture is not in the wad, qbsp doesn't create an entry in the bsp, and if it's not in the bsp, there will not even be a name that can be read by engines/tools. 

should be:
http://ikq.planetquake.gamespy.com/art.htm#ikbase 

...thank you.