Gildoran

It loads them in alphabetical order, with later PK4s overriding earlier ones. Sometimes people try to exploit that by starting PK4 names with zzz (if I remember correctly the fixed declaration packs do it).

There won't be a campaign for the initial TDM release, but there will be a few complete maps. I agree with Springheel. We shouldn't expose players to detailed info, but there's nothing wrong with ironing out a lot of details of factions/history/etc for mappers.

I think that also ties into what was good about Thief's method of introducing the player to the world. Unlike RPGs that force you to read lengthy boring history novels before you can play the game, Thief gives you history/background as one small piece of the puzzle at a time, leaving you curious and wanting to know more. Learning about the world was often the apt reward for exploration.

It's done by taking many cross-sections of the rays. A single cross-section multiplies the inverse of the cloud density texture (ie, bright where light can shine through) by a brightness falloff texture and adds the result to the rendered image. I also make cross-sections bigger the closer they are to the camera.

I don't think they're available in vanilla D3. But you can probably find a skybox mod for vanilla D3 somewhere. Or you could get the D3 expansion, which I think has skyboxes.

Yeah, it does. Though it at least suggests that they may be aware of DX2's problems... That has a resemblance to this:

If you read through this thread it shows a few portal skies I did, and has links to videos in higher resolutions. In particular: Old V2 Skybox V3 Prototype V3 Sunset Sky V3 Sunset Sky modified to produce "god-rays" D3 is capable of just about any kind of sky you can think of, and it has the best material system I've seen in a game.

Stephane D'Astous certainly said all the right things... I just hope Eidos Montreal's actions back up their words.

If nobody has any other ideas we could name the highest reached alert level after the sorts of things guards might say... 0: Quiet night. 1: Must've been rats. 2: Who's there? Is somebody there? 3: Come out, come out, wherever you are... 4: Alert! Lock down the exits!

