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.

I love your dandelions, though they appear to be suffering from z-fighting with their own shadow-volumes: I think this is because you've modeled both sides of the leaves coplanar to eachother; the shadow-volume from the back-face z-fights with the front-face. Probably the easiest solution would be to turn off shadows for the leaves (if missing shadows aren't noticeable for 4 of the leaves, will they noticeable for the other 4?). Also, you don't need to model both sides of the leaves; it's generally better to rely on the twosided material keyword for that (twosided even automatically turns off shadows to prevent exactly this problem).

I've had TDM and RoE installed at the same time without problems in the past.

Enemy Territory: Quake Wars (which uses effectively the same engine as D3) has appearances/performance every bit as good as Dark Messiah. Just to second everybody else, most of the lag is coming from our (not yet optimized) AI. There's also the issue of us not fully utilizing normalmaps to allow us to decrease performance costs of models, so TDM's animation/lighting/shadow calculations take longer than they should. And finally a lot of our mappers aren't making optimized maps, which decreases what they can show while achieving good performance. On the other hand jdude's most recent map looks gorgeous while running smoothly. As for HL2 vs. D3, I've worked with both engines and greatly prefer D3... HL2 requires you to spend several minutes/hours compiling your map's lighting just to see any minor adjustments or tweaks you made. In Doom 3, you can see a perfect preview of your map while you're editing it. I can't overstate how much of an enormous help and time-saver that is for mappers. HL2 lets realtime shadows bleed through walls. No thank you. HL2 also limits the creativity of mappers in terms of texturing/rendering, because its material system isn't nearly as flexible as D3's. When was the last time you could make volumetric clouds and moonlight in HL2 without support from Valve? D3 is sufficiently powerful that mappers can construct their own new effects such as detail textures, volumetric clouds/moonlight, relief-mapping, bloom, etc, without id's help. This is what TDM's skies can look like, without even having to resort to pixel-shaders. HL2 also makes it a complete pain to do pipe-work. You have to model pipes in XSI or hope some other map's pipes are close enough to what you're looking for. In D3, you can easily create your own curves/pipes/etc right in the editor, and they'll be perfect for your map. ...though I will admit that HL2's terrain vertex blending tools are better than D3's, since HL2's are in-editor whereas D3's require a modeler.

Is it possible that the blowouts might occur with the progression of the story rather than every X minutes? That might be an interesting way of increasing the difficulty of early areas later in the game... But yeah, I hate time-limits with a passion (except in limited small-scale cases such as underwater or during a dramatic sequence)... there's a reason they've been abandoned since the days of sprite-based games.

I would assume only totally invisible on the side that's facing away from the light. (since the side is facing away from the light, it receives no lighting and thus doesn't modify what's on the screen, making it invisible) But yeah... I'd be tempted to add another stage, either additive or multiplicative (aka filter blending), depending on the situation (I'd probably use additive for casings for lights that are turned on, and multiplicative for things like windows away from lights). Just be aware that additive and alpha blending appear bright even if there's no nearby lights.

If you want just a simple translucent surface that uses lighting passes and nothing else, then the following would suffice: textures/darkmod/glass/flat/lamp_glass_lit_transparent { glass // doesn't affect appearance, only affects impact sounds translucent // avoids implicit opaque black stage used for filling the depth buffer twoSided // also implies noShadows diffusemap models/darkmod/props/textures/lamp_glass_lit // you could also include a specularmap and bumpmap } Again, keep in mind that the glass won't receive shadows, and each side will only be hit by light coming from that side (if you have a single light, one side of the glass will be bright and the other will be completely dark), unless the light is ambient. I think you're able to get away without using the 'translucent' keyword in that shader because it has no lighting passes (and perhaps because the first render pass uses additive blending). Also, if you'll forgive me nitpicking, "rgb 1" is does nothing (using values other than 1 would darken/brighten the image).

It's pretty hard to see in that screenshot, but if you look to the left of the raindrop, there's a vertical discontinuity in the water stream.

It's entirely possible to have lighting passes (diffuse, specular, bumpmaps) on translucent surfaces. However, there are some important caveats to be aware of. First off, stencil shadows require use of the depth buffer, so translucent surfaces cannot receive shadows. Also, all lighting passes are additive, and they are executed before all other render passes (so the filter stage is actually being executed after the lighting, and is reducing its brightness - it's misleading to put the diffuse/specular/bumpmaps after the other render stages in your material).

The problem arises when heat-haze tries to reference something offscreen... Since each section of the screenshot is rendered seperately, heat-haze in one screen can't reference an adjacent screen, resulting in discontinuities at the borders between screens. Unfortunately, it's non-trivial to fix in general.

Yeah, it seems like nobody ever bothers to read id's level-editing documentation. It drives me nuts whenever our mappers make levels with broken AAS then blame the weird AI pathing behavior on the engine. Yep... a simpler version that uses less CPU and that the player/AI are less likely to get stuck on. Fortunately, it goes much quicker than making the visual components of a level. You primarily just have to clip around complicated bits or around models/patches. Good places to clip would be around handrails or piles of junk. To be perfectly honest, I don't have experience with _impulse27, but I wouldn't expect it to generate AAS on roofs, unless it manages to find a path from a monster starting position up to the roofs.