Serpentine

Which error(s) are the ones showing? If you can upload the map somewhere Im sure one of us will know whats going on. Backwards and degenerate triangles should just flash past while dmapping as they are ignored/optimized out...

Does the console give you the name of which entity caused the leak? try reading up in the output for it, then use the entity list it up in DR(and like most things in DR, if you just start typing it will search). If you rotated a prefab or copy/pasted part of another map; it's most likely one of the entities is visually in the correct place but has its origin far out in the void. This what usually causes these for me, point file is around 3-4 points of bouncing around the void. Usually just solved by having a read in console edit : posting while half asleep.

This can be cause by a number of things - the first is please try starting doom3 and putting in the CD key there. If it accepts the key, restart d3 and make sure it doesnt ask again. If this happens chances are that TDM will be fine. If that doesnt work, I remember someone had the same situation regarding gamex86.dll as happens with some people getting a black screen... but try making sure doom3 is happy first. Starting the map directly will skip a lot of 'nice' things, so it isnt really recommended.

It depends more or less on the type of scene you are going for, the more energetic the waves the harder it will be to make them. If you just want water lapping against the shore you could most likely get away with just a decal layer against the edge and some simple manipulation on the material shader, it supports a few things which could be used to jiggle it around fairly easily. As you dont have a real wave height (well, you could if you want to spend a while load of time making a vertex animated object); Avoiding energetic/low angle scenes would be the best bet. Perhaps modding an ocean shader to get a more 'wavey' surface. Just some ideas

I always overlook the simple things :/

Hey Kalwin, If you could try making a new shortcut to DR and turning the windows compositing/aero off in its properties, that might fix it up. If you cant find the option there just disable Aero completely on windows and see if that gets them back. If it is related to this, it is being looked into by the ever awesome greebo

Since we now know how much you love the lunix; If you happen to feel a need to punish yourself, you could throw DR through valgrind or similar... I wonder if clang's analyser would get far enough to give you a report, assuming there is enough C code sticking around from gtkradiant. That could be kinda handy, but I have no idea the status of clang outside of freebsd. Just food for thought

The music is included in TDM itself, but the map itself will tell you what the track name is etc if you dig around. Otherwise just use the sound browser to try find it.

Everything included in TDM(which includes the training mission afaik) can be reused in maps - you can extract the map file and have a look at how things are done etc if you are unsure of anything.

I've been playing around for the 30 minutes or so with it, it does a really good job with 'mixed' detail textures, areas of moss and then of brick etc. Looks really good with most brick work. For more organic textures or detailed stuff it seems to get very confused no matter the fiddling. But it does make me feel like a kid in a candy store, trying to figure out what I can do, since its so different from the traditional method. My preview stops updating after a few adjustments which makes life a bit more interesting, it can also get quite slow on large textures. Also just a side note, it doesnt produce perfectly tiling normals, it seems to often have 1px borders of solid colour on the edges. Something quite 'interesting' if you want to get grass/leaf/tilingrock normals to look good is throw them trought creating an ssbump+ao baked in, then using photoshop match colours to a cheap normal (since it uses very exotic colours) of the same texture, you end up with a slightly strange looking normal. But in game it has a very nice characteristic similar to njob but with a lot more detail on things like blades of grass, light bumps etc. On bricks and tiles it looks too detailed to fit in with the other materials however

Yup, just use an empty folder to make your life easier

The updater itself knows nothing of doom3, it meterely does the downloading of TDM into the folder it is currently in. In other words, you can run it from any folder and it will fetch the same things. All you would have to do then is take the new folder home and copy it over the existing one to update it. Much the same as doing it via a torrent. I'm sure that someone will package a torrent for 1.01 - but it might take a day or two after release and might be quite a bit slower. Using the updater is more than likely going to be the fastest way

Hmmm, I guess I can try it out on medium and see if that changes the load time - then compare it at medium if it seems reasonable. Will do that tonight

See, this is the interesting bug : even if you _force_ it to use the dds by specifying the exact filename and placing it in the location - it will skip them if it somehow detects it doesnt want to use them (Besides setting your gfx to low/medium I cant find any cvar that controls this reliably without influencing diffuse etc). So I had the same idea as you, Im going to force it by removing the tgas... surely it will default to the dds... surely. Well it turns out it doesnt quite like the idea of that either and rather enjoys the look of black ingame. Normal's cant use DXT1/3, you had to use DXT5 (yes, unlike the others), with specific colour biases. You can find more on the wiki and Katz blog (there's also a link to the correct version of compressenator there, which you will need, the latest has removed the colour format as it is somewhat problematic) If you have any issue with the dds file not following this exactly, doom3 will not do anything with the file and will skip it. But even after all of these specifics, the results are 'ok' for most normals, but no where near 3Dc, which is finally supported by nvidia - but typically they do it in a round about way. If you want to look at a comparison of filesize etc, you can just copy all of the *_local.* out of the TDM folders and run a batch conversion on them. DXT1 with mipmaps should give a comparison to the ideal method - tho the more likely option is that which uses DXT5 + mipmaps and the specifics.

