OrbWeaver

Ubuntu PPA packages are built for 18.04 LTS and 19.10 (I didn't do 19.04 because it goes EOL in less than a month, but it's possible the 18.04 package will also work on 19.04 if anyone needs it).

Sadly we don't have lossless files for most of the sounds, because they were never committed into source control and the artists who created most of them have long left. If you just want to listen to the music though, the OGG file that freyk listed should be usable. It's not quite lossless, but it's a reasonable bitrate Vorbis encode that shouldn't have any noticeable artifacts unless you have truly amazing ears.

Curiously I advised him to do exactly this when he contacted me on Steam some time ago and asked me to pass on various bug reports. Whatever the rights and wrongs of his forum ban (which I won't discuss here), there is absolutely no reason why he can't have an account on Mantis to submit bug reports.

The panel currently has minimum height of 80, meaning that you can't drag down to obscure it even when it is empty. It is pretty trivial to set this to a much lower value (e.g. 10), allowing you to drag the splitter almost to the bottom of the window, giving a more Blender-like interface where you can drag windows to minimum width to hide them. A possible disadvantage however is that users might not realise that there is a widget available in the bottom pane if the splitter is dragged down to hide it, since the splitter does not jump back up even if you switch to another spawnarg which offers a custom editor. This is probably no problem for experienced mappers, but I could imagine a newbie accidentally dragging the splitter down and then working for some time without ever realising that they are missing out on useful functionality like the Choose Model button.

In case it helps anyone, I also have a Git repository which includes the latest ASE and LWO export scripts (tested and working in Blender 2.8x), as well as an application template that you can add into the New menu to create an empty scene with certain grid and viewport settings that might be more useful for Dark Mod modelling than the Blender defaults. I'm open to suggestions for other things which would be useful to include in the template. I'm not much of a modeller so maybe there are certain additional settings that everybody needs to use which I haven't considered.

I don't think you should be able to knock out a bot, but I think the blackjack should do more damage than the sword (because it's easier to bludgeon metal than to attack it with a sharpened blade). I seem to remember this was the case in Thief 2.

