Tirek

There is something so delightfully odd about this problem and its "solution" makes for a hilarious mental image. TDM universe's own version of quantum entanglement phenomena... spooky action at a distance, indeed. Anyway, thank you. I'm glad to have been of some help.

I won't pretend to understand the code, as I have only minor experience with programming and certainly none with TDM codebase, or even C++ in general. I'm not even sure that I understand your explanation; are you saying that collisions between objects elsewhere in the level can somehow cause the player to drop currently held objects? If so, does this happen only when the collisions involve specific combinations of entities? If that is the case, then I suppose I might have just been unlucky. I can't remember doing anything unusual in the level, except that I vaguely remember getting stuck on a piece of geometry and having to use noclip to free myself. A pertinent question now is whether I can be of any further help, as well as whether I'm likely to keep encountering this bug in the future.

It seems your suspicion was correct - starting a new game fixes the issue. The savegame file is too large to be uploaded to the forum, so here's a link to google drive: https://drive.google.com/file/d/1uK81votGdXCbYjJRu6rqUWtyCAtGu-6i/view?usp=sharing

Thanks for taking the time to look into this. I'm not sure how much help a video would be... Even while playing, it took me while to recognise the nature of the issue. At first I even had a notion that it might be an intended mission-specific limitation. Here's a description of what happens, assuming I have a weapon equipped (say, the blackjack): I click my right mouse button while the object (say, a chair) is within frobbing distance and highlighted. The object is grabbed (the blackjack lowers) for a very short duration of time that varies between barely perceptible and just enough to slightly move the object. Half a second at most. After the aforementioned short duration of time, the object is dropped and (the blackjack reappears). I've attached the files you requested. The condump was generated immediately after loading the quicksave, attempting (and failing) to lift the chair and getting the coordinates. I've also tried toggling the "Uncap FPS" option, with no apparent effect on the issue. condump_CoO_bug.txt Darkmod.cfg

Strangely, no. Recently (in 2.07) I've played Snowed Inn, WS4 and WS5, Perilous Refuge and PD3. I didn't encounter this issue in any of those.

Hi, I've recently (with 2.07) got back into playing TDM and have been enjoying it immensely. That said, I'm having a strange issue in the Crucible of Omens campaign mission that I don't remember ever encountering in any other FM: I'm having trouble picking objects up and manipulating them; it's fairly erratic, but it seems as if most of the time they get dropped immediately after being frobbed, which makes it impossible to reposition/manipulate them. This has gameplay implications as well, since it makes it impossible to snuff out candles. I've been searching all over the forum for any other mention of this issue, but found nothing, other than a fairly old thread where someone suggested using a modified "de-clunking" build. I meant to link it here, but curiously, I haven't been able to find the topic again. Looking forward to any suggestions. The mission is extremely well made otherwise and I would hate to have it spoiled by this bug. Cheers!

I got rid of the source directory and cloned again now (same repo). It still won't build, but the error is different. In file included from ui/modelselector/ModelSelector.cpp:2:0: ui/modelselector/ModelPopulator.h: In member function ‘virtual void* ui::ModelPopulator::Entry()’: ui/modelselector/ModelPopulator.h:87:26: error: ‘GlobalFileSystem’ was not declared in this scope GlobalFileSystem().forEachFile(MODELS_FOLDER, ^ Makefile:3692: recipe for target 'ui/modelselector/darkradiant-ModelSelector.o' failed make[2]: *** [ui/modelselector/darkradiant-ModelSelector.o] Error 1 make[2]: Leaving directory '/home/tadejr/devel/darkradiant/DarkRadiant/radiant' Makefile:742: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/tadejr/devel/darkradiant/DarkRadiant' Makefile:482: recipe for target 'all' failed make: *** [all] Error 2 make_log_2.txt

Sorry for the delay; I'm building the one specified on the sourceforge page and in the wiki (https://github.com/codereader/).

Hey, yeah, the details are forthcoming, I just didn't want to clutter up the topic with the details immediately. The distro is Ubuntu 14.10 I've attached the autotools configure log and the make output. Here's the bit that seems to be problematic, on a cursory glance: CXX map/darkradiant-RootNode.o In file included from map/RootNode.cpp:1:0: map/RootNode.h:33:5: error: ‘ITargetManagerPtr’ does not name a type ITargetManagerPtr _targetManager; ^ map/RootNode.cpp: In constructor ‘map::RootNode::RootNode(const string&)’: map/RootNode.cpp:20:5: error: ‘_targetManager’ was not declared in this scope _targetManager = GlobalEntityCreator().createTargetManager(); ^ map/RootNode.cpp:20:42: error: ‘GlobalEntityCreator’ was not declared in this scope _targetManager = GlobalEntityCreator().createTargetManager(); ^ map/RootNode.cpp: In member function ‘virtual ITargetManager& map::RootNode::getTargetManager()’: map/RootNode.cpp:44:13: error: ‘_targetManager’ was not declared in this scope return *_targetManager; ^ map/RootNode.cpp:45:1: error: control reaches end of non-void function [-Werror=return-type] } ^ cc1plus: some warnings being treated as errors Makefile:4938: recipe for target 'map/darkradiant-RootNode.o' failed make[2]: *** [map/darkradiant-RootNode.o] Error 1 make[2]: Leaving directory '/home/tadejr/devel/darkradiant/DarkRadiant/radiant' Makefile:742: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/tadejr/devel/darkradiant/DarkRadiant' Makefile:482: recipe for target 'all' failed make: *** [all] Error 2 configure_log.txt make_log.txt

