Search the Community

Lurkers use those accounts to keep track of what they've read via the cookie. There's no rule that you have to post on forums, so it'd be unfair to delete them.

I've been following Dark Mod all along (somewhat), but had been really trying to support T3Ed and surrounding stuff. Thus, I hadn't played any T2 FMs for a VERY long time, until last week I fired up and played the whole T2X. It was then that I again realized just how much better the movement and feel of classic Thief is over TDS, especially leaning, rope arrows, and water. I knew it all already, but it was a big reminder that just seemed to hit home harder this time. So I came back to read up on Dark Mod some more, and I noticed the forums for the first time. After reading a bunch of threads and stuff, I decided it's time to climb aboard and really focus more on TDM at this point, since it's the last best hope for a bright Thief style FM future!

The TDS forum was starting to slow down last year, but a turning point in my mind was when Krypt admitted that the engine was something of a fluke and the T3 devs themselves hated using it ... and from his and Randy's description of things, it was the main culprit behind most of the disappointing features and design-work of TDS, which just adds insult to injury. It just sort of officially confirmed everyone's experience that FM making on it is not only an uphill battle, but against the spirit of the original games even in the dev's minds. I'm happy that FMs are being made on it while TDM is in production, though, and with the minimalist additions I even hope they'll continue like T1 FMs come out on occassion ... adding spice to the mix (actually, better if they come out more often than T1 FMs, because the technology is more advanced). But, yeah, my chips are with TDM for the future. By the way Komag, I was wondering when you'd finally register on these forums and start posting. What took you so long? Or maybe the right question is, what brought you here now?

I tested it with the snapshop 0.9.6pre version, no problems. With the 0.9.6exp4, just: - Make a blank room, add start point, one light - add a few small brushes, convert to func_static, save, dmap and test in game (everything is fine) - select the func_static and "revert to worldspawn", save, dmap and test in game and this is where you see the black square. If you move the brushes after reverting or delete them, the black square is where they used to be. So it seems that something gets created upon the "revert" command, some phantom object that you can't see or delete in DR. I couldn't find it in the Entity List either.

LOL, no Just saying good that you found a good price etc. I'm browsing 3 forums atm lol...

Someone on the OXM forums in the UK said they can configure me one with a top notch ATI graphics card for £800

This was due to a change in the def files, which had the editor_mins/maxs spawnargs set on the moveable entityDef. I think it happened during the entityDef reorganisation. This borked DarkRadiant's handling of moveables with child brushes. It was mentioned somewhere in the Next Release thread I think, where people were reporting blue boxes instead of moveables. The spawnargs have been removed and these types of moveables are working again, but the core issue that DarkRadiant has problems in these cases is still there, though. I got it reproducably when starting a new map, creating a brush, convert to func_static and save. Komag also reported a few more cases above.

http://forums.thedarkmod.com/index.php?showtopic=10 Have you checked this thread? The FTP is tempermental sometimes.

WHUT?! That's totally new to me. From what I have read so far, the 9800 gx 2 will be 40 % faster than the 8800 ultra at much (!!!) lower costs. Please post some of those reviews, because I was going to buy that card as soon as it's released here. My GTS is way too slow. I was looking forward to crysis so much and I was really pissed that it didn't run properly, so I have to buy a new card... Edit: Forgot to mention that there are also problems with the xp-driver for the GTS (vista drivers work though). The scaling does not work properly, so that I can only play in my screen's naturaly resolution, without stretching. So in the end, the GTS isn't that much of a runner...

Yeah I noticed the slim difference in the bench marks. As for the 9800 GX2, I'm apprehensive... I make it a rule never to buy bleeding edge components, best waiting around till they become mainstream and we know there's no problems with them.

Erm...I'm not sure what program you need to read .ASE files. Anyone? For most textures we'd need a diffuse and normalmap. A specular is really only needed if the surface is particularly shiny, like metal or cermamics. You should also check out this: http://forums.thedarkmod.com/index.php?act=announce&f=4&id=1