No SDK mods would be required to package a random entity placer in a user-friendly form, since it would be trivial to implement with an entitydef and a script. (eg, the distance-portals that shut off when you're far away are implemented in terms of an entitydef and script, without SDK support) The only major roadblock is that in D3, random numbers always use the same seed from map start, so a "randomized" map will always load the same way (perhaps they did that to help with testing). But that wouldn't be hard to change in the SDK. Also, though I'm not 100% sure (I don't have access to D3 at the moment ... my computer's motherboard is fried), I don't think you even need to use scripts to do this. There are triggers that automatically fire on map start, and I think there are trigger relays that randomly fire one of their targets and there are entity-spawners. Just hook all three together and you have random entity placement.

We all want DX3 to be of the same caliber as DX1, but overwhelming experience with sequels to popular games has taught us to expect otherwise.

Since it seems like everybody is suggesting that layers would primarily be used to hide/show rooms, what about having areas instead of layers? An area would be a set of brushes, and something intersecting any of those brushes is said to be inside the area. Things can be in more than one area. As you move stuff around or modify areas, it automatically updates which objects are in which areas. Areas could be used for visibility (I suppose an object would be visible if it's in any visible area). When an area is hidden, its volume brushes might (optionally) still be visible, so as to provide a simplified view of the map layout. Areas could also be used as an easy selection tool. I think "groups, areas and filters" would have a wider variety of functionality than "groups, layers and filters"; I'm not sure what layers provide that isn't already provided by groups - except that layers bypass the (I'm assuming) tree structure of groups. At least areas would be more automated, since they don't require a mapper to manually adjust which areas an object is in.

Whoops... I didn't mean to put the cart before the horse. That's not how I would have interpreted that... Given that Combatants is a layer and Female is a filter, I would assume: Applying the fact that Combatants is invisible and Cathedral is visible: Alice is invisible, since her only layer is Combatants and it's not visible. Bob is visible since Cathedral is visible. Cathy is visible since Cathedral is visible. Then, the Female filter is applied, weeding out Bob so only Cathy remains. As far as I can tell, it looks like you're assuming that an object passes the filter stage if it passes any active filter, whereas I'm assuming it passes the filter stage only if it passes all active filters... is that correct? Edit: I'm wondering if pseudo-code might be an easier way to describe our ideas about how layers/filters/etc interact. Here's my idea in pseudo-code, modified to include Blender-like layer behavior: bool Node::isVisible() { if ( _hidden ) // manually hidden by the user return false; if ( !_layers.empty() && every layer in _layers is hidden ) return false; if ( any filter in ActiveFilters() blocks this object ) return false; return true; }

I had an idea for a way to handle filters without iterating through the whole map every time the filter changes... (I wasn't entirely clear if things were already handled this way, so I thought I'd bring it up) What if a filterable object keeps track of its filter state and a nonce. When you change filter states, it changes the global nonce. Then isFiltered() could be written like: bool isFiltered() { if ( _nonce != GobalFilters().nonce() ) { _nonce = GlobalFilters().nonce(); _filtered = GlobalFilters().isFiltered( this ); } return _filtered; } That way, CPU isn't spent filtering objects until the result is needed, but the results are cached. If we're concerned about the global nonce overflowing, it would be extremely simple to iterate through the whole map and reset all nonces to 0 when the global nonce overflows (which would be effectively never). It just occurred to me that maybe I'm being a hypocrite. Yeah, we might be... although I think that there are some things which are difficult to explain but easy to understand once seen. On the other hand, the distinction between layers and filters is a little fuzzy to me. And I'm wondering if layers do anything useful that wouldn't be accomplished by letting the group hierarchy be a directed acyclic graph instead of a tree. It was a filter.

I was wondering... Has it been determined how filtering, layers, and hiding/showing interact with eachother? For example, let's say BobTheBuilder belongs to both LayerA and LayerB. If LayerA is visible but LayerB isn't, is BobTheBuilder visible? In case this stuff hasn't been worked out yet, I wanted to make a proposal for how they could iteract: Layers don't have a hidden/visible state, but you can hide/show the objects in a layer (exactly as if you were to manually go through and select each object, then press H). In other words, whether BobTheBuilder is visible or hidden is determined by which layer was shown/hidden most recently. Visible objects would be filtered, and would only be seen if they pass all active filters. Disabling a filter doesn't "show" (as in SHIFT+H) an object, it merely doesn't make it invisible. An example might clear things up: Let's say you have AliceTheArcher, BobTheBuilder and CathyTheCook. AliceTheArcher and BobTheBuilder are in the Combatants layer. BobTheBuilder and CathyTheCook are in the Cathedral layer. And there's a Female filter. Assume everybody starts out shown, and the Female filter is off. You hide Combatants, and only Cathy is visible. You show Cathedral, making Bob and Cathy visible. You hide Combatants, and again only Cathy is visible. You hide Cathedral and nobody visible. You show Cathedral and again Bob and Cathy are visible. You turn on the Female filter, leaving only Bob visible. You turn off the Female filter, and Bob and Cathy are visible. (note that Alice is still invisible)

I'm not sure if you would consider this stained glass, but these are from our screenshots page: (screenshot 1) (screenshot 2) (screenshot 3) Rest assured that stained glass is feasible.

As far as I know, it uses portals to limit visibility, not to connect space (hence why they're typically refered to as "vis-portals"). It assumes two objects are nearby each other only if their coordinates are similar.

I completely agree with Greebo. I am a huge proponent of D3 scripting. Ever since mapping for Doom 2, I've always wished for some kind of scripting system for 3D games. I've had to suffer through limitations of early trigger systems, and had to rely on Rube Goldberg contraptions in later trigger and S/R systems (eg, emulating logic circuitry using HL1 trigger relays). In comparison, D3 scripting is simple and elegant. It may not be as powerful as Unreal scripting, but it's still quite useful and easy, and is great for the vast majority of D3 applications. I sometimes feel like we're following trying to make S/R too versatile and use it for too many applications. I keep on hearing people say "Look at how useful S/R was in Thief! We should try to emulate that!" What they keep on forgetting is that the reason mappers had to rely on S/R so much to accomplish effects in Thief was because it didn't have a proper scripting system (I'm under the impression that its "scripts" were really DLLs - like the SDK).

Yep, I got it built with MinGW, and I'm going to try out Eclipse for code lookup/etc. How might I get set up to contribute to SVN?

If you think it's easy, feel free to make a portal mod to demo it. I agree with Crispy. If you designed an engine for that from the ground up, then it might be doable, but D3 and TDM rest on the important assumption that space is Euclidean.

I think I was just tempted to give the tree a root... it hadn't occurred to me that having WorldSpawn as a root might imply that selecting something would select the whole map. I suppose whatever the root (if any) would be, it would need to be transparent and not affect groups. Have we though about doing anything like Open Office (once we have the time)? I was thinking something like:The user can group things together with CTRL+G, and making an entity counts as an implicit group. They can remove a group (which may implicitly convert an entity to WorldSpawn) with CTRL+SHIFT+G. Selecting a group, and pressing Enter "enters" the group, causing everything outside of the group to become greyed out, and allowing the user to move components around, add new components, etc. Pressing Escape exits the group. Agreed. Yeah, but I like to discuss "ideal" behavior before discussing implementations.

Sure.

I would argue that making a diffuse map which includes ambient occlusion is good, but not anything that assumes directional light. In other words, making cracks, pits, dents, folds etc darker doesn't interfere with D3's lighting, but including directional highlights/shading does.

@OrbWeaver: I could fix this... The relevant code is in "libs\gtkutil\filechooser.cpp", line 67. The file dialog doesn't come with an optional parameter to set the default file. Do we have any preference for/against editing libraries? (Do we want to be able to swap them out with newer versions without losing our changes? Or would patches handle that?)

For how the grouping hierarchy behaves, does something like this sound reasonable? (I'm not implying that it would be applicable to anything other than grouping and I'm not talking about the underlying data structure yet. I'm just talking about how it would look to the mapper.) There is a grouping tree composed of Entitys, Primitives and Groups, with the following restrictions: The WorldSpawn Entity is the root. An Entity may only have Groups and WorldSpawn as ancestors. A Primitive may not have descendent's. A Group must have a descendant. (debatable) Here's an example tree: Note: It's unintentional that the nodes below WorldSpawn only have two children. I don't wish to imply a binary tree.