Jump to content
The Dark Mod Forums

Tirek

Member
  • Posts

    29
  • Joined

  • Last visited

  • Days Won

    1

Tirek last won the day on October 27 2012

Tirek had the most liked content!

Reputation

5 Neutral

Profile Information

  • Gender
    Male

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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
  4. 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
  5. 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.
  6. 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!
  7. 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
  8. Sorry for the delay; I'm building the one specified on the sourceforge page and in the wiki (https://github.com/codereader/).
  9. 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
  10. 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?
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. Let me just add my own thanks for this monumental undertaking.
×
×
  • Create New...