Search the Community

the code is from the current git at https://github.com/codereader/DarkRadiant I get the following just $ make CDPATH="${ZSH_VERSION+.}:" && cd . && aclocal-1.14 -I m4 /bin/bash: aclocal-1.14: no s'ha trobat l'ordre Makefile:517: recipe for target 'aclocal.m4' failed make: *** [aclocal.m4] Error 127 configure doesn't seem to give me any error: any idea what's happening?

Ubuntu and variants have decided that ia32-lib package won't be available anymore. From what I understand instead of one metapackage apps are supposed to install their 32 bit dependencies as they install. Obviously, as tdm isn't a packaged deb this doesn't happen and the 32 libs needed aren't installed. Has anyone got a work round for this? I wondered if their was a list of 32libs needed users could install them separately.

First of all, hello! I am a new player and user, who sadly only heard of TDM a few days ago. I was mind blown that a game of this genre + quality + complexity might exist in the world of open-source / Linux gaming, and couldn't believe my eyes until I actually played it and looked for official info on the website. Thank you to those who created this fantastic and ambitious project, and of course ID Software for releasing the Quake 4 engine which made it all possible. As far as I'm aware, this is the only FOSS singleplayer FPS, as well as the only FOSS project with cutting edge rendering features which actually allow for modern visuals... certainly something new in this area. There are many things I'm intrigued to discuss and possibly suggest. I wanted to start with a simple technical question however: Is it known when there will be an x64 version of the engine? 32-bit is always slower more or less, as well as limited to 4GB of memory... main reasons why I strive to run only 64-bit versions of everything. It's also problematic to run on a 64-bit Linux OS, where you usually need compatibility libraries to be maintained. I use openSUSE which thankfully maintains these... but I still have an issue with sound constantly "flickering" and suffering rhythmic interruptions, which is suspected to be related to 32bit. I discussed this briefly on the IRC channel, but only heard that attempts to make the engine x64 compatible existed yet none were finalized. Was hoping there might be more news on what to expect.

Greetings, I'm looking for some information (or anecdotes or anything, really!) about the state of TDM source code compilation under Linux. I've been test-compiling the latest official (2.04) TDM source code on 32-bit Slackware 14.2 and I'm a bit confused because there seems to be no way that that code would compile without at least 1 tweak under any Linux distribution (and even more tweaks under a modern Linux distribution). I've also taken a look at the Doom3 (non-'BFG Edition') source code release and, frankly, the same could be said about that code release, which probably explains a lot of the TDM Linux build issues. So, in summary, I cannot understand how the TDM 2.04 Linux build was ever compiled for release using the 2.04 source code provided. Can anyone shed some light on this matter, please? I'm considering submitting one or more patches to get past the most serious issue(s) if there's a chance that such patches will be put to good use. But before I do, I need to understand more about the history and the current state of affairs with regard to the TDM Linux builds. I don't want to duplicate efforts and/or step on anyone's toes if they're already dealing with this somehow. Thanks!

It occurred to me that I should submit this patch now, especially since I see evidence of others (like 'Crinkelite') compiling TDM under Linux. Based on replies to my post in my other recent thread, I realize that it has no chance for 2.05 inclusion, but I want others to have access to it now, so I'm asking that it be added to latest SVN, please. Problem/Fix Description: There is some sort of anomaly with the SCons build system (which is used only for Linux builds, not Windows builds) whereby all items get needlessly rebuilt, every time, when doing TDM builds. In fact, this was encountered by 'NagaHuntress' back in this Aug 2015 post. But, for this and various other reasons while investigating a 64-bit Linux build, she chose to completely switch from SCons to CMake, conveniently side-stepping the problem. The issue fixed by my patch has to do with the SCons (MD5) 'signature' file, which is used to decide when input files used in the build have changed. It's not 100% clear what the cause is, but it may be due to the use of the 'VariantDir()' directives in the 'SConstruct' file. Regardless of the reason, credit for the solution comes from Victor Gaydov's webpage: Both Doom3 and, therefore, TDM use a method of specifying the SCons signature file which causes this serious problem. The solution is quite simple, just as Victor stated: specify the signature file using a full path. The attached patch provides this improvement. It was tested under 32-bit Slackware 13.1 running SCons version 2.5.1 and under 32-bit Slackware 14.2 running SCons version 2.4.1, both against latest SVN (6720) and against the TDM 2.04 release. The fix means that now when you're building TDM under Linux, SCons won't (annoyingly!) rebuild the whole tree every time. This change also nicely allows the removal of a hack in the Linux build script file which was used to force the existence of a SCons signature file. Prior to this patch, if SCons was run without a signature file of the expected name already existing, it would report a long error message that began with this: OSError: [Errno 2] No such file or directory: 'scons.signatures.dblite':And, worse, it would fail to create the proper signature file ('scons.signatures.dblite'), instead creating an unwanted 'scons.signatures.tmp' file, and thereby causing ongoing grief with every successive run of SCons. This simple patch fixes both problems while also removing the inelegant work-around in the Linux build script file. Please apply to latest SVN. prevent-scons-from-rebuilding-everything-every-time.patch.txt