But the upshot here is that you still need an extra link, and it seems not possible to set the actual probability. Consider a path with three nodes, the second one in front of the fire place: In this case, the anim will be played *everytime* the guard reaches the node in front of the fireplace. Now consider laying an alternative routes as greebo described: Problems: * the alternative route would be a straight line between node 1 and 3, meaning the guard does not nec. pass in front of the fire place (you need another node to make him go there and continue) * the guard will choose each path 50% of the time, but what if you want him to be 70% of the time near the fireplace? That is why "path_anim" should have a "probability" spawnarg, that says "if a random number is smaller than this value (0..1), then skip playing the animation and continue". That would simplify the path setup and make it more flexible at the same time. Hope I explained that now

Before this stuff lingers another month on my harddisk, I uploaded the WIP mosaic textures to SVN. Here are some screenshots: Editor: Game: Showing missing color combinations: The map to test this is test/mosaic.map. Things missing: * bumbmap * specular * some tiles have a color cast/color variations (e.g. the trim tile is slightly darker than the center tile). It should be easy to get rid of this, because my panorama stitcher can f.i. equalize color casts. However, I have not found a way to do this for two non-overlapping images. Maybe someone knows an easy way? * some color combinations are missing (like green t-shaped trim tiles etc.) Also, more color variations could be done (like dark yellow). For the last step, I added a temp. material which uses the red central tile and a blue overlay texture to create a second blue central tile variant. If this works, it would be dead easy to make more colors without having literally dozend of TGA files. (it might even be possible to control the color directly from the editor via spawnargs, but this means you need to convert the brushes with the tiles to entities first). Problems with this technique are, however: * DR does not show the true color (only in game) * the current central tile has very very slight red cast in the mortar, and this becomes visible if you look at an angle at the texture from far away, it becomes "slightly reddish" If somebody wants to work on these tiles, I do have the 2048x2048 "source" images in XFC format (Gimps native layered format) with the various overlays to create the color variants. I can also compact these to one-layered PNGs and upload them somewhere.

I seem to remember that the advice wasn't intended for players so much as developers... no idea what the supposed problems were, other than that they supposedly had to do with D3 assuming paths were a single word (in the console?).

I'm pretty sure this is a myth. Multiple people have reported running the mod in a directory containing spaces without any problems.

You could certainly do things with the window brightness fading in/out over time and with having "shadows" move across the brightness. You'd probably just use tables to control the animation. However tables loop over time and aren't random. You can't have truly random materials without some outside source influencing their parameters (which would require the window to be on an entity). If you have a bunch of windows just applied to worldspawn, they will all animate the same way, all in-sync. There may be ways to mitigate that by having different animations for different parts of the texture space, but it could be difficult for the texture artist to set up, and would require the mapper to have each window occupy a different part of the texture space. It might also require more render passes per window, leading to performance problems. If you want to have randomly animated windows which behave independently, by far the easiest way would be to put each window on a separate entity designed to control the window, though that could quickly eat up the 4096 entity limit. (it may be possible to economize by having a single entity control up to 12 independent windows) The other challenge would be having the window controller only running when in PVS; I think my previous solution to this may be buggy on multi-core systems, but using a more conservative approach should work almost as well. It's not possible for a texture to be truly random by itself. I might have been referring to using textures to cause stars to pseudo-randomly twinkle, or to using entities to randomly control textures...

Or... If you'd rather, you could work on the Objectives gui. It's quite easy and I can give you all the relevant graphics. You'll have to import a new font though (but wait until we're sure which one). http://forums.thedarkmod.com/index.php?showtopic=3808 What's your preference?

After you have patched it to 1.3, you can apply my patch to update the functionality of the Doom e inspectors window. Just a simple fix to let you minimize it. http://forums.thedarkmod.com/index.php?showtopic=3086

