OrbWeaver

I'm afraid you may be on your own with this one. Using dodgy unofficial compiler patches to hack in a new way of passing exceptions between DLLs (which is generally risky and prone to silent failure even when using a sane compiler setup), and then using this to target a very non-standard platform/package combination (GTK on MSYS/Windows), sounds like such a horrific maintenance nightmare that I wouldn't personally touch it with a ten foot pole.

These are problems in the source code and/or libraries used during building (e.g. libgit-dev). They have nothing to do with the Git version or command you used to check out the DarkRadiant git repository itself. Git is used internally to build the version control functionality inside DarkRadiant, and it is this version control plugin which is failing to build.

I don't even understand what this code is about. What is the "TDM based GCC compiler"? The TDM team doesn't write C compilers, does it? Why would we need to deal with such low-level mutex and shared memory code?

With the latest Ubuntu package I see the same behaviour: mouse scroll works when not in freelook mode, but in freelook mode it does nothing (arrow keys still work). To be honest I think it's been like that for ages but I never realised that the scroll wheel was supposed to work in freelook mode.

My understanding is that the original meaning of "save scumming" is when people take a game which is supposed to have permadeath (typically by deleting save files when the player dies), and "hack" it by backing up and restoring those save files outside of the game's control. In other words, modifying the intended design of the game in such a way as to make it less challenging. Like you, I can see no justification for using the word to refer to people who simply make use of a save feature which is exposed by the game and expected to be used by players.