The map format is dictated by the game, not DarkRadiant, so updating DR will never make maps incompatible (assuming there isn't some catastrophic bug, of course). I do recommend keeping regular backups of your map files to avoid data loss however. Ideally you would use a version control system like Git or Subversion, but failing that, any cloud backup service that stores snapshots of older versions would also work fine.

I'm a big fan of Git. I switched DarkRadiant to Git years ago, and have been happily using it and sharing commits between my and Greebo's repositories (on entirely separate hosting platforms) since then. But even as a Git fanboy I am embarrassed by some of the misconceptions about, both in the "for" and "against" camps. Misconception: "Git doesn't use a central server". Reality: The vast majority of Git projects, and the workflow that would most likely be adopted by TDM if it were to switch to Git, is to have a central authoritative server that every trusted developer pushes their changes to. The Linux kernel is a notable exception, but is also very atypical in both its size and the distributed nature of its development. Git provides a little more flexibility in that developers can make a whole string of commits locally and then push them in one go, but they are still going to be pushed to that central server before anyone else can use them. Having each individual developer push their changes to their own GitHub repository and submit a pull request would be possible, but probably wouldn't solve any problems for this project, and would increase workload for whoever is appointed to review and accept all of the pull requests. Since all developers would be pushing to the same repository, code breakage is just as possible with Git also. Misconception: "Git magically avoids code conflicts". Reality: Code conflicts are the result of divergent, incompatible text changes in the code itself. If you and I edit the same line of code and then try to push our changes, a merge conflict will happen. The choice of VCS makes absolutely no difference to whether this conflict will occur, although Git does provide slightly better tools for dealing with the conflict when it does arrive. There are only two repositories that matter for the Dark Mod: the source code repository, and the assets repository (which is never going to be switched to Git because it is a repository of large binary files which would not be handled well by any distributed VCS tool). So needing to clone the whole thing is not an issue. Those are both workflow or cultural issues which cannot be solved by a VCS. People can just as easily delay commits/pushes with Git, and they can easily make lots of small incremental commits using Subversion. If commit frequency is a problem (and I have no reason to believe it is), it needs a social solution, not a technical one. On the other side of the fence: It does have unsafe ways to edit history, but they are not particularly "encouraged". Most Git guides I have seen make clear that rewriting history is very dangerous, completely screws up other people's work, and should be avoided whenever possible. Sites like GitHub even have the ability to administratively disable force-pushes altogether to stop people from doing them accidentally. Misconception: "Git adds a whole load of distributed functionality making it hard to use". Reality: For the most common use case (pushing to a single central server), there is absolutely no need for any Git user to deal with "distributed" functionality. You can produce a SVN-to-Git cheat sheet that maps commands almost one-to-one, and stick to those commands entirely. Some of the commands aren't particularly well-named (e.g. using "checkout" to switch to a branch, or "add" to add changes to a file rather than adding a new file), but they are not complex to use, and you can always set up aliases if you find the default names confusing. Conversely, many operations are significantly easier (and faster) in Git than in SVN. Only recently did SVN add the ability to view the diffs of each change in the history, or to show which changes were pulled in by a merge, and these features are still slow and cumbersome, whereas Git (and Hg) did all of this from the beginning.

Samples where the noise is noticeable at an ordinary listening volume (i.e. not selecting the noise and amplifying it artificially): mantle_pull01F mantle_pullF01 mantle_pushF01 With all of the others I think the noise would be very difficult to notice without specifically looking for it in an audio editor, as most of it is just electrical hum at 50/60 Hz which contains nothing useful for vocals and can just be high-pass filtered out.

The hum is pretty easy to remove with a high pass filter (I tested in Renoise). There is a small amount of broad spectrum background noise (although strangely not in every single one), but I would say many of these would be perfectly usable from an audio quality perspective.

#5021: DR gets unhandled exception on start up should also be fixed in this release (this is the one where you had to delete your corrupted filters.xml to get DR to start correctly).

To be honest that process seems very convoluted to me, with its insistence that the mod be installed into a system-wide location but with world-writable permissions, and "mandatory" chmod commands after almost every step. I would recommend a process similar to what kano suggests: just download and run the installer from a directory where you already have write permissions (e.g. in ~/Games/DarkMod), then if you really need to make it a systemwide installation, move it into /usr/games/darkmod and set permissions afterwards. I would bet that the vast majority of users never actually need to do this, because most people's machines are single-user and don't need to run the game from multiple accounts.

I can help with audio editing/processing if necessary, although I'm certainly no better at it than any of the other forum members who have experience in this regard. I have registered versions of REAPER and Renoise which I use for my own audio work. I'm no creative director though — I'd vote for Springheel in that regard although he may not have the time now he's officially retired. Removing hum can be achieved with a notch filter, which may give better results than a full spectrum noise reduction plugin depending on the spectrum of the noise you want to remove. And (although I cannot speak officially) I definitely second what Peter said: we do need uncompressed WAV originals, not just lossy OGGs. It's fine to distribute the final product in OGG format to save space, but we should have the uncompressed originals checked into the source repository so they can be edited, combined into new sounds, recompressed with a higher-quality codec or whatever may be necessary in the future. Having to recompress already-compressed OGG files is really sub-optimal and introduces generation loss.

I'm a big fan of the modern classical music used in film or game soundtracks; in fact some would say that people like Hans Zimmer and John Williams are keeping classical music alive, when the art music world has disappeared up its own pretentious ass into atonalism and unlistenable post-modern bollocks. I think the reason we don't see a lot of it in the modding world is because it's actually very difficult to produce on a small scale: you either need the enormous amount of time and money required to score and record a piece for full orchestra, or try to simulate it as best you can with really good (and therefore expensive) sample sets and plugins. I like to incorporate classical themes and textures into my electronic music, but actually trying to make the Gladiator soundtrack on a home PC would be impossible.

A single line of text under the title is not documentation, and will not be visible to anybody who installs a package of this software through their distribution. Even if you put that text into the package description, as a hypothetical end user I still have no idea what it means to "build a root tree adequate for packaging the game into Linux", or why I would want to do this. Maybe I'm just exceptionally stupid, but if I don't understand the purpose of the script, it's possible that the Arch developers don't either, which might be why they are rejecting the package. (Looking at the contents of the script I can see that it is creating a directory structure under a directory called "build" which contains Dark Mod files in system-wide subdirectories locations like /usr/bin, but I don't think end users would normally be expected to read the source of a script to find out what it does after installing a package. Nor is it immediately obvious why an end user would want to run such a script on their own system — surely building this tree is something that should happen as the first step of building an RPM/DEB/AUR package, and should be included in the package build scripts, not installed onto the end user's system?). What is expected to happen when an Arch user installs this package? Presumably they're just going to get a build.sh file installed into some system-wide location (maybe /usr/bin) which will then appear in their PATH. From the name build.sh it is not obvious what this tool does or what project it is associated with, but if I try to do the obvious and type "man build.sh" or "build.sh --help" neither of those commands are going to give any help (and the second one will presumably just start building a Dark Mod root tree in the current directory, which may not be what I want). Again, I am not associated with Arch and have no idea of the exact reason they would reject the package, nor am I suggesting that the script is useless (in fact it is probably very useful for people who want to create DEB or RPM packages of the Dark Mod). I'm just giving some possible reasons why a distribution might not accept it. Essentially you're just giving them a random shell script and saying "Here, distribute this awesome script! There's no documentation or man page included, but if you want to know what it does, just look at Github or read the source!".