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).