I'm having trouble compiling the current DR sources from github on linux... I'm not sure if this is the right topic to bring that up though, since this is about the binary builds, as I understand? Should I post in MirceaKitsune's topic (about trouble with building in OpenSUSE), perhaps?

Oh? I'm sorry, seeing that you haven't read my PM yet, I just assumed you were inundated with messages. Somehow I managed to completely miss the additional forum appearing in the forums list, although it's true that I have the individual forums bookmarked, so I don't see the overview too often. Great, I'll check out the forum, although it likely won't be until the day after tomorrow that I'll actually be able to take a look at the build, I'm on my laptop now and it's got old intel integrated graphics. Thanks, and sorry for being such a dolt, hah.

Just an update regarding TDM on Linux; while I haven't yet heard back from Springheel, I've been playing around with 2.02 in the meantime. Using a 32-bit version of linux in a VM, you can use the "ldd" utility to see what the required dependencies are - this is a command-line command/application that tells you which libraries the executable (which you specify as a parameter to ldd) links to. Once you've found out the names of the required libraries, you can use the "apt-file" utility to see which packages contain these libraries (some often-used libraries are found in many different packages, so you tend to end up with far fewer required packages than there are actual libraries required). Note that "apt-file" is not installed by default in *buntus, you'll have to get it first. Once you have the list of required packages, you can then use any package manager that allows you to specify alternative architectures (using the "libexamplepackage:archname" approach) to download the 32-bit versions of those libraries. Then your application should work, in our case these are "tdm_updater.linux" and "thedarkmod.x86". I realize what I've just written may be intimidating for a complete newbie to linux, so when I'm near my gaming machine again, I can write step by step instructions, if y'all want it. Anyway- I did this experiment using a freshly installed 64-bit Ubuntu MATE 14.10 and a freshly installed 32-bit Xubuntu 14.04, because I happened to have the ISOs lying around. There may be caveats I haven't foreseen, and certainly these instructions only apply to Debian-based systems which use apt-get and support the MultiArch capability (that's what allows the :i386 suffix to work). Also, resident linux-gurus: you are encouraged to call bull**** on what I've written, if you feel it's the wrong approach, I can't really consider myself a Linux authority of any kind.

Okay, I just did that. As for the 64-bit build: are there any plans for its inclusion in the 2.03 cycle? The 32-bit compatibility libraries have become quite a problem for Ubuntu users; as you might know, the libs have been deprecated in the last year or so and removed from the repositories. Unless something has changed since my last attempt, there is currently no simple way of getting them, which might alienate/discourage some linux users- it did discourage me enough that I decided to just install TDM on Win7 in the end. Now, whether this whole thing is a genuine obstacle or just an annoyance depends on how technical the user is, of course... Personally, I admit that I could have put in more effort that last time, but I had some other stuff going on so I just gave up This time I'm willing to do this more thoroughly, of course.

Hello, all. I would be willing to test the build on a linux box. I run Ubuntu 14.10, the specs are as follows: Core2Duo E6400 (full disclosure- it is overclocked ever so slightly from 2.13 GHz to 2.35 GHz, without raised voltage, so there's that) 4 GB RAM MSI Radeon R5770 1 GB HDD is a 7200rpm spinner from WD As far as the driver situation goes, I'm currently running the open source radeon driver; since the card is getting old, the performance might not be all that great, so I'll try to find the time to test the proprietary drivers as well. As far as the scope of the testing I'll be able to do- my employment situation is such that I'm rarely able to predict the volume of work, so I'd rather not promise thorough gameplay testing; what I'm mostly interested in is basically to see in what shape the linux build is. I never actually managed to get the 2.02 running on my previous 14.04 system, because I couldn't get the 32-bit compatibility libraries - are there any changes in this respect? Are there plans to make a statically linked build perhaps? I would love for people to be able to at least run TDM on Linux, and I'm willing to put some effort in, although time is probably going to be the limiting factor here. Basically, I wouldn't mind giving it a try, but given that I really can't promise anything, I would also understand if you'd prefer to keep the number of testers on a more manageable level.

Let me just add my own thanks for this monumental undertaking.

The story is full of intrigue and mystery and the characters really come to life. The visuals and sound design of the mission are in my opinion the best of any TDM mission yet. The place feels organic and lived in, which I believe is especially due to the fantastic attention to detail - even the little, out-of-the-way things are all carefully designed and make sense in the context. My playthrough was almost six hours of game time- NOT including reloads. I've done a lot of backtracking, not because I had to, but because I was so immersed in the setting that it just didn't seem like a chore. Archetypal Thief-style gameplay and a benchmark of TDM missions.

Yes, that is the expected behaviour of GTK. It's meant to replace the "forward" button.

If I may add my 2 cents; IMHO, given the focus of TDM as a toolkit, to be used mostly by a community of unpaid fans, I think the most worthwhile improvements (apart from the obvious performance tweaks that access to the renderer enables) would have to be those that make life easier for the mappers and asset creators and that increase the flexibility of the engine... To explain a bit better: I think it would make sense to aspire towards "streamlining" the mapping process, in the sense that there are as few technological obstacles between the ideas and concepts that the mapper starts with and the realization of the same in the engine. For instance, visibility determination that relies completely on mapper-placed portals requires a considerable amount of time to be spent on optimizing a map and even so, the mapper is still restricted to making fairly "boxed up" areas. Also, hard limits regarding brush and entity counts, "leaking" maps... These are the sort of obstacles I had in mind. Unfortunately, most of them seem to stem from the basic approach the engine uses to represent level geometry, AFAIK. In any case, such wide ranging changes are hard to implement. I'd guess harder than, say, adding SSAO, or even replacing stencil shadows with shadow mapping and such. Synchronizing various community efforts will probably prove to be the hardest part :/ I doubt TDM team actually has the manpower to manage it's own fork of idTech4.

Well. I would presume 328 MB for a single savegame file could be classed as "ridiculously large" Also, the latest crash produced a log in the console... Says "malloc failure at <number>". I would just append the log here, but my gaming machine isn't connected to either the LAN or the internet currently. I saved the log to a file though, so I can still get it if it's gonna be useful.

Would anyone mind if I add my problem with this FM here? It's probably a different issue (I haven't had the crash due to the pillars yet and my gfx is nvidia), but it results in a crash as well. Everything worked without problems until Since that point, saving and loading started takes much longer than before and occasionaly, the game will CTD upon loading. After getting thrown to desktop, looking at task manager shows Doom3.exe still using up to a gig and more of ram for at least a minute or so (at that point I became impatient and ended the process manually). I'd also be glad to supply additional information, if possible and necessary.

I had this exact problem; in my case it was along with the perspective view being unbearably slow and unresponsive. I can confirm that setting the affinity to a single CPU core seems to have fixed the problem completely. There was no need to turn off Aero (which is great, because Windows 7 is much less useful with it off) my specs: Core 2 Duo E6400, 2.13 GHz 2GB of RAM Geforce 7900GTO 512MB running Windows 7 Ultimate 64-bit

- Operating System Windows 7 Ultimate 64-bit- CPU Core 2 Duo E6400, running at stock speed which is 2.13 GHz I think- System RAM 2 GB- Video Card geforce 7900GTO 512 MB- Video Drivers (if that info is available) 190.62Experienced Performance, Steps you had to perform to get it running or problematic driver versions, etc. Settings: 1024x768, no AA, 16x anisotropic, all details on high, bloom on. Didn't get around to measuring the framerate yet, but it's been good enough to never present an annoyance. Haven't yet noticed any particular problems. Subjective impression is that being underwater probably FPS drops somewhat, but not enough to bother me. Elsewhere it's generally very smooth.

It's very satisfying. I also like how loud ambient sounds make it harder in such a natural, immersive way. Mad props then. If it were any better, people would just want to fight all the time

Since there is no official feedback thread yet, I'm posting in this topic. I hope that's okay with OP. I've now played through most of the training mission. Didn't quite finish the sneaking part yet... Got busted after not quicksaving for a while, mostly because I was too busy being blown away by everything. My intention was to provide some constructive criticism righty away, but it seems this will have to wait, because the annoyances were apparently minor enough to be completely overwhelmed by just how slick this thing is. Off the top of my head - the lockpicking is fantastic, IMO. It really seems to capture the fiddly, attention-demanding nature of the task while not being too frustrating (lockpicking difficulty currently set to average). I liked how I found myself completely immersed in it, eyes half closed and all. Thumbs up. I initially feared combat might be awkward, but my doubts were put to rest after a couple of fights. It's hard, but when I got the hang of it, I started really enjoying it. Maybe too much... I actually find it fun enough that I don't even mind getting killed in the arena, which is most of the time. When I managed to string several attacks/blocks/counter-attacks together for the first time, I felt a genuine thrill of accomplishment. I think I'll keep the parrying system on "auto" for now, though

Seconded - TDM is a remarkable success. Such a massive TC actually making it doesn't happen often, from what I've seen. The release caught me totally off guard; I knew it was supposed to come out sometime in the next month, but was trying not to hold my breath too much (nerves, you know). Sometime today I visited the site, just as I have done many times previously, and I just sort of stared at it for while. Didn't quite get it at first. Well yeah, thank you. That's what I was trying to get across The installer/updater program is shuffling bits around ever so stoically as I type.. *glee*