chedap

You need to make it two-sided to drop shadows correctly. Only tris that are not lit by a light will form a shadow from that light (that's what you see on the second shot). Or think of it this way: if from a certain point you can "see" the light through the model/shadowmesh, that point won't be in the shadow. Also, set shadowmeshes material to shadow2, that will prevent "weird" sharp shadows in places. Since these are mostly convex, models not dropping shadow on themselves won't be noticeable.

Doubt most here are in on the joke. I'd like to say something like "Oh Cleve" to pretend I know or understand what the guy is about, but that'd be dishonest of me.

I can think of a couple. Basically any time the shape of an object doesn't allow for occluder's placement inside of it. E.g. a privacy screen, or curtains you can hide behind. With two-sided you risk accidentally occluding the object itself, or other small objects close to it. It's a pretty rare case though, and the use of an occluder probably wouldn't be justified in the first place.

If the performance difference is marginal, I'd say two-sided. Having to decide which way it should face to work can become confusing (to people unfamiliar with how engines work, it's unintuitive enough that a single one-sided plane won't drop shadow if it's facing a light).

Meh, I am of the opinion that trying your hardest to avoid player frustration, especially in the level design area, is just aiming for the lowest common denominator. And on topic of Valve's mapping guidelines I also think they might have been on target with Left4Dead, but then they way overdid it with Portal 2 (to the point where you just automatically shoot the only two bright squares upon entering the room and voila - puzzle solved, without brain involved). Like, go play the second level in Duke3D: can you imagine a progress-critical vent shaft above eye-level in a modern FPS? And yet, I don't remember having much trouble with the level, despite it being one of the first encounters with verticality in FPS for me (and, I assume, for lots of others too). Possibly without mouselook, too! Exploration is a quality I personally value the most in Thief/TDM, and it's pretty much dead in most modern first person games, even in supposedly "oldschool" FPS's. Avoiding frustration in this context is synonymous to "streamlining", and it's a slippery slope. Give the player a good map instead - not necessarily the most detailed one, but one that can be used to intentionally explore the place. It's something that can make or break an FM for me, and I especially noticed it with larger TMA FMs: e.g. "Art of Thievery" has great structure, but you'll only know that when you're almost finished, since the map is worthless. And, in contrast, something like "Hidden Agenda" or FMs by Morrgan are a joy to explore when you can understand the scale of things and plan your route. Intentionality is even more relevant for ghosting, nobody wants to repeatedly avoid same guards while aimlessly running around the place looking for a room you didn't visit. All that said, it's a good rule to respect the player, and player's time as well. Fortunately, switch- and key-hunts (the worst offenders IMO) aren't popular among TDM mappers.

A long corridor (e.g. in a hotel) with a row of doors into different rooms would not cause the discussed behavior, so red lines would just clutter DR even though most of the time nothing would be wrong.

Keep in mind that I'm completely uninformed, but assuming "distance to portal" is measured from its center, wouldn't that create difference in behavior between thin and wide portals (think VPing streets)? Also, a more common example (than a recessed wall) would just be a corner of a building, like this.

Just to be clear, does this only happen when they share the same plane, or would it happen any time 5+ VPs separate two visleafs? i.e. would this fix it or not? It's easy to "merge" VPs into one with a row of columns, but not so much if each VP has a corresponding door.

Maybe it's somewhat unintuitive, but once you have it picked up you have to "drop" it from your inventory and make it physically touch the end of a doused candle (or any other extinguishable light source). It's on the advanced side of TDM's interaction, since both dropping inventory items and their rotation are barely used beyond the training mission. I can remember at least one FM (was it "Lich Queen's demise"?) that requires the use of slow match to progress though.

From the screenshot it just looks like a long match (you can relight candles with it). If it's just a decor prop you can't pick up, it might not have been a good idea to put it in darkness, but it's not really a glitch.

A minor suspicion with "indirect" dousing vs. instant search mode when hit dead-on. http://www.youtube.com/watch?v=OB9ZhrK1A2s TDM 2.02

You should be able to make characters switch places with "copy_char" patcher command. PM'd.

It's probably still possible to silently put out a torch in guard's hand by aiming at ceiling above him (and timing it correctly). Don't know if it got affected by AI hearing changes though.

That's what I used/recommended as well, so like I said, not really a problem.Regarding wiki articles, this one isn't redundant, and it does link to patcher instructions. Leaving them as they are seems fine, I mean, it's hardly a frequently asked question, and it isn't going be asked again until some other language translation comes along. I see "needs Perl" has been added, the rest of the instructions aren't that hard to figure out.

Your patcher is functional, and aside from minor inconvinience of needing separate command .txt's to handle multiple input/output files, it seems bug-free. Really, it's fine. The reason for confusion was more on documentation side, since there is another wiki article with different tools (for more manual tweaking), and since the requirement of having Perl installed (for Windows users) isn't mentioned on the patcher's page. I've since sent instructions on how to set up the patcher step-by-step, so I think the issue is resolved.

The instructions here are working, just use the patcher on offending characters. Here's what I got on the first try using these values: source font_in/treasure_map/fontimage_12.dat target font_out/treasure_map/fontimage_12.dat decrease_xskip 0xF0 3 decrease_xskip 0xF3 4 source font_in/treasure_map/fontimage_24.dat target font_out/treasure_map/fontimage_24.dat decrease_xskip 0xF0 6 decrease_xskip 0xF3 8 source font_in/treasure_map/fontimage_48.dat target font_out/treasure_map/fontimage_48.dat decrease_xskip 0xF0 12 decrease_xskip 0xF3 16 Seems I overdid it with 'р', 'у' is alright, also 'б' and capital 'Г' could do with adjustments. But it's working. @charisma:

Go to control panel, switch it to "small icons", open "folder options", untick "hide known extensions" in the view tab (might be named slightly differently, my windows isn't in English). Or just type out the extension in the file name when creating an archive (7zip can do that). Any archiver should be able to open .pk4's once you associate them with it.

Since you mentioned some kind of conflict that prevents two active screens simultaneously, it would be a good idea to test how (if at all) it works with mirrors (including reflective water volumes and puddles). Also related, there's a fun bug/side effect of mirrors: since glare coronas and other "billboard"-type particles always face the player, their reflection might turn out facing the player sideways (might need to take a screenshot to support my poor wording). I'd bet it applies to any additional PoV's as well.

It's work-in-progress, not a design decision, if that's what you mean. Easier to tweak lighting first, then decide which model to use (in this case, they could end up on columns instead of walls). And since I'll probably model new light sources anyway I'm feeling too lazy for placeholders.

Yeah, didn't realize they had their own light sources. Can I make them show up in DR?

Might as well post here, too.

Should be 6 or 8 subdivisions, nothing that criminal.showlightcount: http://i.imgur.com/YtNyXdM.jpg And wall lights do intersect, I meant that aside from a single light volume filling the room, there are also several smaller ones illuminating the chandelier itself but not touching any walls.

noshadows applied to most walls gave me like a 1 fps increase. And it's a room isolated for testing purposes, single leaf, no VP.

Most of the scene is being lit by just one central light. Obviously, it overlaps with the wall lamps, but that's it. There are a couple extra ones around the chandelier (so it doesn't look flat), but they don't intersect or reach any walls, and so shouldn't be affected by changing brushes into patches. That's 50 fps without AI, in interior, without visportals open. Also, I would like to eventually make windows transparent and add curtains. I'm not necessarily aiming at the lower-end hardware, just decided to test whether getting rid of brushwork would help. Just in general or my case specifically? I wouldn't know what's different between TDM and vanilla Doom3, but I do have before/after versions of the scene for potential testing.