NagaHuntress

Okay, I've figured out why melee attacks with weapons aren't doing any damage. The root cause is that temporary object is being deleted before it's data is used. In function idAnim::CallFrameCommands() case FC_MELEE_ATTACK_START and FC_MELEE_PARRY_START have the following code for extracting weapon names and attack/parry names: const char *WeapName, *ParName; int spcind = command.string->Find(" "); WeapName = command.string->Left( spcind ).c_str(); ParName = command.string->Mid( spcind+1, command.string->Length() );What happens is that Left() creates a temporary idStr, and WeapName stores a pointer to its C string. Because this string is short, it will use idStr's internal base buffer and not allocate anything from the heap. Then once line has finished excuting it deletes the temporary idStr, leaving WeapName with a stale pointer. On the next line Mid() then creates a new temporary idStr and AttName/ParName stores a pointer to its C string of that. This new temporary idStr reuses the storage for the previous temporary idStr. Because the storage is recycled, the two strings pointers (WeapName and AttName/ParName) point to the same string, which is what's meant to be in AttName/ParName. The end result is that WeapName doesn't name a weapon name, so the weapon look up fails and it can't do the actual weapon attack/parry, however, it still plays the animation. Whether or not this bug manifest depends upon when it deletes the temporary idStr for WeapName. If immediately it will bug with melee weapons having no effect, or if its deleted when the scope ends the bug won't happen. So ultimately its dependant on the compiler, and possibly it's optimisation options. Submitted to the bug tracker as #4199 with a patch to fix it.

Part of my motive for switching to CMake from SCons, is that I found SCons's build files were rather opaque to my eyes and I was puzzled at how to do anything that wasn't a copy and paste job. However, the big motivation for me is the fact I got this "Cannot explain why `somefile.os' is being rebuilt: No previous build information found" for every single file while building. This meant it recompiled the whole thing everytime I changed the simplest of things, and waiting 4 minutes for it to finish compiling got old fast. I couldn't figure out how to fix it, so I created a CMake file to replace it.

I ran into the same bug with "zlib.h" when compiling under Linux Mint 17.2 . The fix I made was to add the version libPNG included in the Dark Mod's source to the SCons build process. You can find a diff for this fix on the bug tracker #4198.

Okay, I've added 'in_grabmouse' to make the mouse grab behaviour like that of the keyboard's. This will fix the bug where it won't let go of the mouse on loss of focus. It's not the proper fix where it grabs and ungrabs based on focus being gained and lost respectively, but it should work well enough for now. It might have problems if the mouse moves fast enough to escape the window before it moves the cursor back to center. The diff is up on the bug tracker. #4190

I wasn't aware of there being an 64 bit branch already. Now that you've mentioned it, I can't seem to find it. Is there a special spot that it's kept? For me, the advantages is being able to use more advance debug tools. I'm not able to run Valgrind on a 32-bit build, as vital libraries are missing their debug information. The other advantage in my eyes is being able to compile natively to the distro and against the libraries it has installed. I'm not sure what you mean by collision issues. I can build both 64 bit with the new CMake file and 32 bit with the old SCons files on the same machine. There are some manual steps still (like moving include/boost ) but those can be overcome with more dev time. External tools don't need to be ported to 64 bit immediately. When they're ported, any binary data they produce just needs to keep the same sizes on data types and structures.

Even with the bug I've mentioned, I find being to alt-tab out of game immensely useful. So, in that respect I'm for putting the patch in as is, but I can certainly understand on holding off until it's of better quality. Regardlees, I'll try and work on a better version of this patch as time permits.

