Dram

If you are referring to a crack or a so-called "no-cd patch" then that is something we cannot help you with. Don't take it personally btw, it is just that we do not want TDM to be closed down because of cracks and warez, as it were. I'm sure you understand

Couldn't agree more. I just loved the steampunk architecture in T2, as well as the robots etc

I did partially. I have done some rigging on the thug model, though I've been slowed down totally from doing anything atm due to getting my portfolio to a presentable state. I should have the portfolio done soon (within half a week) and will finally get back to Dark Mod stuff. Sorry I didn't let you know earlier, but the reason I put the rigging on the back burner was because I had to get more level editing done for the portfolio, that and also I slightly lost motivation rigging when I got both legs and hips done and 3DS Max crashed...and I forgot to save. Now I still have the feet and lower legs done. Again, sorry Spring, I should have let you know sooner, I was just quite side-tracked.

Well I know that of course. I mentioned right from the start that it has to be changed.

Hmm, well currently Blackheart Manor uses 2 horses in the stables. I could theoretically remove them of course...but they are oh so fun to ride....

Nice Speaking of which, I assume the walk animation I did for the previous horse is unusable here as the bone hierarchy is completely different correct?

That is....not right. I remember reading an article on global warming talking about climate change, where it is not forecast to just be hotter generally, but rather very large changes in weather patterns, as we are seeing in AU atm, where it'll be 42C one day, and 16 the next. I can only imagine what Sydney drivers would do if the temperature plummeted to below zero in winter...There are no winter tires in AU (save Snowy Mountains), so there would be a very large problem. Hell, if it snows in Prague unexpectedly then half the drivers still have summer tires, which have no grip on snow or ice.

That is a good work-around yes, but the functionality should really use the same type of surfaces that mantling allows, except that you would (for example) press mantle and hold down (backwards) so that the thief only catches onto the ledge but does not climb up. It would not be a difficult feature to add, but it is the testing time that is the problem.

Looking at the suggestions objectively, I think shimmying across ledges would be a great addon, and could lead to some very interesting levels. If our thief can pull himself up onto a ledge (which is not exactly a trivial task in reality), then theoretically he should be able to hold himself hanging there for a while at least. Of course, the main issue here is not that it would be a great idea etc, but would mean yet another feature to be on the playtest/bugfix list, and it's a long one. NH is not trying to sound arrogant, he is simply tired of having to respond to similar suggestions (for example a while back we had talk of adding silent footsteps), but mainly he considers the amount of time that would have to be invested into such a feature and thus gets annoyed. At least from what I see. In any case, I personally agree that wall-jumping has not place in Thief, as the thief was never shown as an agile little weasel but rather an average man who is neither built nor skinny. The ledge-shimmying is an excellent idea though, one that would be awesome to see in TDM, but I think it will have to wait till post-V1.0. Please don't take offense to annoyed-sounding responses as we have been working on the mod for a good four years now and have already locked-down feature additions long ago so that we may release it soon.

That is VERY strange for AU. Mildly worrying really where the climate is heading.

One technique you can use to reduce the pathfinding complexity is to fill emtpy space where AI cannot reach (such as in the air) with brushes textured with textures/common/monsterclip. This will mean that no AAS data will be generated for those areas and thus lowers build time, and prevents reaching the maximum reachabilities which gives you that area. You can also cut the areas with visportals.

Enjoyable as always I tend to agree with him though, his reviews are quite spot on mostly.

Well that's a good thing for me then (I guess only for me) because I love cold weather. A couple weeks back was playing ice hockey in Bruntal with -15C temperatures hehe, suffice to say, you had to keep moving to keep warm.

Voted. Fingers crossed

Ahh I see. I did a search for max_entit but found nothing, and also did a search for 4096, I guess now I see why I did not find it.

But I could not find max entities. I don't think there really is an entity limit per se, but rather a limit on the maximum events, which in turn effectively means maximum entities. Unless there is a value I did not find in our source In any case, I clearly remember reaching 4090 or so entities and not being able to load the map due to reaching more then max events.

Very noble Crisp I'm here in CZ with 20cm of snow atm, so I missed all the fires and the heat...for now...flying back to Sydney on the 16th...gah

Thanks It has actually significantly expanded since that vid, and has also improved. The map will be released with TDM v1.0. I have to say, the only bothersome thing about creating a map is that you know where everything is.