I have no sound on an ubuntu 64 bit machine in darkmod (no music no ambient) ------ OSS Sound Initialization ------ opened sound device '/dev/dsp' ioctl SNDCTL_SYSINFO failed: Invalid argument this ioctl is only available in OSS/Linux implementation. If you run OSS/Free, don't bother.WARNING:driver doesn't have DSP_CAP_MMAP capability close sound device WARNING:sound subsystem disabled any ideas?

I've been having a few issues with a dual monitor setup. I first tried playing in full screen mode. This was pretty bad. I couldn't control which monitor the game was shown on and the other monitor was disabled completely. When I closed the game, all of my other open windows were all on the same monitor and I had to put each one back the way I'd had it before. Then I played in windowed mode and made it fullscreen in the windowed menu. This is better: I can choose which monitor to play on and my other windows stay where I put them. However, the video settings are changed for the other monitor. Is there some way to make the video settings only affect the game window? I have some stuff open on the other screen and the colors are all messed up until I close the game. Also, there is no way to release the mouse from the game while a mission is loading. When I am in the menu, I can press the ~ key. This opens the console (which I don't care about) and releases the mouse. When a mission is loading, this does not work. Is there some way to release the pointer while a mission is loading? I am using the GeForce 1060 graphics card with nvidia driver version 390.42

I am reporting here my experience with compiling TheDarkMod from sources on Linux. I am going to attach some patches, but beware that especially the ones related to build may be specific to the system.I have used a Gentoo Linux distribution, with multilib enabled (that means that I have a lot of libraries compiled also in 32 bit version).Relevant packages:GNU compiler: 5.4.0Boost libraries: 1.62.0The Dark Mode: SVN trunk (2.06+, last commit: 6731, Dec 15, 2016). Finally, I am new to this program and I have gone mostly from scratch, likely ignoring a big deal of lore that may demonstrate some of this as obsolete, non-optimal or plain wrong and dangerous. I'll try to catch up with the threads developing on the subject. I downloaded the sources with: git svn clone --stdlayout https://svn.thedarkmod.com/publicsvn/darkmod_src thedarkmod git tag FromSVN # to keep track of my own changes (because I am the GIT type), and it took long. Nothing I am writing here depends on using GIT instead of SVN anyway. First, I should have applied immediately NightStalker's patch. I didn't, and I regret. It's from this forum, at http://forums.thedarkmod.com/topic/18544-time-saver-build-fix-for-sconslinux-compilation. Also, I did some tuning on the build scripts, that are good for general purpose but not for distribution (the distribution plays safe and assumes Pentium3). I enabled as many CPUs as available and the "native" instruction set (build_tuning.patch.txt). IDLib tries to forward-declare std::basic_string, which is a standard C++ class; unfortunately its declaration is an implementation detail, and the one in PUGIXML turns out to be incompatible with the one shipped by GCC: error: reference to ‘basic_string’ is ambiguous std::basic_string<char, std::char_traits<char>, std::allocator<char> > PUGIXML_FUNCTION as_utf8(const std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >& str); And the system string class from GCC 5 is different from the one that was used to build the Boost libraries that are shipped. Sadly, the only thing I could manage was to hard-code the system Boost libraries in the build paths. In my case they are at /usr/lib32, so the magic took the form of: grep -r -l -e 'lib/libboost' * | xargs sed -i -e 's@/usr/local/lib/libboost\(.*\).a@/usr/lib32/libboost\1.so@g' -e 's@#.*linux/boost/lib/libboost\(.*\).a@/usr/lib32/libboost\1.so@g'boost_link.sh.txt (note the "/usr/lib32/" path in two places). This, and changing PUGI header (pugi_strings.patch.txt) did the job. Now, there are linking problems with duplicate definitions. I really do not understand how that thing was supposed to work, but anyway I changed the definition of INLINE for GCC so that it avoids emitting multiple definitions for the same functions. Also I had to manually fix a couple of places for the same reason (inline.patch.txt). Next, a recent commit added a source file (idlib/geometry/RenderMatrix.cpp) but it did not add it to the source list for Linux build. There is also some piece that is Windows specific and that needs to be disabled (RenderMatrix_in_Linux.patch.txt). After this, running ./linuxBuild.sh produces gamesx86.so and thedarkmod.x86, which I copied manually into the directory where I had a downloaded installation (2.04), and that makes it a 2.06. The updater has still Boost link problems, so I use the shipped one. Just that. Now compilation works to me all the way from commit 6600 to 6731, with some exceptions here and there. The first commit works well enough that I could actually start playing Saint Lucia. The latter, though, is buggy in that my character is always considered in deep darkness: convenient for him, but not for my gameplay. More about this in another post, I guess. If you want to give these patches a try, you can run patch -p1 < patchname.patchin the main source directory (the attached patches should be renamed, with .txt removed; the shell script operates the substitution above).

