Baal

Outdoor sections are just big rooms with a special skytexture on the ceiling (a simple case). You should start with the interior (which is much more easy if you're new to the engine and editor) and add "outside rooms" later. Don't worry if this explanation is a bit confusing, it all becomes clear with a little experience.

If you plan to use it outside under bright light conditions you need a bright display (I think at least 200 cd/m^2). Netbooks are great only if size and weight are important. They are easy to carry around but don't compare to a cheap notebook performance wise. Some of them have really good battery life time though (4 hours and more). Most notebooks don't reach that. If you want to use an external monitor on high resolutions the VGA out that all current netbooks have is not optimal. I'm not an expert on this but I know it's something to consider. It all depends on what exactly you want to with it.

The treeview selection affects the texture browsers display (only active categories are displayed) and vice versa. I don't want them to communicate directly but through their parent (the material browser widget containing them, not the tree store singleton if I think about it further). But I can't get to specific because there's not enough done yet. And I'm still looking through the code to see how things are done.

I intend to do it something like this: There's a singleton (material browser or -store) that keeps the tree store and (multiple, so that you can have texture browser and media browser windows) browser widgets. They each contain a treeview and a texture browser in a paned layout (among other things). You can hide one of the two panes or show them both (3 layouts accessible through buttons or maybe tabs). The widgets need to communicate their input. I could do that through callbacks or maybe call methods on the singleton directly.

I'm still working on this and I have a question for OrbWeaver or greebo. What kind of callback mechanism do you prefer? There are the GTKRadiant templates, GTK signals and boost also has libraries for this.

I would try it but I still didn't get to play "Scratches" or "Edna bricht aus". But thanks to your recommmendation I chose the latter as a christmas present for my brother and he liked it.

A decal or blendlight would make it possible to control the fake shadow independently of the light sources volume. That would be much easier to manage than a projected light texture on the source which would change with volume adjustments.

On every surface inside its volume. It just blends its texture onto the surfaces without specular and normal map lighting calculations. At least that's how I understood. I haven't tried them.

I would say what's best depends on the respective situation. Interesting, these blend lights. Which shader do they use? I guess it's not "interaction.vfp" but a more simple one.

When you're building open areas, like city streets, always keep things like performance, sound propagation or AI path finding in mind. The most important tool for this are visportals, so try to set them up before you've built the whole level.

Maybe this could be done with an appropriate light texture. The projected lights are a very cool feature of the engine. And they can move to some extend.

They are correctly linked together, there's no obstacle and the node is above ground. It's a "path_corner".

I already read that. It seems one of the two possible paths doesn't work. If I add that node as a target (alone or as a second one) the AI doesn't move anymore. What could cause this?

Is the possibility to add multiple targets to a path node implemented yet? Or am I doing something wrong?

You can get a better sense of scale by putting AI and models into your map. (Re)texturing and placing models is quick and easy so I would do that from the start. And even though some things will change you'll still learn the basics of darkmod/doom3 engine editing.

Why, I haven't done anything yet. Who is actually using a layout where the combined view wouldn't fit? In my case (the splitpane layout) there would be no switching anymore since the window can be made big enough. The shortcuts will of course be left as they are. I just noticed that the regular layout is a bit different. I guess the people who are not happy about this change use this layout? It would have to be possible to open two texture browser windows to keep the existing functionality then.

The new tab would have 3 layouts between which the user can switch: The first contains both and would look like the model browser (with the right window containing a view similar to the texture browser). You don't have to switch between them. If the window is not big enough the user can switch between 2 and 3 which is nearly identical to how it currently is.

It would merge the "Media" and "Textures" tabs into one and provide layouts for this tab similar to the existing ones. I definitely don't want to significantly change something others are used to.

The window could have 3 possible layouts: 1. Both tree view and texture view side by side. 2. Tree view with minimized texture view (like the media browser). 3. Texture view only (with a button to switch between all and currently selected perhaps). If the containing window is to small the user can toggle between 2. and 3. I think he meant me. Yes I do.

Yes, that's exactly what I have in mind.

Like the model browser for example. I'm not using the embedded view though, where it would not really fit. I have to think about how it could be done in this case. I should explain a little better: The texture browser filters by the selected category in the tree view; by selecting the parent in the tree it would look like the current texture browser. If you select a child it only displays this category (only the loaded ones). By finding textures I don't mean the ones that are already used but browsing through categories to decide which I could use. When I start something new I normally load some categories (wood, brick and cobblestone for example) and see what fits together. I never liked the way they are all lumped together. I do both regularly so switching between windows is annoying. In my opinion, GTKRadiant did this much better.The media browser already has a preview but it's not as useful as the texture browser (to small on high resolutions, only one at a time). So what I want is either a texture browser with categories or a media browser with a better preview. Obviously that would mean to merge them.

Something that always bugged me about the texture browser is that it doesn't show the materials in categories (like the media browser). That makes looking for a specific texture very annoying when a lot of them are loaded. I'm wondering why these are even separate windows. So I would like to merge the texture viewer into the media browser (models, entity definitions, sounds would fit in there too but I don't want to be to ambitious). What do the programmers and other mappers think about this?

I'm not sure what you mean. The .map files contain architecture, objects etc. Do you want to look at them in the editor?

Yes, I will report that to the bugtracker.

This is a correct material definition: textures/darkmod/stone/brick/rough_blocks02 { stone qer_editorimage textures/darkmod/stone/brick/rough_blocks02_ed diffusemap textures/darkmod/stone/brick/rough_blocks02 bumpmap textures/darkmod/stone/brick/rough_blocks02_local { if ( parm11 > 0 ) blend gl_dst_color, gl_one map _white rgb 0.40 * parm11 } { if ( parm11 > 0 ) blend add map textures/darkmod/stone/brick/rough_blocks02 rgb 0.15 * parm11 } // TDM Ambient Method Related { blend add map textures/darkmod/stone/brick/rough_blocks02 red global2 green global3 blue global4 } } You can modify that for now and ask when there are problems.