If they are not completely dark I'm pretty sure that it is caused by fastlight (it is not very accurate and does not calculate the detailed areas) 

You can't have attenuated sunlight, it would kind of defeat its purpose ... You can however change the way sunlight (and other lights) affects angled surfaces via the anglesense features.

Also, make sure to use sunlight3 instead of sunlight2, it greatly improves details in the sunshadow. See readme for lots of details.

ETP is just a name for any method of specifying texture positioning that couldn't be done in the classic Quake map format. For Q1 I only know of QuArK ETP (its default map format) and Hammer's Valve 220 (recommended for QuArK, too). With those formats, you can freely rotate textures in all three planes.

If you're using WC 1.6 or earlier there's no ETP. The bad shadows are then probably caused by complex or bad brushwork and they might be reduced by using -soft -extra4 in my Light.

However, it's rather common to have a few bad spots in terrain-like brushwork. I'd guess it's a limitation of the bsp format/tools and/or accuracy of float values. 

aww..

i was more thinking of technical limitations.. i'd disagree that it had no purpose. i made a little demo map & took two screenshots to compare:

http://www2.jameson-h.com/fr/ftp/rj9k/sunlight.htm

the first is with your sunlight & nothing else; the second is with attenuated lights & no sunlight info. whilst the shadows enhance the first screenshot, i think the second provides a much nicer & more realistic feel with the fadeoff. it probably shouldn't replace normal sunlight altogether but i think it might be something worth looking into at least..

btw, i turned -fast off and it seems to have reduced it a bit a few bits remain but they aren't so noticeable. i'll start doing extra compiles nearer completion.

and it's WC1.6 i use, oldskool bi-planar texturing all the way ;) (although admittedly the lack of freedom can be a pain in the arse sometimes)

thanks both of you for the suggestions! 

that attenuated lights have no purpose ;) I meant that there's no such thing as attenuated sunlight; the distance attenuation at any practical surface difference near the Earth is next to nil.

Since there already are attenuated lights in the light tools, the sole purpose of sunlight is that it's non-attenuated and with parallel rays. Before, mappers used to add many pointlights or "delay 3" (infinite) lights along the skyline to mimic real sunlight.

And while I may be biased here, I think the first shot is the most realistic one, although the 2nd is also interesting. In any case I definitely recommend adding subtle ambient pointlights to outdoor areas to reduce the somewhat uniform sunlight. Maybe some hint of a cloud effect ...

Btw, if you use WC together with TreeQBSP, I'd suggest adding the -oldaxis option to handle 45 degree textured surfaces correctly. 

what you say about sunlight in reality is very true, but if the sunlight in question isn't direct (ie, it's a cloudy day) and you have a fairly enclosed chasm environment (like my maps tend to be quite often :p ) then the further down you go, the less sky the rock is exposed to. maybe it could just be called 'skylight' as opposed to sunlight.. or something. i dunno. i guess i should just figure out a way to combine both methods & stop moaning about it :p

and thanks for the oldaxis tip, i've noticed quake renders diagonals differently to WC.. 

if you look back in the screenshots thread at the 'numen' preview i posted up, you can see the skybox i'm using and can hopefully see why i don't consider sunlight appropriate, since the sun is pretty low & the majority of the sky is a flat orange shade.. infact i've already got the sunlight at a low z-angle (-15ish) in the first map since it really makes an impact in the 2nd shot 

I worked some time with qmle and imported dxf files. Is there a way to foresee the excact shape of the model?
I mean, let's say I want a cube of 64x64x64 as new imported stand model in qmle.

Point is that when I import a dxf file it is imported in qmle as a random shape. I can never tell the excact measures. I could use the transform tool, but in this way it won't become the cube I need.

My solution seemed to created a 64x64x64map, compiled it to bsp and try bsp2mdl and try to load it in qmle.
But the dxf files I draw from it change shape when I import them to my CadCam programm. 

it was easier than I thought as the qmle grid measures are 32. 

Since your tools compile the half life .map format into a q1 bsp, could they also just spit out a q1 .map from an hl .map? 

The thing about the quake model format is that it stores all of the coordinates of the verties as single bytes, in the range 0-255. The model then has an offset vector and a scale vector in floating point values. You may find if you save and reload your model in QMe then it will have developed inaccuracies. The grid in QMe works seperately to this rounding off, so it usually just makes things worse.

Of course, if you only have one frame, then the upper and lower boundaries of the model will always be correct, as they are stored as '0 0 0' and '255 255 255' as bytes, meaning one is the offset vector, and one is the offset plus the scale vector.

The easiest way of thinking of this in my opinion is that quake creates a grid with 256 gridlines in each direction, then scales it so that it exactly contains the model in all the frames. The vertices that are furthest out on each direction sit on the edge of the grid, and everything else is snapped to it.

The problems will arise once you make the model larger than that 64x64x64 box in some frames, in any direction. Then the scale and offset vectors get recalculated, and the box vertices get snapped to a new grid. One way to get round this is have a frame somewhere in the model larger than all the other frames, with two vertices placed very carefully. For instance, if you have one vertex at '-128 -128 -128' and one at '127 127 127', and nothing outside those ranges in any frame, then your grid will be in multiples of 1 quake unit. If this isn't a clear explanation, take a look at:
http://www.btinternet.com/~chapterhonour/pickup.zip
which shows it in practice.

The thing is, adding this weird sized frame is just tricking the tools into making the scale and offset into being correct. At some point, I plan to modify my export script for blender so that you can specify offset and scale manually, rather than have it calculated automatically. Of course, if you make the scale too small to accomodate the model then outlying vertices will get squashed, it'll need some thought. 