.

I've been thinking a bit, it would be a good idea to involve the Linux community in the development of this game to improve it's compatibility with Linux. I'm a relatively new Ubuntu user and am just starting to get familiar with Linux and all of it's quirks. The Linux community supports open source software and getting them involved in developing and testing the Dark Mod on various distros will do a lot of good. I installed The Dark Mod on windows and it works just fine, I've seen a lot of people say that there's issues with getting it to run on most distros of Linux. Would be cool if it were possible to get the Dark Mod to show up on the Ubuntu software center, most of the open source games you see there are crap. This would be the first fully featured 3d game that runs on a good graphics engine there and many people would probably download it just to check it out. They might help with continuing the development of the campaign. Just an idea that I'm throwing out there, I might inspire someone to do something or it might require me to take initiative and post on an Ubuntu/Linux forum or something...

Yesterday I installed 'The Dark Mod' version 2.05 on my computer. ('tdm_update.linux' worked great, but took FOREVER. The resultant 'thedarkmod.x86' file is 6.5 MB in size.) My issues: When starting the program (./thedarkmod.x86), I get great audio, but only a black screen (window).When running on full desktop mode (not in a window), both monitors go black.I can hear clicking when I move the (invisible) mouse pointer within the black screen. Unfortunately, the only way I found to get things back to 'normal' is to do a 'CTRL+ALT+BACKSPACE', since I cannot get the mouse pointer to my desktop (when running in window mode).I cannot see what errors I may have gotten when launching from the command line, because of having to re-start my session (see line above). My computer system: OS: Linux Mint 17.3 (64 bit) CPU: Intel Core i7-3610QM @ 2.30 GHz x 4 System RAM: 8 GB Video Controller: Intel 3rd Gen Core processor Video Card: AMD / ATI Heathrow PRO [Radeon HD 7850M/8850M] Video RAM Available: 2048 MB Displays: Laptop [1920 x 1080 (16:9)], Standalone monitor [1920 x 1080 (16:9)] Anyway, from searching the forum for possible things to do to get video, I changed the following lines in my Darkmod.cfg file: seta com_videoRam "2048" seta r_aspectRatio "1" seta r_fullscreen "0" seta r_customHeight "900" seta r_customWidth "1600" seta r_mode "-1" seta sys_videoRam "0" Still, I get the black screen (window). My Darkmod.log shows: Any thoughts on how to actually 'see' what is hiding inside the black screen (or window)?

I have created a new PPA (personal package archive) for hosting the darkradiant Ubuntu builds. It is available at: https://launchpad.net/~orbweaver/+archive/darkradiant including instructions for how to add the PPA to your APT sources. This is a lot easier for me to upload packages to than the existing FTP repository (especially since I can just upload the source package and it builds the binaries automatically), so unless there are any significant problems I expect to use this PPA for future Linux releases. It also has the advantage of not using up Tels' generously-provided bandwidth.

Try as I might, I cannot set up my software sources (Linux Mint 17 aka Ubuntu 14.04) to successfully get hold of Dark Radiant. I've had DR before and run it with no problems under earlier Ubuntu versions. Synaptic Package Manager tells me that there are dependencies which cannot be satisfied (libcurl etc). Fine, but I haven't the faintest idea what I'm supposed to do about that. Is it me, or is it not possible at the moment for me to run Dark Radiant? (It does appear to be the case that the latest DR version was issued with Ubuntu 13.04 in mind). Any help out there?

Hey, Every time I've try to use the Full Editor when PM'ing someone, and every single time I get an error. Whoever is in charge of the forum, is it possible that this could be fixed? Thanks Neon