1. As far as I know, this is completely independant of the current reorg in progress, and is instead based solely on the textures themselves. 2. I haven't looked at the materials or individual files to figure out for sure what is up, that comes later. For now, I'm only reporting what I see in the editor. That said, There are some textures that have various problems. If no one steps up to claim them or the right to fix, I'd like to fix them up myself. Speak up soon if you object. -foliage/wall/hedge_001 - doesn't tile (ascottk) -slate/floor/roof_002 - needs tiling fixes in one direction (ascottk) -stone/floor/brick_001 - normalmap is reversed (diffuse bricks appear to bow outward; plus if it's a floor, concrete oozing out of the cracks wouldn't work, everyone would be tripping!) -stone/floor/brick_002 - doesn't tile (ascottk) -stone/floor/brick_003 - normal map reversed (same reason as _001) (ascottk) -stone/floor/cobble_002 - normal map is very wrong.. either shifted or rotated or... (ascottk) -stone/floor/cobble_003 - normal map reversed (ascottk) -wood/ceiling/plastered_001 - no normal map -wood/floor/tile_weave_001 - no normal map Fix: provided normal map; texture didn't tile either, also fixed diffuse and specular -wood/trim/beam_001 - normal map reversed -wood/trim/molding_001 - no idea, normal map is wrong or scaled or ... Fix: none; maybe it is okay afterall (?) -wood/trim/molding_002 - normal map too shallow (but that's just an opinion) -wood/trim/molding_004 - normal map too shallow (but that's just an opinion) -wood/trim/panel_003 - wrong normal map, seems meant to use the much better one from panel_002? Fix: altered material to use other normal map -wood/wall/wallpaper_001 - might want to invert normalmap, so it's like the other wallpapers Fix: reversed normalmap -wood/wall/wallpaper_003 - no normal map Fix: supplied normalmap Edit: If I do proceed, I'll track progress in this thread. Gildoran, I could either FTP any fixes or submit them myself, whichever you prefer.

Re: "cut in half" - So you mean you want him to stop after he holds his hands up? Angling the hands, no problems. I'll try animating the fingers during the rub too.

Well, you could work with Ishtvan on the Mission Statistics gui. I posted the concept in that thread. http://forums.thedarkmod.com/index.php?showtopic=3800 It uses the same background as these main menus, but you won't really need the graphics in order to start it, right? edit: Don't you have ftp access? I think that's where drumple is posting the menus.

Yes, I already saw that bug myself. It's happening only in Linux, and it's due to the tooltip text being displayed in the lower left corner when you hit the modifier keys. The suggested fix was to make the tooltips an option for people experiencing these problems.

I’ve got few interesting questions for you people. You made a great work. You transformed, ugly, shitlooking doom3 engine in to something similar to Thief. Fine. But tell me, I’ve got PC that 3 years younger than this game (Doom 3) It is Intel Core2Duo E6300 OC to 3.0Ghz, with 1900XT and 2GB Ram. Why on this little street I see such low FPS? This street, it is not very detailed, it’s using muddy textures. And I’ve got here only 20-30 FPS? WTF? Yes I’m playing on high quality in 1280x1024 with AAx4. But look at this for example, Dark Messiah, it have much more detailed levels, much bigger and I’ve got there 60FPS with same resolution and AA, AF, 8 and higher. What? There are no dynamic shadows? Well first of all, such shadows in doom 3 looks like shit because they are sharpened, and second is that in HL2 – EP2 We have soft real shadows. So in conclusion I would like to say that idea of using such engine to resurrect or port Thief ideas was a very bad move. We have got only two possible ways. First, all of us will buy something like 8800 Sly, or we will see such ugly blocky architecture like that Because all other high poly places will simply lag. Well we have some kind of unreal way, forget about Doom3 Engine and port all work to Source engine. Once again, there is some crew, they are making a full remake of original HL so they used united lighting model, but after ep2 they imported real shadows and real lightning in game, without any problems. P.s. Guys, who make missions for Dark Mod, forget what you made under DromEd, such engine like dark mod needs new approach, more detailed. Cause same things which looked good under Dark Engine look ugly under DM. Thank you very much for your patience and sorry for my strange English. Holland btw.

I don't have any particularly clever GUI ideas right now for a Mission Stat screen. I think once upon a time we had talked about doing something similar to a pirates-style summary, complete with graphics: http://forums.thedarkmod.com/index.php?showt...=618&hl=pirates That might be a little overly ambitious now. edit: Actually, scratch that. I DO have a clever idea. I'll put a mock-up together shortly. Ish, what mission statistics do we record?

Here's the original thread that shows the comparison shots: http://forums.thedarkmod.com/index.php?showt...roadhead++arrow None of the screenshots showed the fletching of the new arrows which was why I missed them. I do like the shape of the head better, but I'm more comfortable with the size of the original arrow model. Resizing Dram's model might be the best option.