Cameras attached to AI + script to fade in/out time changes = nyesss. The time control could make for some interesting cinematics/cutscenes efforts too

Been playing with compressing the normals, but there is no reliable way to make doom use them - if it thinks you're using a decent graphics card it will just not bother using the dds and instead use the tga, even when the dds files are placed in the correct folder etc. Its annoying as you could half the size of the 1.1gb of normal maps in TDM1.0 to around 470mb. It would be great to get 3Dc support (I have no doubt their friends at nvidia didnt want that happening tho, considering id actually did a lot of research into compressing normals but in the end 'decided' against it, you can still find the papers about it.). Would also gain a good bit of load time(since when it uses the TGA's it does its own RxGB conversion at load time) and a little performance with full mipmapping, I dont think doom3 generates them. My experiment for the day

Since it does say diffuse is to be DDS and Normals uncompressed, Im fairly certain I meant that the archival copy would be TGA+RLE. I dont know many people that work on textures and scale down each time they save to check ingame The comment was made as he was suggesting that perhaps people had put in textures which were RLE'd, while I said that its likely that people did hand over RLE'd copies as it does allow for it, if those are used in the mod is not part of the logical statement however. In a world where carrots can be held in baskets while apples must always be in baskets it is the case that there could be both carrots and apples in a basket. Mountain, molehill etc. And the following incorrect formats are in 1.0 (normals): gfclock_local.dds lion_glass_local.dds arch_scrollwork_local.jpg corpse_local_ed.jpg stripes_local_ed.jpg - should be redone, looks like the colours are way off

The texture guidelines are quite badly worded and do say that RLE is fine - I wont change that til its confirmed. Most modern cards dont actually have great management for TGA, certainly not low level. They are most likely converted to just standard RGB which is fairly inefficient in itself. I wonder if d3 supports 3Dc mmm

http://forums.thedarkmod.com/topic/10168-scaling-icon-for-tdm/page__hl__TDM%20icon__fromsearch__1 It wasnt NH after all! Other than that, you can dig in the tdm pk4's (open with winrar or an alternative)

I havent run into any trouble with RLE, but I did see some people mention it over at doom3world. Sadly, even once opensource; adding jpeg2000 would be somewhat futile, as it stands most opensource libs for decoding it are horribly slow - and thats just in pure software, where most things dealing with jpeg get a substantial boost by hardware these days. On the other hand it does allow you to easily get hold of scaled data (think mipmaps, kinda). Its an interesting thought, a lot of current opensource and even commercial games, simulators and the likes would benefit greatly from a new optimized texture forumat taking into consideration things like alternative maps etc, I know there was meant to be some M$ one, but I havent heard anything of it lately and Im sure it isnt supported by any editor.

Ah, my TGA's are all RLE'd which would make quiet a bit of difference, but that is besides the point, the reason I said it was pointless to try compressing them more is that the simple deflate with fairly minimal settings picks up on the redundant data very easily (I wasnt clear) Someone asked about jpeg decoding in doom3, yes it is supported... tho avoided at all costs for things like specular/normals due to the artifacts looking really bad on scaled textures, lightmapping or something it -could- be ok if you controlled the encoding variables. As for compilation time, on a 4 year old rig it takes something like return to The City about 2 minutes to compile. But yeah it was just a more conceptual thing Yes, I am a terrible person who likes to compile thier entire nix box etc, even if there is no real reason these days. I will throw the tdm files through uharc with its multimedia extensions for some strange kind of amusement.

Someone, I think NH did produce a high res icon... try searching the forum and shout if you cant find it

I dont think the OP is talking about 7zip(LZMA), rather just standard Deflate(I think thats all doom3 supports) using better settings. But agreed, time vs. effort is not worth it, its an extra step for an author for such a tiny gain. If file mirrors wanted to make a script to automatically recompress the uploaded .pk4's with better ones it wouldnt be too hard either (if anyone ever worries about that) Another thing is while FM's that are large are released, a large portion of them will be the textures. TGA doesnt compress very well at all, DDS even less. .maps and associated formats should compress reasonably well, so that isnt a worry. If TDM really takes off and people start getting massive bw hits, perhaps fm's coult contain a flag which tells TDM to compile the map on install... but that is highly unlikely and just food for thought

You should most likely bench the difference on a mid range pc, I always unpack the pk4's so that I can mess around easily, but I would think that it might have slowdowns loading some map areas etc if you compress it quite heavily and it is a custom texture/model/asset map. But just how much - who knows.

Fire arrows and torches, a perfect... match.