rotation is your friend. Usually you will be rotating 45 (1:1), 27 (2:1) or 63 (1:2) degrees. Textures will normally still be skewed if the brush is angled on more than one axis (e.g. a curved trim that is sloped upwards) so the best thing to do is to use a fairly plain texture that doesn't have too much detail that would make it look obviously skewed. 

until recently that Worldcraft (versions 3.3 and above) have a nice set of buttons on the texture properties dialog:

Textures can be fit across one face or multiple faces, or aligned to the left, right, top, bottom, and center of faces with a single button click.

http://collective.valve-erc.com/index.php?go=hammer 

I don't know why, but for some reason the texture alignments I make in Radiant for this angled stairtrim <href=http://biff.leveldesign.org/pics/base_defuckt.jpg>here</a> don't look the same ingame. I've heard from SPoG that it could be a compiler error, but I'm not sure what to do if it is, and if it is. Gah. 

I obviously fucktangled the link to my illustration, so here: http://biff.leveldesign.org/pics/base_defuckt.jpg 

...I get that sort of thing when I forget and try to use an angle that is not an integer. 

if the editor lets you set floating point rotation values. The map format (or maybe the tools) only allow integer rotation values. 

which one? Is it the tools or the map format that restricts texture degrees to integers? I am sure I don't know :{ 

What could I do in this case? 

when i have an angle like that that isn't on a integer rotation, I sometimes break the span into two smaller chunks, and bend the texture slightly at the middle, so that it follows the shape more closely. Or adjust the geometry to have a different slope (sometimes the geometry can't really change, though.) 

I think I've got an idea on how to avoid the whole angled brush thing altogether, but it means redoing the composition of the room. Gah. But thanks you guys =D 

http://kell.leveldesign.org/

When I go to download one of Kell's skyboxes, I get 404 on all of them. Just a heads up. 

I use a later version of worldcraft, and I also use Bengt's compile tools. Needless to say, WC decides on some insane texture coordinates when you use the "intelligent" fitting functions. But, they compile just fine. Try those compilers out. 

Think I'm already using aguirre's stuff. Bah, I've changed to room up anyways -- just hoping now I've got enough room for a decent coop session. 

When I go to download one of Kell's skyboxes, I get 404 on all of them. Just a heads up.

ahem...

Due to the inordinate amount of work to compose 49 separate downloads, these skyboxes are currently only available in a single download as The Kothic Skybox Compilation.

http://kell.leveldesign.org/skies-kothic.zip


;) 

Works for me. Thanks for the reply. 

Not sure where to put this, but it doesn't deserve it's own thread, so I guess mapping help is probably the place. A while back I posted the code for adding a teleporting monsters flag. If you set it then the monster would start invisible and teleport in when you triggered it. There were two things about the code I posted which I didn't like.

One was that I'd been lazy and not used a spawnflag. This was mostly because I didn't want to check which spawnflags were already used for monsters, so I just used a different field for the flag. This works fine, but in retrospect I think spawnflags are the way to go. The other was that you had to alter each monsters' spawn function to impliment the code, which is tedious and messy.

So I've got around to writing up a new tutorial on how to do things properly, and it's now up on inside3d.
http://www.inside3d.com/showtutorial.php?id=171

This new function should work on all monsters, even custom ones, as long as they use walkmonster_start. This makes it nice and easy to plug in to any existing mod, which should be helpful. The tutorial uses spawnflag 8 for teleporting, which to the best of my knowledge is safe for monsters. Anyone know of an exception? 

So I drop in a trigger_hurt in front of a health console thing (ala Half-Life) and it successfully gives the player +health (by using a negative numeral damage). But, 2 problems:

- the player reels back in pain (this could be explained, I mean - shots do hurt)
- you can continually eek health past 200!

So how do you stop either of these bits, but mostly - how do you stop it from continually giving you health beyond the set value (say -50 - which would add +50 health to your current health). 

Make the brush an info_notnull with the following fields

think InitTrigger
nextthink 0.5
touch health_touch
healamount 50
noise items/r_item1.wav

If you want regular, non mega-health style healing, ie. capped at 100, that's all you need to do. If you want mega-health style, capped at 250, with tickdown for health over 100, then add

healtype 2

This will only trigger once, but there are ways to reactivate it. If you add

use SUB_regen
targetname blah

then every time you trigger blah it'll restore it for another heal. I'm not sure if any combination of those will do quite what you want, but play about and I'm sure you can get a reasonable healing machine. 

Thanks! That works wonderfully except for 1 minor message/error:

Sv_startsound: items/r_item1.wav not precached 

put a health pack somewhere in your map and it will precache the sound.

This should be the case with any sound you want to use, so if you want to use a fiend grunt sound you need a fiend in the map.

Maybe Preach has a special hack for precaching sounds though :) 

Afraid not, there's no way to precache an arbitary sound or model in the original qc. Which is a bit of a pain as you could do all sorts of interesting things like mapmodels if there was, but all the precaches are explicitly specified. So yeah, that sound is the rotten health pack sound, change it to whichever sound you find suitable. 

Does anybody know how to improve the terribly jerky ending sequence of Dissolution of Eternity?

I've only been able to improve it by reducing camera tracking updates by angle comparisons and a timer. 

As I understand it, the problem is that quake angle updates on entities are only sent out as a single byte, which gives you poor precision, lower precision than a single degree in fact. You might want to speak to the SDA guys, as angle turns seem much smoother in their setpiece demos(like the credits sequence for the easy 100% run they released at Qexpo). So if there's any way around it I guess they know it. 

such protocol limitations too and I'm sure it's correct.

However, I don't think that's the problem here as this is not a demo; the camera entity updates the view in discrete steps (following nextthink 0.1) and it doesn't seem to help to make the steps smaller either.

My hope was that there'd be a way to make the camera pan the scene like a player turns. Otherwise maybe the easiest fix is to just update slower, thus making the camera work steadier.

Btw, what is the formula for calculating where an entity will be shortly according to its current origin and speed/direction? 

I'm pretty sure the problem isn't present so much in demos, and only appears real-time cutscenes such as this, becuase a fixed path for a camera has to be sent out from the server(which has the progs.dat) to the client, and so uses the network protocol. Demos record a client's perspective so maybe they can get higher precision that way. I know that one of the selling points for proquake was that it had "double" precision on aiming, ie two bytes, which makes a noticable difference for aiming rockets etc. I'd expect the same would be true on camera things, so the system would be limited more by update rate(the nextthink).

If you get round the protocol limitations then the way to ensure a smooth update is to use PlayerPreThink or PlayerPostThink as they get called each frame. Have a flag set when the player is watching from a camera that needs to update angles, and call the angle setting function from one of these functions whenever the flag is set. I still don't think it'll help more than a little without the protocol changes though...


The latter is easier to solve, for constant speed you want

entity.origin + (entity.velocity * delta)

where delta is the amount of time into the future you want to predict. If you only have a scalar speed and direction vector, go for

entity.origin + (normalise(ent_dir) * ent_speed * delta)

Use makevectors to get ent_dir if the direction is given as an angle. The first one will probably suffice in most circumstances though.