NightStalker

From a fellow Linux guy (Slackware, in my case), greetings and welcome to the forums, GreyGhost! First, a friendly (but strong ) suggestion... When you have a large block of text (like that console output), please wrap the "Spoiler" tag around it when composing your post so that it doesn't require people to page through so much volume when perusing a thread. In fact, I'd go so far as to suggest going back and editing those earlier posts to do so. There may be multiple problems here and I'm no expert on video issues, but let's slowly tackle things one-by-one.... First, it might be wise to verify the integrity of your 'tdm_gui01.pk4' file with this: zip -T [path/]tdm_gui01.pk4Assuming that's not (part of) the problem, let's address your video RAM issue: I don't own any AMD/ATI video cards, so I've never had to do anything about it because my old nVidia video card's RAM (256MB) is correctly determined: But, as you can see, in your case, it looks like it's defaulting to a mere 64 MB of video RAM when you have 2048 MB. So you should address that with a setting as suggested in the console output before going too much further in the debugging. I know that you made some VRAM-related settings in your debugging, but not knowing exactly where that advice came from and not personally knowing anything about those settings, I can't offer much more than to say, "Keep trying things until you see that 2048 MB is reported correctly in the console output." Others here more experienced in those settings will hopefully jump in with advice. Also, given that both of your displays are 1920x1080 pixels, I cannot quite understand how setting this would ever be useful: But again, maybe those with more experience in use of those settings will jump in here. If you have the 32-bit S3TC libraries properly installed, it strikes me as odd that you're seeing this: I see (and I'd expect you to see) this: But you're running TDM in a 64-bit environment with 32-bit compatibility and I (generally) run TDM in a pure 32-bit (Slackware 14.2) environment, so that may be contributing to the problem. BTW, what video card driver is installed? I know nothing about ATI Linux drivers, so I cannot be much help there, but it would be good for people reading this to know. Can you run 'glxgears'? What does 'glxinfo' say? Please copy 'n' paste the 'glxinfo' output into a "Spoiler" section here if you can. It might help. Try to address as many of these issues and questions as you can. Come back with any questions, please. I'm not an expert on a lot of this stuff, but I think the collective experience here can get you going on this, eventually. Keeping my fingers crossed...

Not a problem whatsoever. You're pushing the boundaries (a good thing to be doing) and you're bound to run into legitimate issues along with a healthy measure of confusion and silly mistakes along the way! Don't ask me how I know this. So don't hesitate to post again if you run into something that's befuddling. Glad to hear you've gotten things fixed up!

Glad to see you back, Crinkelite! A minor point to be sure, but please be careful with the terminology. I know that you're compiling a 32-bit TDM under a 64-bit OS but I want to clearly distinguish that case from the very different case of compiling a 64-bit TDM, which is what your subject line had me assuming initially. As for the 1st problem... This is a very wise choice, IMHO. I've taken a similar (more extensive, in fact) approach, with positive results. As for the 2nd error log you posted, which "lean" key are you referring to? Left? Right? Forward? All 3? Is this happening consistently, literally every time you lean (left, right, forward)? Is it happening on "The Outpost" (per your log) only or on other missions too? Looking over my old notes, running one of the late-December-era TDM 2.05 beta releases but under a 32-bit OS, I've encountered a failed 'assert' in the 'idCollisionModelManagerLocal::Rotation180()' routine (coincidentally?) on "The Outpost" when I was trying to move an ordinary bottle to get to the golden (loot) bottle behind it on a shelf in the kitchen. But I could not duplicate the crash on subsequent tests. That's the closest thing to your problem I've encountered. I have no expertise whatsoever with the 'collision model' code, so I think you may just have to dig into that 'assert' failure and work backwards, unless someone else has good advice. Wish I had more to suggest and/or more time to experiment...

That's odd. That mirror seems alive but if it's acting up, maybe it is time for you to disable it in 'tdm_mirrors.txt' and run the updater with the '--keep-mirrors' option.

Your log appears to have been cut off. Did you include the whole log? Are you running out of space on your drive? Frankly, I don't see anything obviously wrong in the portion of the log that you included. Look at this line in the log: Updates are available. 66 files need to be downloaded (size: 2.86 GB).Are you giving the 'tdm_update.linux' app adequate time to download all that? Also, if you include any more lengthy log files, please upload them to the TDM forum, then attach them to your post, as opposed to including them "inline".

Welcome to the forums! First, are you installing "from scratch" or updating an existing installation? Next, to properly help you, we need to be sure which updater you're running. Is it 'tdm_update.linux'? If so, some general advice first... Anytime there's an issue running 'tdm_update.{exe,linux}' it's incredibly useful to TDM folks to see your 'tdm_update.log' file. As a bare minimum, that will tell us which version of the updater you're running (0.66 being the latest, BTW). Having said that, some additional suggestions... Try running 'tdm_update.linux --help' to see additional options. (But be aware that the '--dry-run' option is not actually supported, so don't try it!) To answer your specific questions, yes, while you can technically specify mirrors by editing the 'tdm_mirrors.txt' file, the 'tdm_update' app can/will override it unless you specify '--keep-mirrors'. But there really should be no need to manually specify mirrors, so I'd advise avoiding that for now. And, yes, you can go directly to a mirror to get what you need (e.g. 1 or more 'tdm_update_2.0*_to_2.0*.zip' files), but if you do that, you'll probably want to specify the '--keep-update-packages' option to prevent the updater from erasing those (often very large) files when it's done, in case it takes a few tries to get things working, for example. Good luck! But if that advice doesn't help, please let us know and we'll go to the next step.

I'm surprised (and a bit dismayed) that nobody has replied to you about this issue by now and acknowledged your discovery as a legitimate bug. It's actually just a simple mis-application of a specification within an entity in the map, easily fixable. BTW, good catch and thank you for bringing this bug to the TDM team's attention. (I never "shouldered" that commoner's body, so I never noticed the wrong name during beta-release play-testing of "A New Job". In the future, I will be more careful to pay attention to this when play-testing people's maps.)

Great minds think (and work) alike?

That's why they call me "NightStalker".

That is correct. I used the chalice from the wardrobe cabinet to dislodge it. I haven't used chakkman's savegame file, but I'm 98% sure that I now know what's happening here.

0.66

My post was substantially in response to having seen someone requesting Spanish language support in the Steam comments and the fact that TDM already supports Spanish (the 3rd most spoken language in the world) but wasn't advertising it on the Steam page. Of course it would be more interesting to know from which countries TDM players originate. But lacking that information, the Wikipedia article is the best alternative I know of to support my contention, especially considering the ratio of "information imparted : time spent gathering it".

In the Steam comments, I noticed someone asking for Spanish language support, which is not currently listed on the Steam page for TDM. Given the popularity of world languages per this Wikipedia article and assuming it's possible to edit the Steam page, I humbly suggest that we add the (already supported) languages Spanish and Italian if it's not too much of a pain. If only a limited number of languages can be listed, then I suggest replacing Dutch and Polish, again based on that Wikipedia article. I also took a look on the TDM main website and in the wiki FAQ page and see no mention of supported languages. I think that should be remedied at some point, at least in the wiki FAQ. I volunteer to update the FAQ.

It's not just you. I challenge everyone to compare the readability of the top (unselected) line to the bottom (selected) line in this typical mission "purchases" screen: It gets even worse when you're trying to select the screen resolution in the video configuration menu and the current resolution happens to be something other than your LCD monitor's native resolution. White text on a tan background is just a horrible choice.

Thanks for uploading the file, NeonsStyle. My hypothesis is busted, FWIW. But I see the problem. It's not line 400, it's line 440. And line 440 has a single quote character with no terminator, which is what's causing that message from the parser. It looks like you've got an un-prefixed comment block at the end of the file.

I have a reasonably strong suspicion about what's causing this. Can you please attach that 'mainmenu_custom_defs.gui' file here so that I can confirm or reject my hypothesis? Be sure to upload it and attach it as a file, though. Do not post it inline.

Confirmed. Lastest git code is building nicely now with no need for a hacked 'LINGUAS' file. Thank you.

Not a problem. But, just out of curiosity, have you done any successful compiles recently from scratch, i.e. pulling the git tree in a fresh directory and running 'autogen.sh && configure --enable-darkmod-plugins && make'. Or, failing that, maybe just running 'make distclean && make' on your existing git tree? I'm no i18n guru by any stretch. It just seemed to me that there's a file ('de.po') that's missing from the build directory which was probably there when I compiled on Jan 7th. And I'm speculating (with little evidence, ATM) that it might not be there for you either if you start from scratch or do the 'make distclean'.

FWIW, it's not that (assuming I'm understanding you correctly): ==> which gettext /usr/bin/gettext ==> gettext --version gettext (GNU gettext-runtime) 0.19.8.1 In fact, since Jan 7th, when I last successfully built and ran DR from latest git on the same system/HDD, nothing has changed on that HDD other than some new TDM source code and some TDM 2.05-beta updates. That HDD is used exclusively for TDM and DR and it's a full, virgin 32-bit Slackware 14.2 installation (from DVD-ROM) with the addition of only the OpenAL-Soft libraries (for TDM compiles) and FTGL + wXWidgets-3.1.0 (for DR), all compiled from source code. So this seems like a new issue on DR's side, otherwise I would not have even mentioned it. A quick check shows a few recent i18n-related changes in the tree, so I suspect one of them has broken something for my setup. For the record, I'm perfectly OK with using my work-around indefinitely if this is something you'd rather not pursue.

Your fix takes care of the problem. Thanks again! A minor new problem with i18n has cropped up since the successful compile I did from latest git circa 07 Jan 2017. I worked around it by deleting the content of the 'install/i18n/LINGUAS' file and re-building. DR now compiles and runs fine. Here's the build failure output: And here's the relevant region of 'install/i18n/Makefile': If you need me to re-test after any changes, just let me know.

Thx, greebo! Will grab latest and report back ASAP.

From the usual place: http://wxwidgets.org/downloads/ Specifically, from here. Contents of '/usr/local/include/wx-3.1/wx/generic/dataview.h':

Build from latest git fails under 32-bit Slackware 14.2, with wxWidgets 3.1.0: AFAICT, that's the only build error.

Yes. Going back to my old notes on this, I was seeing errors like this when running 'tdm_update.linux' with read-only PK4 files: Applying differential update package... [= ] 6.2% Preparing PK4: tdm_env01.pk4 tdm_update.linux: /home/rand/Desktop/darkmod_src_2.04/include/boost/smart_ptr/shared_ptr.hpp:648: typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() const [with T = tdm::ZipFileWrite]: Assertion `px != 0' failed. Not a very intuitive message, is it? Looking into that is another thing on my list, assuming I get the time someday. The updater (even in 2.04) is not causing the problem, it's just not fixing (until the 2.05 release) the bad timestamps the way it should. (The whole story is long and convoluted and it's already covered in that link I gave, so I won't repeat things here.) But the problem should start to go away beginning with 2.05.

Hi, jackiebean... Welcome to the forums! I've never run Linux Mint (I'm a long-time Slackware guy), so I cannot comment on the dependencies. But if you continue having problems running the "updater" ('tdm_update.linux') app, please let us know, with as many details as you can provide (especially including the output of the log file) and we'll be sure to assist. Also, be aware that you can compile the updater app itself, quickly and independently of the game, in case that helps. Simply drop into the 'tdm_update' directory and issue a 'scons' command. And try 'tdm_update.linux --help' to see a list of useful options, including (but not limited to) '--noselfupdate'. But don't try using the '--dry-run' option -- it's advertised but not supported, something I intend to fix in the near future by eliminating it from the '--help' output. Oh, another thing that may be "biting" you: The updater is intolerant of read-only PK4 files in your installation (run-time) directory, so if you have any of those, make them write-able before running the updater. Finally, be aware that TDM 2.05 is about to be released and will include a fix to the updater app for a serious bug in the time-stamping of "resource" files, so you may want to wait until then to do any serious experimenting and updating. But don't let that stop you from playing around with a 2.04 installation if you're motivated to do so. If you encounter any issues you need help with, don't hesitate to let us know. Good luck!