Baal

Does your map contain lots of details made from brushes? Is everything aligned to the grid that's not an entity?

You can convert them to func_static entities (single patches or in groups). This way they aren't cut up by other faces which might safe some compile time. You can also disable shadow casting on func_statics if necessary.

Yes, this is a really bad idea. The faces of the containing brushes that would normally be in the void wouldn't be optimized away, your visportals wouldn't work, as you need sealed, separate vis areas for a lot of things and it would create unnecessary pathfinding areas...

I would like to give your map a test run. I have some mapping experience and I am very picky.

I'm interested but would vote for a size of at least 1280x1280 so it doesn't get to cramped.

Cool, thank you. Looking forward to the result.

The following command outlines all triangles of a scene that are send to the grafic card at a keypress. 'bind key "toggle r_showtris 0 3; toggle r_usescissors 1 0"' By only setting 'r_showtris 1' only the triangles that are shaded (lighting calculations) will be outlined (r_usescissors 'cuts' away triangles outside the visportal outlines).

Here are some new shots of my map, which is slowly coming together.

Yes, both entrances must be visportalled or your room won't be a separate area. But the single portal may still work and you may end up with a bigger area containing the room and whatever the other entrance leads to. If there's a connection (a leak) from the room to the outside area, the portal will not work because it just leads from one area to the same area.

Visportals separate areas. If you replace all visportal surfaces of a certain area with a stone texture, this area must be completely sealed off from the rest of the map. You can think of them as windows into adjacent areas. Only the visportal surface of the brush counts and they should be as small as possible without leaking. If there's a gap, like in your door example, the portal will not be placed (you can check this with "r_showportals 1" in game).

I could take a look at it.

Thanks for the nice words. _Atti_: Is this the same mission you posted a screenshot of earlier? It looks very good. Melan: You're right, there's a lot of detail in the normal maps; proper choice of textures and their alignment can make a huge difference. I also tried to make lighting a bit more contrasting and interessting as I think that's an area current missions are lacking in. One of the best looking features of the engine is the projected lights so they should be used more often.

Something I've been working on for a while. It's a small mission and hopefully not too far from release.

I think you just need to install some missing perl libraries: perl-config-tiny, perl-archive-zip and perl-libwww I don't know what they are called on ubuntu but it should be something similar to the package names above.

I redid the visportals of Silenciums "Thieves!" map. The early versions weren't visportalled optimally, too. It's not that big but I think it is a good example.

Congratulations! And I think the name is great. If you had named him Guybrush, that would've also been cool.

With all these special cases it would be cool if the script could give a list of files/definitions that have these (bump-, diffuse-, specularmap) stages instead of the short syntax. The problematic materials are hopefully not to many so that someone can adjust them by hand. The scale keyword, for example, can also be used in the frob highlight stage but then it will scale all 3 textures. I would prefer the script to do that but I'm not sure how much work that will be for Tels. Maybe it's enough to identify the special cases (special meaning materials that use the blend *map stage for at least on texture).

There are cases like these: bc_gembag { ... { blend bumpmap map heightmap(models/darkmod/props/textures/bc_gembag_h, 6) } ... } }I believe this is equivalent to "bumpmap heightmap(models/darkmod/props/textures/bc_gembag_h, 6)" so I could rewrite these defs manually before processing them with the script. And these: textures/darkmod/nature/snow/plain_snow01 { ... { blend bumpmap map textures/darkmod/nature/snow/plain_snow01_local scale 0.5, 0.5 } ... } If there are not to many defs that contain bumpmap or specular stages like this I can correct them manually. Don't check in the new materials yet. There are some problems (the green materials) that need to be figured out. I try to run the script myself and see what needs to be done.

Unfortunately there are also some "blend bumpmap" and "blend specularmap" stages in a few files (~30 files, so I guess they can be checked manually).

The "please check x" comments are wrong in some materials. This for example: diamond_large { noSelfShadow noshadows twosided translucent glass { blend diffusemap map models/darkmod/props/textures/diamond_large_d red 0.5 blue 0.1 green 0.1 } // TDM Ambient Method Related { blend add map models/darkmod/props/textures/diamond_large_d red global2 green global3 blue global4 } // TDM Frob-Highlighting // TDM Frob-Highlighting { // Please check: bumpmap if ( parm11 > 0 ) blend gl_one, gl_src_color program frob.vfp vertexParm 0 0 fragmentMap 0 _flat fragmentMap 1 fragmentMap 2 _black } }

That's good to know. But be sure to report here if there's something special about that version.

No, these special cases are better checked by someone anyway and the fallback you're using should be fine.

Use the _flat keyword in this case. According to iddevnet these also work as fragmentMap parameters.

Are you sure about that? I think you can still buy it online without problems (if you're 18).

As far as I know you can order it online relatively easy (proof of age 18). And I believe there is no special german version. It just comes with a translated manual.