No, they don't export map files. You should be able to convert using QuArK, though. I guess another way is to just use Hammer/WC3.3 for continued editing of a Valve 220 map.

I also heard something that one version of GtkRadiant could read Valve 220 maps and then save into Q2/Q3. This could then be edited directly in Gtk (possibly also exported to Q1) or further converted to Q1 by e.g. my ConvMap. 

that converting a Valve 220 map into plain Q1 might result in screwed up textures as some ETP stuff can't be represented properly. 

Thanks Preach, for your explanation!

I just started at good luck, making a model base with one square stand position of 64x64x64. Then I imported it into Qme and took the output mdl to quark47. A quick vieuw in Quake, with a transposed e1m3 file and a cube 64x64x64, translated the stand position.

In this way I could manage to recalculate the measures until it became a regular fitting cube form. To my surprise it were the correct double 32 measures of Qme.

Another point appears with the texture. I took a_floor1 because of it clear square outfit. But as I had to diminish the texture to 79% for the model, they seem somehow flattened in game in opposite of the mapbox textures.

I think I have to live with it, because I see no other way. It looks as if the model, hidden in the map boxes, will reveal itselves in some way. Also models always have a lightened shape, as map boxes receive their lightning from the light.exe themselves. 

I've been snooping around and I think the map exporting functionality has been removed from gtkr. I might be wrong though.. 

Ok, I'm trying to make a ceiling fan that rotates in the normal way (around the vertical axis.)

Problem: No matter what I do, it rotates around the horizontal axis. It looks very stupid.

It's the first time I do this... I'm a bit unsure how to proceed.

I have my rotate_object, the fan. I have an info_rotate directly below it, on the axis of rotation. Below that is my func_rotate_entity. Rotation is working, so the targets etc. are OK.

1) Do the info_rotate and func_rotate_entity need to be on the _center_ of rotation, or is it enough to put them anywhere on the _axis_ of rotation?

2) For rotation around the vertical axis (Z axis I assume), what does my rotate key need to look like? I tried 0,0,90 and 0 0 90 but neither seems to be working. I also tried 0 90 0 but nothing changed...

I need a bit of help here. czg's tutorial isn't very specific and I think it contains errors. 

Figured it out. I'm officially stupid. The vertical axis is the Y axis. ^^ I seem to have missed some geometry lessons.

Someone should make a clearer tutorial, or Kell could just put an example map into Quoth. I might make one and donate it.

:) 

of any specifics regarding rotating stuff, but AFAIK the vertical axis is the Z-axis. Maybe your problem is related to the sometimes strange key formats; yaw/pitch/roll etc. 

Rotatings are a cunt to set up - czg's tutorial is fairly clear, but the idiotic way that the rotatings were coded makes it a process of trial and error to implement, since I believe that it does use both angles and pitch / yaw / roll.

I'd guess that this hacky code got past when the Hipnotic project leader was off with flu. 

I found out by trial and error that the Y axis is vertical. The Z axis is "depth" and thus one of the horizontal axis.

X and Z are horizontal, Y is vertical. In math, X goes left-right, Y goes bottom-top. Z is "depth" in three dimensional space.

The "mechanical" part was pretty simple actually. The rotating object itself is turned into, surprise, a rotate_object. It rotates around a corresponding info_rotate. Third we have the corresponding func_ entity, like func_rotate_entity and func_rotate_door. This point entity has all the information, mainly the "rotate" key. It holds the combined direction and speed information. "rotate" "0 45 0" gave me what I needed: Turn 45 degrees per second, around the Y axis.

Luckily I didn't have to set up collision detection. Player has no RL, so he shouldn't be able to reach the fan. :) Laziness!

:) 

No Z is usually vertical
In quake for instance, z is vertical

IN Math it is relativ, because you can rotate the coordinate system.
but always the same is:
when you look through the z-axis in the positive way then, x is right and y is left
when you look through the x-axis in the positive way then, y is right and z is left
when you look through the y-axis in the positive way then, z is right and x is left

Had my final exams focused on geometry ;) 

Then how do you explain that "rotate" (0 45 0) makes it turn around the vertical axis?

The key's format is (x y z) so in translation, that means "turn 45 degrees per second around the Y axis."

So either Y is vertical in Quake, or the func_rotate_* is buggy. Or the whole map is rotated and I didn't notice. :)

Anyway, it works :) 

3dsmax is the most common 3d tool for games because its cheaper - alot of people prefer maya (forget shitty softimage) but it does the same thing; changing z for y. And has alot of other problems for exportation.

Ballache. 

Again, I don't know any specifics about func_rotates, but the key format pitch/yaw/roll is one of the used ones and then your example means 0 degrees vertical pitch, 45 degrees counter-clockwise around the z-axis and 0 degrees roll around that vector (possibly not used).

And you can look in any Q1 editor to verify that z-axis is indeed the vertical axis (i.e. up/down from the floor). 

ijed: Ballache is the right word :)

AguirRe: That is so far over my head, I might have to re-read that when I'm less tired to grasp what it means. It sounds reasonable though. 

test is to load a map in FitzQuake or any of my engines and use the console command viewpos.

Then you'll get the xyz coordinates of your current map position and then three extra values that specifies how an intermission entity key should be specified to look in the same direction as you're currently looking. Move the view and check again to see how the values change.

This is one of the formats used when specifying a vector. Another is the more simple spot/sunlight key of TyrLite or my Light; pitch/yaw. See the readmes for more details on this.