Gildoran

It's not real.

You would find the section of the code that looks like set "title::text" "$gui::title"; set "body::text" "$gui::body";and add something to change the size of the body rectangle if the title is empty. Perhaps something like: set "title::text" "$gui::title"; set "body::text" "$gui::body"; if ("$gui::title" == "") { // I forget if the $ is needed set "body::rect" "x y w h"; // replace x y w h with enlarged body rectangle } Instead of "x y w h", you'd have the rectangle that'd you want the body to take up when there's no title.

You know, it'd be possible to make a gui that doesn't allocate space for the title if it's blank...

Readables are limited by what GUIs can do. That precludes things like changing font or size in the middle of a paragraph. The only things that xdata can affect are settings that can be changed at runtime (because the GUI reads its settings and modifies itself at runtime to apply those settings). Font-size can be changed at runtime, so it would be possible to control that with xdata. On the other hand, the font is static, and therefore cannot be affected by the xdata decl. I was eventually planning on implementing some way for GUIs to detect when a setting has been set (for use with textscale), but never got around to it... I highly recommend avoiding all text colors except black, because they're drawn using alpha-blending, which causes them to glow in the dark, even on in-game models. (if we could find a way to draw them multiplicatively, other colors would be feasible)

You might check out this post for an explanation. (the bottom has pictures that may help show what's going on)

blend filter and blend modulate both mean multiplicative blending. If you only have one settable color, you might do something like this for the frob part: { // this can stay the same since it just scales the brightness of what's on screen if ( parm11 > 0 ) blend gl_dst_color, gl_one map _white rgb 0.40 * parm11 } { // implicit: blend gl_one, gl_zero map alphaMapRepresentingColoredAreas maskColor } { // Where the alpha is high, additively blend, tinting with your color if ( parm11 > 0 ) blend gl_dst_alpha, gl_one map yourDiffuseMap maskAlpha // just to make sure we don't screw up the alpha red 0.15 * parm11 * yourColor'sRed green 0.15 * parm11 * yourColor'sGreen blue 0.15 * parm11 * yourColor'sBlue } { // Where the alpha is low, additively blend normally if ( parm11 > 0 ) blend gl_one_minus_dst_alpha, gl_one map yourDiffuseMap rgb 0.15 * parm11 } Any custom material stages will only show up in-game or in D3ed's preview... I wouldn't worry about it too much, since the editor image is only there to give an idea of what texture is being used when you don't have the lighting preview on.

How are you doing the blue overlay? If it's multiplication, it should work fine. If you're doing something like blend blend, it'll be too bright. This is entirely possible. For a while I was trying to encourage people to avoid making multiple diffusemaps. In fact, textures/darkmod/stone/brick/red_sloppymortar_dark does exactly what you're looking for, except you'd change the rgb keyword into separate red, green and blue keywords. The one tricky bit would be getting the additive part part of the frob highlight to match the color (it may be easier to just not worry about it for now). No, blend add is blend gl_one, gl_one. blend gl_zero, gl_one_minus_src_color means to use the following formula: screen = (0) * image + (1-image) * screen which simplifies to screen = (1-image) * screen blend gl_one, gl_one (eg, blend add) means to use the following formula: screen = (1) * image + (1) * screen which simplifies to screen = image + screen It's very similar; rgb x is shorthand for red x green x blue x Likewise, colored is shorthand for red parm0 green parm1 blue parm2

Both blend methods have the "transparency" controlled by color, though they look at color in opposite ways (because blend filter is equivalent to blend gl_zero, gl_src_color). blend filter multiplies what's on screen by your image; as a result, darker sections of your image change what's on screen more than lighter sections (white doesn't change anything at all). Colors are valid too. blend gl_zero, gl_one_minus_src_color multiplies what's on screen by the inverse of your image; as a result, lighter sections of your image change what's on the screen more and darker sections change it less (black doesn't change it at all). Colors are valid too, but result in the opposite color being seen. Think of your image like a mask. The advantage of this blend technique is that red 1 - parm0 green 1 - parm1 blue 1 - parm2 can be used, allowing the mapper to control the color/intensity of the image via an entity's color. In general that's not true, but for surfaces to interact with lighting and shadows, they must be fully opaque (though it is ok for them to have "holes" where they're not drawn at all). Transparent surfaces may interact with lighting but cannot receive shadows. Lighting is additively blended, so its transparency would be controlled by the color.

I seem to remember that the advice wasn't intended for players so much as developers... no idea what the supposed problems were, other than that they supposedly had to do with D3 assuming paths were a single word (in the console?).

You could certainly do things with the window brightness fading in/out over time and with having "shadows" move across the brightness. You'd probably just use tables to control the animation. However tables loop over time and aren't random. You can't have truly random materials without some outside source influencing their parameters (which would require the window to be on an entity). If you have a bunch of windows just applied to worldspawn, they will all animate the same way, all in-sync. There may be ways to mitigate that by having different animations for different parts of the texture space, but it could be difficult for the texture artist to set up, and would require the mapper to have each window occupy a different part of the texture space. It might also require more render passes per window, leading to performance problems. If you want to have randomly animated windows which behave independently, by far the easiest way would be to put each window on a separate entity designed to control the window, though that could quickly eat up the 4096 entity limit. (it may be possible to economize by having a single entity control up to 12 independent windows) The other challenge would be having the window controller only running when in PVS; I think my previous solution to this may be buggy on multi-core systems, but using a more conservative approach should work almost as well. It's not possible for a texture to be truly random by itself. I might have been referring to using textures to cause stars to pseudo-randomly twinkle, or to using entities to randomly control textures...

Given that the entire gameplay code is in the SDK, a mod would be able to change the player's gravity and view orientation. The real question is how easy/hard it would be and whether it would be worth the time to implement it in TDM (I think we have more important concerns right now). Also, given that AAS is precompiled with assumptions about gravity, I think it'd be difficult for monsters to navigate while taking new gravity into account.

Yeah, one of the most common mistakes I see in TDM textures is having the "grain" of the normalmap be way too intense... it always makes the textures look like zebras when viewed close up. Though I don't think that's a result of using a normalmap generator, as all my normalmaps come from generators and they don't have that symptom. The other thing I see a lot is diffusemaps that look like paintings rather than photos, or diffusemaps that come from photos with directional lighting... if more of our textures came from high-res photos carefully chosen to avoid directional lighting, I think that would help a lot.

I was looking at Yahtzee's videos, and I noticed that he recently released a game called The Art of Theft (it stars Trilby so I presume he's the author of 5 days a stranger and 7 days a skeptic). I'm enjoying The Art of Theft right now and thought other Thief fans might like it too...

If you crouch down and look at the model, you still don't see any z-fighting? (the screenshot above is from citybeta, at the start) It's possible for it to cast shadows on itself, because the two sides of the leaf face opposite directions but occupy the same position: The problem is that the bottom side of the leaf is casting a shadow, and the top side is (barely) intersecting with that shadow. Overlapping coplanar faces can be ok when they have identical triangles, but the shadow volume is calculated slightly differently on the GPU so its triangles are slightly different from the leaves' triangles which causes z-fighting. Can you point out which other models have overlapping coplanar faces, and I'll describe if I'm experiencing any problems?

I actually once played just such a Flash game, though you controlled the fat slob directly instead of it being a god-game.