cool. 

I figured out why you can't get up the ladders in darkplaces, though I gotta tell you it was a bit of a stumper for a while. The problem is actually the size of the solid boxes around the metal grills, in darkplaces these are made too large. The size of them is calculated based on the dimension of the sprite reported by the engine.

Winquake(and presumably all other engines):
'-64 -64 -64' '64 64 64'
Darkplaces:
'-90.5 -90.5 -90.5' '90.5 90.5 90.5'

For reference, the sprite is 128x128 pixels - and one pixel to one quake unit is drawn in both engines. So why does darkplaces report such a strange value? Well, 90.5 is ~ sqrt( 64 * 64 + 64 * 64), which is the length of the diagonal line from the centre of the sprite to the corner. So I'm guessing that it's stored like that to create a corrected "bounding radius" for the sprite. This is to make sure you don't get into the situation where the corner of the sprite should be just on screen, but the engine thinks you can't see it any more.

My feeling on the matter is that this updated bounding radius should not be sent to the qc, and that darkplaces should just store it internally. I don't think this would be hugely problematic to fix, the fact is that nobody uses sprites in quake, so it's probably never been noticed before. 

I've got testers reporting missing quake.wav and quakeend.wav at level start. All are using -hipnotic -game quoth with Quoth and Quoth2 installed. I've double checked .map and the level doesn't call these sounds. Ideas? 

the most noticeable one is when the game begins by playing demo1, and the explosion sound of ogre's grenade would be missing. 

er, what was it, its coded in the info_screenshake to play those sounds. Re-assign the sounds to "misc/null.wav", for the keys "noise" and "noise1", in every info_screenshake in your map, and the warnings will disappear!

I think Preach answered me on the mapping help thread, #7180


:-) 

..I'll do that tonight. Mebbe there'll be another base map out this weekend :) 

The earthquake sounds are available in mission pack 1, but not in the quoth packs. If you actually want them then send me an e-mail, but you can just silence them like Ricky says.

The missing explosion sounds in the start-up demo is in fact by design. Quake sends the explosion sound automatically whenever you tell it to create the explosion particles. In order to make it possible to have explosions with different sounds, the default explosion noise is replace by a silent .wav file and explosion noises are added "by hand". This can be seen with the bob. Of course, the noises are not added retroactively in demos that were already recorded. 

Will the Quoth2 pack be updated with these sounds? 

Preach, sorry for not testing with my other map. That had the screenshake entity in it and I didn't notice the sounds were missing back then.

It would be cool if they could be added in an update. Maybe the current pak could be replaced? Anyone with the old pak would still get the warning, but it's not a big deal. Are there other complications that could arise from modifying an existing pak?

Should we just ship the sfx with our maps? 

My map is in the latter stages of vis. I can do

txQbsp -onlyents

and

light

and then theres only newskip.exe to run, but after I do that, I cant change anything, cause changing the ents would require re-doing the lights (some lights toggle on-off), and light.exe has a fit after newskip is run... (takes deep breath)

In short, I'd like to know! 

thats gonna confuse people.

I just mean I can get rid of the "noise" and "noise1" keys in my screenshakes, but only before I run newskip.

Unless theres another way. I'm too scared of loosing my vis data! 

light -onlyents then 

:-( 

There's no plan at the moment to update with a patch. If we were, the plan would be to create a pak2.pak with the patch elements in it, to be overwritten when part 3 is released. We'd make that a separate download and patch the full file at the same time. But we'd really only use that option if a critical problem like a crash bug came up. So for now I guess the best thing is to distribute the sounds with your map. Otherwise it'll go from you telling us there's a bug to people playing your maps telling you there's a bug, even though it's not your fault, because they didn't get the patch.

And yeah Than, don't worry about not spotting it, I messed up too. I had a test map for the earthquakes, but I was specifying the sounds by hand, so the defaults were never tested.

Modifying entities:
There's at least one way of doing this when a map is fully compiled, without having to worry about which utility to use at which time. Get a copy of adquedit:
http://www.quaketerminus.com/tools/adquedit_v13.zip

Then open the bsp file with this program. You'll see a button to extract entities. This saves them to a text file, where you can edit them directly, add new fields, even add entirely new ents to the map. Then use adquedit to import them again. The text file is basically an ".ent" file, but the program bakes the entities into the map when you use the import function. 

ATM I have the misc/null.wav set for noise and noise1. I think I'll probably leave it that way, but its nice to know I could change it if I so desired in the future!

cheerz 

using *any* old bsp modifying program on a modern bsp, they'll most likely trash it completely.

Ricky: If you don't change any brushes, you can always do another fullvis (or fastvis) run using the same prt+vis file. As long as the prt file doesn't change, the vis file should be OK.

A new run only takes a few seconds. 

How long has your site been suspended for? 

kell.QUADDICTED.COM

:D 

I played around with trigger_command and found a bug. My message is "screenshot". Sometimes when moving through it "+attack" or "+forward" are appended to "screenshot" = "screenshot+attack".
It doesn't bother me as it does not affect what I am doing but it seems undesired. 

Of course +attack is only appended when I actually +attack at that time. 

You must suffix all commands with \n, so that the commands don't run into each other. We toyed with the idea of having all the _command entities sending "\n" after all commands but it doubles the network overhead, and stuffcmd is traffic intensive to begin with. So it's up to mappers to format the commands correctly, but when the tutorial is extended to cover all the _command entities, we will make this explicit. 

I read that before but forgot about it. Thanks. 

nice stuff! Not overly fond of the backpacks though.

I liked the new maps, although I felt the texturing in e1m2quoth didnt always gel. One bug too, some of the pillars or buttresses kept disappearing and reappearing (sort of like software greyflash but they would just disappear). Is this known? I was using aguire's engine. 

quoth2_mapsources.zip 404s 

when is the Quoth mapping tutorial going to be completed?