Jump to content
The Dark Mod Forums


Development Role
  • Content Count

  • Joined

  • Days Won


NightStalker last won the day on January 14 2017

NightStalker had the most liked content!

Community Reputation

67 Excellent

About NightStalker

  • Rank
    Linux hero

Profile Information

  • Gender

Recent Profile Visitors

318 profile views
  1. This reminded me about the time when I first got involved with TDM (Dec 2016), in the era of TDM 2.04/2.05-beta, building under Linux natively (i.e. no VM). It should be noted that the incredibly annoying issue with SCons rebuilding everything all the time was easily fixed with essentially a 1-line tweak. Reading my notes from back then, I see that when building "from scratch", use of PCH nicely lowered the build time (from 16m39s without PCH to 9m01s with PCH), but only for the 1st build. Subsequent builds' speed improvement with PCH would obviously depend somewhat on what changed
  2. I don't generally like jumping into the middle of a conversation when someone is already being assisted, but I fear that things might be going astray here. Freyk, IIUC, all 'fraten' wants to do is install a desktop icon. It sounds like the game itself is already installed correctly... it's just lacking a "launch" icon. Is that the case, fraten? That is, can you run the game from a command prompt? If you don't know, please check that first. Also, I don't use Ubuntu (I'm a Slackware user) and I don't use desktop icons, but I suspect that you could find plenty of information online in a ge
  3. Correct. (That's the latest version, which comes with TDM 2.07, for those unaware.)
  4. One reason is to avoid having it overwrite the one you built (i.e. from source code) with changes of your own. I find that it's often a different mindset between Linux users and Windows users, but I (being a full-time Linux user) don't like the fact that any executable I run decides to "self-update" and run itself again. It makes it maddening to debug sometimes. At least the authors had the forethought to include the "--noselfupdate" option.
  5. Many thanks for that file list, stgatilov! That's all I really needed, since (with the single exception of that 'tdm_shared_stuff.zip' file) I'm intimately familiar with the TDM installation fileset, having spent countless hours with it during the run-up to the 2.05 release. But, for the benefit of any others and for future reference, I'm glad you thoroughly documented it. I confirmed that your file list exactly matches what the 'dry run' of the TDM updater showed. Also, there actually is one mirror (http://mirror.helium.in-berlin.de/thedarkmod/release) whose content is view-able. That's
  6. Thanks for the link, freyk. I read it, but it's the same technique that Durandall already suggested in that same thread that I linked to in post #5 of this thread. And, as I mentioned in my reply to his/her post, that method yields a less-than-pure installation. It's a work-able alternative, but it's cleaner to use the "interrupt the updater" technique suggested by nbohr1more and implemented by me (required code can be found in that same linked post). I'd like to have stgatilov's list(s) to confirm that his 2.07 "requisite file list" matches what I'm seeing the (hacked) updater try to dow
  7. Many thanks for the info! I'd love to see a list of the files to download to make a complete 2.07 install. But even more than that, I'd like to know how you create such a list (more on that below). Occasionally, for debugging, I find it useful to have run-able, pure, older TDM versions. So I'd also like to see such a file list for 2.04 - 2.06, although I suspect that it may not be possible or might be impractical if said files no longer exist (i.e. packaged with release-specific, older content, for ready-made download). Using a crude hack, I've already managed to create "virgin" installat
  8. Fortunately, the details in that bug report mentioned in that code snippet have shed more light on the problem. After reading it, I realized that there may be some sense in actually (counter-intuitively, I'd argue) running TDM (the game) after the 1st (failed) run of the TDM updater (where it went from 2.00 -> 2.06 instead of 2.07). So I tried that and saw evidence that the game was "Repacking" various PK4 files (presumably the ones containing ROQ/OGG/AVI files). Then I re-ran the same updater process with the same options. It acted differently this time, (needlessly?) downloading all 3
  9. The log file from the 2nd run of the updater: tdm_update--run-2.log.txt
  10. There's some sort of problem with the TDM updater whereby it won't create a proper 2.07 installation. Being on a slow Internet connection, my TDM installation/update procedure has always involved downloading just the latest update zip file (currently, 'tdm_update_2.06_to_2.07.zip') from the ModDB site and making that available to the updater locally, to avoid unreliable, slow downloads during the actual update. I followed the same procedure that I've always (successfully) done in the past: extract the huge, 2.3-GB 'THEDARKMODVersion2.0-StandaloneRelease.zip' file (downloaded once from ModDB
  11. I agree with 'gnartsch'. I don't think there's any need to try to fix anything in this regard. The packager app had the bug originally. Unfortunately, it went undetected and a "band-aid" fix (which itself had a flaw) was applied to the updater app. Shortly after I became involved with TDM, I eventually found and fixed both flaws (back in late Dec 2016). IMHO, now that we've been through 2 TDM releases with the fixes in place and no reports of problems, we should be able to remove (at any convenient time) the entire "band-aid" (i.e. the entire block of code that does anything to the times
  12. I explained in a general way in the 1st post of this thread: Refreshing my memory by re-reading my notes on this from Dec 2016, I'll point you to the 'R_ParseImageProgram_r()' routine in the 'renderer/Image_program.cpp' file. Beyond that, I'll leave it to the author of that code to explain.
  13. Apologies for not "closing the loop" on this. Only recently did I finally get back to re-visiting this issue. I wound up simply hacking the 'tdm_update' C++ code to crudely inject a large, obvious console message and a 10-second delay at the end of each version's update. This allowed me to simply monitor the installation and break out at the appropriate time. Very ugly, but it sufficed. Here's the actual code, injected at the end of the 'Updater::PerformDifferentialUpdateStep()' routine in the 'tdm_update/libtdm_update/Updater/Updater.cpp' file: Thanks again for all the suggestions.
  14. Although that file that you referenced which comes with the source code ('COMPILING.txt' is the actual name) is pretty useless (IMHO), it does give the link to the Wiki "Compilation Guide" for TDM. Although that Wiki page certainly could use some attention, it does show one variant of a "scons" command. But, frankly, it's buried in the noise and easy to miss. I'm not a huge fan of wikis, especially for something as important as publishing a project's building instructions. Good that you've found the 'linuxBuild.sh' script. After my first few compiles of TDM, I've never used that script.
  15. I think many of your questions are best answered by someone else, so I hope others will comment here. I can only speak for the Linux build. I've never compiled TDM under Windows (or Mac OSX). And I have no experience with Continuous Integration (CI) systems. (In fact, your use of the acronym sent me searching to understand it! ) So, heeding the words of Mark Twain, I will keep my mouth shut and let everyone think I'm a fool rather than open my mouth and remove all doubt. I will say that the various disorganized build instructions are undoubtedly somewhat obsolete, misleading, and incomp
  • Create New...