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. 

iv got worldcraft 3.3 with the addon that lets u map for quake, but i cant seem to compile my map, i get a error in each and every step of the compilation process. 

Give some details, and there may be a solution!

One thing I will say is that the WorldCraft process window has always been a problem, and it would be recommended that you run your compiling programs under a command prompt (i.e. start> programs> accessories> command prompt - then:

cd c:\(insert your .map file and tools dir here)
txqbsp (mapname)
vis -fast (mapname) ==> "-level 4" instead of "-fast" for full compile
light (mapname)


OK, so you may well know all of the above already :P

Please specify the error for more help :-) 

i used to have a batch compiler for hl1 i could get it again u think that would work betteR?


** Executing...
** Command: Change Directory
** Parameters: c:\quake


** Executing...
** Command: Copy File
** Parameters: "C:\BSP\Quake\Bats\testmap1.map" "c:\quake\id1\maps\testmap1.map"

The command failed. Windows reported the error:
"The system cannot find the path specified."

** Executing...
** Command: c:\program files\worldcraft\quaketools\nomapversion.exe
** Parameters: "c:\quake\id1\maps\testmap1"


** Executing...
** Command: C:\BSP\Quake\Bats\QBSP.EXE
** Parameters: "c:\quake\id1\maps\testmap1"

Transparent water QBSP with Hipnotic extensions
MultiWAD version 1.65
by Ken Alverson based on original code by John Carmack

outputfile: c:\quake\id1\maps\testmap1.bsp
************ ERROR ************
Error opening c:\quake\id1\maps\testmap1.map: No such file or directory

** Executing...
** Command: C:\BSP\Quake\Bats\rvis.exe
** Parameters: "c:\quake\id1\maps\testmap1"

---- vis ----
************ ERROR ************
Error opening c:\quake\id1\maps\testmap1.bsp: No such file or directory

** Executing...
** Command: c:\program files\worldcraft\quaketools\light.exe
** Parameters: "c:\quake\id1\maps\testmap1"

----- Light 1.43 ---- Modified by Bengt Jardrup

************ ERROR ************
Error opening c:\quake\id1\maps\testmap1.bsp: No such file or directory

Elapsed time : 0:00

** Executing...
** Command: C:\Program Files\Quake\glquake.exe
** Parameters: +map "testmap1" 

Er - what is happening there is that the compilers arent configured properly, I can only speak for myself here but I put the compilers in c:\quake\id1\maps, which is the same place that I store the working rmf and map files. This way the only dir that Worldcraft crappy process window has to look is the one folder that all of the files are in!

http://www.mediafire.com/imageview.php?quickkey=dxr4mm4cicn&thumb=4

Although I will say:

"** Parameters: "c:\quake\ id1\maps\testmap1&q..."

what the hell is the &q doing at the end of this line? Heh - I don't know!

This is a stupid one: - does the dir c:\quake\id1\maps\ exist on your PC?? (I assume so, but you never know!)

From the log it seems that the error first occurrs during the copy file process - because of this none of the other tools will work because the file did not copy to the destination folder, which is where the compilers are looking for the file....

Hmmm