Quicksaves should be restricted because: We want the game to be the exclusive domain of a small minority of hardcore players who are able and willing to spend 14 hours a day honing their Dark Mod skills, and we regard all other players as "scum" who should bugger off and play Candy Crush instead. We assume we know best what gameplay experience will be most rewarding, and want to force our one-size-fits-all solution on every single player for their own good. We want to encourage the development of unofficial forks of the game (since it's open source), and regard the resulting player confusion as just another part of the excitement. We firmly believe that game difficulty should only ever move in one direction: upwards. We are unable to improve any of the unpredictable and confusing mechanics which motivate save-spamming in the first place (like blackjack failures or hitting the wrong part of a light with one of your 6 remaining water arrows), and we consider removal of the save function as the easiest band-aid.

More intelligent video codecs are definitely on their way. Current codecs have difficulty with things like white noise, gravel, water splashes and the like, because of the rapidly changing high-frequency content which does not compress well under DCT and Fourier-based algorithms. But a human doesn't care if this detail is accurate at the pixel level, as long as the texture appears realistic. A future codec might encode this more efficiently by looking at the higher-level patterns, and representing something more like "a frame full of flowing water using scale S and colours C1, C2 and C3" which the decoder can use to recreate the detail, even if it doesn't match the actual pixels in the source footage.

Exactly. We are biological "machines" following the "programming" of millions of years of biological evolution, along with several thousand years of cultural evolution. There is no reason to assume that a biological machine is fundamentally capable of doing something an electronic machine can't, unless you cling to the philosophy of vitalism which says "Biological organisms are Just Different in ways which are impossible to describe or understand." Which is more or less identical to the belief in a metaphysical soul, just with slightly different language. So are the neurons which comprise our brains. They are balls of water and other substances which communicate with one another in a primitive, well-defined way. Nobody has ever been able to look at a neuron and say "That is the neuron which gives rise to consciousness and artistic appreciation". No neuron has a mind of its own. But together they somehow comprise a human mind. And that's the problem with all these vitalistic and mysterian theories of consciousness. They rely on the logical fallacy that says "If I can't understand how this happens, it must be fundamentally non-understandable". But such an argument is clearly nonsense. There are thousands of things (e.g. in advanced physics or mathematics) that I don't understand, but other people do — and that's just looking at the present day, not all of things that future generations will understand better than any of us. It would require an extraordinary arrogance to assume that because we can't understand how a fully-conscious machine could be built today, then it must necessarily be impossible even after hundreds or thousands of years of technological advancement.

If, hypothetically speaking, a future FlatPak containing the game itself were to be created, would this be an easier problem to solve? Or is linking between FlatPak directories just as hard as gaining access to an arbitrary directory?

This is the argument from ignorance (or lack of imagination). "We don't understand X, therefore X can never be understood, and it must be magic." The brain is made up of neurons, which are well understood. They "fire" in response to a certain threshold being reached by a required number of input neurons. Yes, there are millions of them, and we don't understand the full implications of how they are linked together, but there's nothing magical going on. A sufficiently advanced machine with a sufficient amount of processing power would be able to simulate the behaviour of a neuron-based human brain. And unless you quite literally believe in a metaphysical "soul", this simulation would produce the equivalent of a human mind. Nobody is claiming that a present-day computer can do any of this. But this proves nothing about what future computers will be able to do. Once upon a time, people would have said that no machine will ever be able to beat a human at chess, but now they can (easily). Only a few years ago people would have insisted that a machine can never interpret an English sentence and produce an original work of art, but here we are. I'm not sure why you group all "living beings" together in this way. As far as we know, there is nothing living which can think like a human, although elephants and some cetaceans (e.g. orcas) may come close. Living beings encompass everything from humans to dung beetles and amoebas, and even our present-day computers are capable of more advanced "thinking" than many of these. Computers have been capable of true randomness for decades. That's how secure encryption works. Most modern CPUs even have built-in instructions to generate random data from a hardware (i.e. analog) random generator. Not that it really matters, since there is no current evidence that consciousness or human-like thinking depends on randomness. We have very little understanding of how human memory works, or why we forget things (and then subsequently remember them again). But there is no reason to declare up front that we will never understand this, or be able to simulate it in a machine. And how do you know that we don't act in pre-defined routines, "programmed" by biology and/or culture, acting in a way which (purely by accident) gives rise to what we consider human behaviour? Just because you can't tell where your creativity and human behaviour comes from, doesn't mean that it is magic, unknowable, or coming from somewhere other than the mechanics of your brain.

I always watch these panics about AI bots "invading" this or that with an attitude of detached hilarity. Given that humans are nothing more than a biological machine, it seems self-evident to me that given enough time and technological advancement, electronic machines will be able to do everything that humans can. When humans create art, they do so by a process of generating ideas based on existing art styles they have seen or been taught, along with various sources of "inspiration" from their everyday life or past experiences. There is no magic, there is no "soul". It's just recombining various ideas in their heads in a way which matches culturally-specified criteria for what is aesthetically pleasing and what isn't. This is exactly what the AI bots are doing. Sure, if you're a junior graphic designer whose job is to create customer-specified images on demand, you'd probably be threatened by these developments, just as people who made candles were threatened by the invention of electric lighting. But that's progress for you.

I think the i18n system was written single-handled by Tels, who was a rather — shall we say — opinionated developer, with some strange ideas about how things should be done. He was a big fan of Perl for some reason, and even asked if we would add a parallel Perl-based scripting system into DarkRadiant, even though we already had Python and nobody except him actually wanted to write scripts in Perl. I'm sure there must be better ways of doing i18n, although how easy those other systems are for integrating into a game engine I wouldn't know.

I've got most of the way through this mission and can definitely see the "Grayman quality" at work. Unique and consistent architecture with a mission-specific distinctive look, and a layout that makes sense. However I am stuck because I have only found two of the poetry books — despite clearing out the entire castle, knocking out every AI, and looking inside every container I can see, I still cannot find volume 2 anywhere.

There definitely shouldn't be different rulesets (for the aforementioned reasons), but UI helpers such as auto-raising the blackjack should probably be configurable since not all players would want them.

I'm not sure I really understand what you're asking, but I think you're talking about the pathfinding of the AI (guards etc), and suggesting it could be improved so that they can find their way around obstacles rather than repeatedly walking into them? The second question about "buffers" I'm afraid I don't understand at all.

OK, I got it built and installed. Main functionality looks good. Basic map loading and rendering is working as expected. I don't know where the preferences are being stored. The existing preferences from ~/.config/darkradiant/3.1 are not loaded, however newly-set preferences are saved and loaded in the next session. So it is storing preferences somewhere, just not in the normal location. The wxWidgets GL rendering issue does reproduce for me. The easiest way to trigger it is to click on the Media tab then on the Textures tab. The contents of the Media tab continue to be visible until you do something which triggers a re-render (e.g. move the camera or just click in one of the 3D views). This will probably require an update to wxWidgets 3.2 when possible. Missing icon confirmed, but this is already planned to be fixed before release.

It turns out that Ubuntu are shipping a broken version of flatpak-builder. In order to build on Ubuntu, you need to: Uninstall the .deb package of flatpak-builder if it is installed. Install the Flatpak version with [sudo] flatpak install flathub org.flatpak.Builder This will install the Flatpak but not put the command into your path, so you need to run /var/lib/flatpak/exports/bin/org.flatpak.Builder (or your local version, if you didn't install system-wide) manually, or symlink it into /usr/local/bin/flatpak-builder for convenience.

Unfortunately I can only get as far as step 5: $ flatpak-builder --user --install --force-clean build-dir com.thedarkmod.DarkRadiant.yml (flatpak-builder:15593): Json-WARNING **: 20:22:26.374: Failed to deserialize "config-opts" property of type "GStrv" for an object of type "BuilderModule" Downloading sources Downloading https://downloads.sourceforge.net/project/glew/glew/2.2.0/glew-2.2.0.tgz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 327 100 327 0 0 496 0 --:--:-- --:--:-- --:--:-- 496 100 816k 100 816k 0 0 600k 0 0:00:01 0:00:01 --:--:-- 3296k Downloading https://mesa.freedesktop.org/archive/glu/glu-9.0.2.tar.xz 100 162 100 162 0 0 567 0 --:--:-- --:--:-- --:--:-- 567 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 Failed to download sources: module glu: server certificate verification failed. CAfile: none CRLfile: none I'm assuming this is more an Ubuntu problem rather than a Flatpak problem, since nothing in the manifest specifies the SSL certificates. However I don't know how to rectify it. I'm not even sure what it's using to do the download: wget downloads that URL fine, whereas curl returns a "301 Moved Permanently" page but does not otherwise complain about SSL certificates. EDIT: This works fine and provides similarly-formatted output, so I assume Flatpak is using curl behind the scenes. $ curl -OL https://mesa.freedesktop.org/archive/glu/glu-9.0.2.tar.xz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 162 100 162 0 0 516 0 --:--:-- --:--:-- --:--:-- 515 100 425k 100 425k 0 0 296k 0 0:00:01 0:00:01 --:--:-- 1076k Perhaps it is something to do with sandboxing used by Flatpak, interfering with the ability of curl to find its SSL certificates?

Here's a job on Freelancer.com (formerly Rentacoder.com) where somebody wants a programmer to create a very simple OpenGL demo rendering a single piece of terrain. https://www.freelancer.com/projects/opengl/opengl-tutorial The average bid so far is $522. Consider how long it will take you working at Burger King to save up a spare $522 to spend on a programmer to write code for you. Then consider how much more complicated it is to create an entire mod, vs writing a simple OpenGL tutorial to render a single object. This will give some idea of how much money you would need to save to make this in any way viable. And this is just the bottom dollar bidder on Freelancer.com who will do the least amount of work possible and produce absolute garbage code just to get the lowest bid in. To have the work done properly you'll be looking at one or two orders of magnitude more money.

I just checked the tarball which can be downloaded from my GitLab repository (https://gitlab.com/orbweaver/DarkRadiant/-/tree/maint/3.1.0) and .gitattributes is not appearing in the resulting archive, so it looks like GitLab at least is honouring the export-ignore attribute.

If a box is easier to implement than a cone, then no problem. The shape probably doesn't matter too much, what's important it is that it is a volume not just a single line. I don't think the volume itself should handle obstructions, since it would be tricky to work out if an obstruction is actually blocking the blackjack or just an irrelevant intrusion into the edge of the volume. Quite possibly you would need a ray trace in addition to the volume: i.e. the volume is used for AI head positioning, whereas a ray trace is used to check if there is a window or something between you and the AI head. I'll gladly test it out if and when it makes it into SVN and can be tested easily (e.g. with a cvar).

The only person who can answer that question is the person who is actually offering to do the work. None of us can answer in the abstract because there isn't a standard rate for "modders for hire", and the scope and complexity of the task is not well-defined. First you will need to find this hypothetical programmer (or team) who is able and willing to produce the game you want. Then they will tell you how much it would cost and you can decide whether you're willing to pay.

In my opinion it shouldn't be a box or a point trace — that is far too sensitive to aiming direction, as some of the feedback comments are already pointing out. If at any point the instructions involve things like "You are better off aiming at the shoulder blades because they are broader", the implementation is going in the wrong direction. It should be a forward-facing cone (like one of those dog collars to prevent scratching) centered on the player position, and extending forwards. The angle and length of the cone will need to be determined via testing, for example it could be a 90 degree angle extending for 1.5 metres or something like that. If the AI's head is anywhere within this cone, there isn't a wall or other surface in the way, and all of the other alertness conditions are met, the knockout should succeed.

My default position is that pure editor state changes should not be considered part of the undo stack — in other words, if a particular operation would make no difference to the map file on disk if you saved immediately afterwards, then that operation would not be part of the undo stack. Under this criteria, selection changes would not be undoable. The advantage of the above approach is that the "map changed" status can be tied to the undo stack: if (and only if) the stack is empty, the map is unchanged. Although this is an implementation detail that is of little interest to end users. However, there clearly is a case for having selection undoable if certain selection operations are tedious or time-consuming to perform, as has been mentioned with patch vertices. The fact that Blender is making selection undoable indicates there must be a significant demand for it.

Oh, I must have been thinking of 3.1 then, which being an "unstable" release wouldn't be expected to make it into Ubuntu repositories. 2D views, such as the preview image on the Media tab and the main part of the Textures tab, used to show completely white until resized. I haven't actually tested since my Ubuntu upgrade though so not sure if it's still a problem.