I have used UnrealdED 1 (for Unreal 1), UnrealEd 2, 3, Hammer, Warcraft 3 Ed, TDS Ed (for a -very- short period of time) and of course Doom 3 Ed (and then Dark Radiant which is specific to TDM). Out of all of them I would say by far Doom 3 Ed/Dark Radiant (very similar, but Dark Radiant has more features) are the best. Much, MUCH less buggy then the others and bsp holes are incredibly rare and are usually caused by an excessive amount of miniature brush work which is not grid aligned, thus the mapper's fault really. Several times I've dumped a map in UEd 1 because of an un-fixable bsp hole. In D3Ed even the worst hole is fixable, as you can just remove the evil brush and create a new one, or fix it by grid aligning it. My last bsp hole was back in 2006 when I used to make everything from brushes. I fixed it at the time and since then not a single hole (yay!). Sorry, went on a bit of a tangent there... The other main reason why creating a mission in TDM is a good idea is because D3 goes open-source after the release of idTech 5, and means that the renderer can be updated for D3 etc, thus having a modern-standard true-to-thief game. That, and the entity limit in D3 is default 4096, but we've bumped that up to 8192, and can increase it further easily. Yes, it has happened that we've reached the entity limit of 4096 so had to bump it up

I thought that would be the position taken. Fair enough, well at least the option of on or off is available.

Excellent work on the menus Just one thing that could use adding - bloom settings. If you get time to add them, here are all the settings copy/pasted directly from SysCVar.cpp: idCVar r_bloom( "r_bloom", "0", CVAR_GAME | CVAR_BOOL | CVAR_ARCHIVE, "Enable Bloom Post-Process Effects (requires DX9 Compliant Hardware)" ); idCVar r_bloom_blur_mult( "r_bloom_blur_mult", "0.5", CVAR_GAME | CVAR_FLOAT | CVAR_ARCHIVE, "Blurred image multiplier for bloom"); idCVar r_bloom_src_mult( "r_bloom_src_mult", "1.0", CVAR_GAME | CVAR_FLOAT, "Source image multiplier for bloom"); idCVar r_bloom_buffer( "r_bloom_buffer", "4", CVAR_GAME | CVAR_INTEGER | CVAR_ARCHIVE, "Bloom buffer image size: \n1 = 64x32\n2 = 128x64\n3 = 256x128\n4 = 512x256\n5 = 1024x512\n6 = 2048x1024"); // New by Clone JCD idCVar r_bloom_contrast_mult( "r_bloom_contrast_mult", "1.55", CVAR_GAME | CVAR_FLOAT | CVAR_ARCHIVE, "Contrast multiplier"); idCVar r_bloom_contrast_min( "r_bloom_contrast_min", "0.1", CVAR_GAME | CVAR_FLOAT | CVAR_ARCHIVE, "This is the minimum contrast value when (shift sensitivity based)bloom drops \nWhen shift sensitivty is turned on bloom contrast varies from (constrast_image x r_bloom_contrast_min) to (constrast_image x r_bloom_contrast_mult)"); idCVar r_bloom_shift_delay( "r_bloom_shift_delay", "0", CVAR_GAME | CVAR_INTEGER | CVAR_ARCHIVE, "Delay in millisecs for shifting the bloom sensitivity \n0 = No shift sensitivity delay, sensitvity shifts immediately. \n-1 = Disables sensitivity shifting"); // New by Clone JCD idCVar r_bloom_blurIterations( "r_bloom_blurIterations", "1", CVAR_GAME | CVAR_INTEGER, "Blur iterations for bloom"); // New by Clone JCD idCVar r_bloom_hud( "r_bloom_hud", "0", CVAR_GAME | CVAR_BOOL | CVAR_ARCHIVE, "Enable blooming of the HUD" ); idCVar r_bloom_lightRayScale( "r_bloom_lightRayScale", "1.3", CVAR_GAME | CVAR_FLOAT | CVAR_ARCHIVE, "Brightness scale of light ray effects when bloom is active"); The only important ones are: r_bloom r_bloom_blur_mult r_bloom_buffer r_bloom_contrast_mult r_bloom_contrast_min r_bloom_shift_delay r_bloom_lightRayScale If everyone feels it is not necessary to have bloom setting then fair enough, they can be configured individually through the console, but IMO it is better to have everything in the main menu.

Congratulations Crisp Unfortunately, being in CZ I didn't get to provide feedback with the betas. It's good to see you've managed to finish it I hope it was a worthwhile investment! Good luck

Ok, well I'm downloading the SVN model_src directory now and intend to make a start on this within the next few days. I was reading through the forums however and saw mention of problems with the new skeleton? Has this been resolved? Just confirming so I do not have to do this twice. As for what I've been doing till now - mapping

Happy Holidays everyone! Greetings from Czech Republic

The easiest solution in this case would be to have the AI get alerted from "floating" objects.