I've been spending the past few weeks adding 64 bit support to the Dark Mod, and finally have something that mostly work. This was only developed and tested on Linux, so a Windows version will probably require some more work still. Things tested: Able to play through the FM "Thief's Den" to completion.Able to play various bits of the training mission. (Was not played exhaustively.)Downloading FMs and switching FMsCompiling for 32 bit with the original build system.Loading 64 bit saves on a 32 bit version compiled from the same source.What doesn't work: AIs are blind as bats and require physical contact or sound to provoke them. (64 bit only)Some AIs stand in the spot while their arms are moving and their toes are lifting, suggesting they're wanting to walk somewhere but failing to. Some suspicious noise does make them to move forward a bit more. The City Watchman in the Thief's Den is a good example. (64 bit only)Melee weapons don't connect at all, both for the player and AI. (both 32 bit and 64 bit)Sky boxes seem to take on random colours based on your location and which direction you're looking. (64 bit only)What's needed to build: CMakeMake sure the following libraries and development headers are installed:BoostCURLDevILJPEGOpenALPNGZLIBX11XextXxf86vmThe souce code downloaded from the Darkmod's Subversion repository.Build instructions: Apply diff to source from the SVN repository.Remove "include/boost". This prevents the older headings from conflicting with newer ones.If your the source code is in "~/darkmodsrc/trunk/" make a directory "~/darkmodsrc/build"Run the command:cd ~/darkmodsrc/build cmake ../trunk -DCMAKE_BUILD_TYPE=Debug If successful, type the following to build the actual game:make If make is successful you should now have "darkmod.x86_64", "gamex86_64.so", and "tdm_game02.pk4" in your build directory. Copy these files to your installation of TDM (or make symlinks).Other notes: Currently the CMakeLists.txt has *x86_64 file names baked into it, but if the file names are fixed, this should also work on 32 bit systems.I've only tested on Linux Mint 17.2 (64 bit).Technically it's still a work in progress, but I'm going to having less time to work on it in the near future, and the remaining bugs that I'm aware of have me stumped at how to find the cause of their problems. Anyway, I figured I'd put it out here, rather than let it languish forgotten on my hard drive. tdm--64bit-wip--2015-08-10.txt

After some test, I've found that the games doesn't let go of the mouse when it loses focus due to alt tabbing, however, switching workspaces via the keyboard does work to force it to let go. It needs to be modified further so that it will let go of the mouse when it loses focus. I've also tested it on Ubuntu 12.04 and it performs the same.

If the size of save games were in the order of kilobytes, keeping unlimited quicksaves might be okay, but TDM's quicksaves are megabytes in size, so I can see the save driectory bloating up quickly if one has a habit of quicksaving. Having N quicksaves in rotation is a good idea, as it avoids having a bad quicksave ruin your day. Having N configurable would be nice, but I suspect N=2 will satisfy most people.

It's more likely to be related #4104 but their report doesn't mention if they tried playing past the title screen, as in my experience, the crackling/popping extened all other audio in the game and missions.

I''ve gone and submitted it to the bugtracker. I have no power to assign the bug to you, so you or someone lese will need to do that.

No, it's an unrelated bug. This bug had a random chance of happening, but when it did, it would manifest immediately or within seconds of the game starting/restarting.

I've created a patch to fix the problem where audio would sometimes start popping/crackling when the game starts. And in the cosole this would be seen repeated: snd_pcm_writei 4096 frames failed: Broken pipe preparing audio device for outputI have a feeling that this fix is more of a kludge that works around the issue, rather than fixes it at the source. However, it does appear to work well enough to mask the problem. Changes: -If a call to snd_pcm_writei() returns an EPIPE error it will re-prepare the connection and then try to send the audio data again, but it will also try to send a partial duplicate. The number of frames duplicated is set by 's_alsa_underrun_extrafill'. I've only tested it on Linux Mint 17.2, 64 bit. tdm-linux-sound-fix.txt

I've created a patch to fix the problem where it was impossible alt-tab (or use any other window manager key combos) to switch away from TDM. This patch works for both windowed and full screen modes. tdm-linux-window-manager-key-fix.txt Changes: - It will no longer grab exclusive input of the keyboard by default. This allows the window manager to process the keyboard input and do things like alt-tabbing. To get the old behaviour set 'in_grabkeyboard' to 1 (Exception: Full screen console will now ungrab, previously only windowed console would ungrab.). - In order to get the above behaviour to work in full screen mode, full screen mode initialisation has been modified so that it asks the window manager to handle the window as a full screen window. To get the old behaviour set 'v_nowmfullscreen' to 1 (this will force it to grab the keyboard input too, regardless of 'in_grabkeyboard' or other conditions). I've only tested it on Linux Mint 17.2, 64 bit.