OrbWeaver

Typically we aim to follow the GNOME Human Interface Guidelines for DarkRadiant, largely for historical reasons (it was derived from GtkRadiant, although it only uses GTK on Linux now via the WxWidgets back-end implementation). However, neither Objectives nor Conversations currently comply with the guidelines, because: They are a curious hybrid of instant-apply (creating or deleting objectives or conversations entities) and explicit apply (editing the contents of those entities). This means if you click the cancel or X button, the entities will be left in the map but any changes you made to those entities in the bottom part of the dialog will be silently discarded. If they are instant apply dialogs (which the HIG seems to recommend where possible), they should only have an X button to close the dialog, not OK/Done/Cancel buttons. The HIG doesn't specify exactly how users should cancel their changes in this case, but I assume the expectation is that they would use the Undo function. If there are supposed to be explicit apply dialogs, they ought not to have an X button at all (although again the HIG is a little vague on this point — it says that instant apply should have an X button, but does not explicitly say that explicit apply should not have one), but should have Done and Cancel buttons which behave as you would expect. So you are right that there is a usability problem, but the recommended solution is not to have dialogs pop up additional dialogs. Either the changes should be applied as soon as you make them and clicking X just makes the dialog go away, or there should be no X button at all. That does seem to be the shortest path to avoiding data loss in this case, although the fact that entities are created immediately and left in the map even if you explicitly Cancel is still a deviation from recommended behaviour.

Literally everybody believes that their religion is "beneficial", that's why they believe in it. The people behind the Spanish Inquisition thought they were improving society by eradicating non-believers who would bring about God's punishment. Destroying the economy, massively increasing the cost of living, inviting the government to manage every aspect of our lives (such as with enforced veganism), brainwashing children to believe they are literally going to die of climate change before they reach their twenties, just so we can show how much we care about polar bears while the developing world continues to spew as much CO2 as they like... isn't particularly beneficial in my book, but YMMV.

You know environmentalism has become a religion when its followers literally declare their child prophet a Messiah, parade effigies of her in the streets and put up murals and paintings as if she's the fscking Virgin Mary.

On the other hand, this is the Dark Mod forum which in my experience tends to be an order of magnitude more civilised than most forums (especially game-related forums which tend to be full of toxic entitled 12-year-olds). I give it a 50/50 chance.

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!".

I know nothing about the Arch Linux packaging policy, and I am not officially speaking on behalf of the team, but I would be astonished if any distribution would package that software as it currently stands. There is absolutely no indication of what the software does, why someone would want to download or use it, or how it should be used. No documentation, no README, nothing. I can't even tell from the repository who is supposed to be installing and running this software — e.g. is it aimed at people who want to create packages of the Dark Mod (to give to other people), or for end users who want to install the Dark Mod for themselves to play? Or is your Git repo just a skeleton for building an Arch package of the Dark Mod itself, and end users will not run your scripts themselves? I really have no idea. The licensing situation is also very unclear, since your license file refers to GPL 3, but does not contain the GPL 3 license and also seems to impose its own requirements which are not compatible with the GPL (for example, the GPL does not require distributors to credit the author or indicate if changes were made).

If there aren't enough programmers to put the Unreal Engine 4 features into the Dark Mod engine, why would there suddenly be enough programmers to make a completely new Dark Mod 2 from scratch (which is considerably more work)? Suggesting a sequel as the solution to a lack of updates in the current version is like suggesting building a new city because you don't have enough resources to build a house.

If people want to assist by donating programming time and skills, I'm sure the team will always welcome that.

The only need for building in VR is if the game is going to be played in VR, in which case the VR editor will give you a better idea of what players are going to see. Being able to interactively add and position objects in 3D space does not require VR; in fact it is a common feature of MMOs which allow players to create their own housing or private areas (I suspect the same interface is used by the developers to build the game world itself, which is why it is relatively easy to make this feature available to players). Converting this 3D interface into VR doesn't magically make it easier — it would provide stereo viewing of course, and make it slightly easier to move your head around to get a different view of the object rather than using the mouse, but as others have mentioned it introduces its own problems too. I'll be the first to admit that DR has many usability problems, but making it into a VR app isn't going to fix them.

Hard crashing the entire application for a missing asset is just stupid. If you do this on Windows (which most mappers and players are using), nobody will even see the error. They will just get the standard Windows "This application has caused an error and will be shut down" dialog and have no idea why unless they go hunting in log files. There is no benefit in this behaviour, you are literally hiding the problem if you do this. The only people who would conceivably want a console message followed by a hard crash are people running the game from the command line on Linux, which is a tiny minority of the userbase. If you wanted to make a missing asset a hard error (in order to prevent mappers from inadvertently shipping a map with a missing asset), you could make it print a message in the internal console and then refuse to load the map, much like what currently happens if you try to compile a map which has a leak. This behaviour might be useful for mappers but would have no use whatsoever for end users (who are not responsible for the assets in a map), so it should at best be a configurable developer option, as stgatilov is suggesting.

To slightly expand on that point, a good quality microphone is essential, with a wide frequency response and no colouration of the sound. Basically the sort of full-size mic that you might see in a radio studio, not a cheap VoIP mic or a gaming headset. It will be really noticeable if the vocals are recorded with a low-quality mic, once they get into the game. The audio might sound muffled, or particularly harsh around the sibilants ("S" sounds), and no amount of processing will fix it.