OrbWeaver

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.

Do you still get the render issues in the texture preview window (i.e. the view is entirely white until you resize or force a render in some way, after which it works correctly)? This was always a problem with the 3.0 wxWidgets packaged with Ubuntu. I've been thinking about wxWidgets version recently because I upgraded to Ubuntu 22.04 last week and they are still packaging wxWidgets 3.0, even though 3.2 has been out for a long time. I'm wondering if we need a way to build using a local newer version of wxWidgets that we can include without needing to rely on the distro packages (e.g. with an optional Git submodule). Although if you're getting crashes with 3.2 it sounds like the upgrade might not be as simple as I would have hoped.

I've set the export-ignore attribute on .gitattributes itself, so I guess we'll see if this makes any difference to what GitHub produces. Another possible source for the tarball would be the one attached to the Ubuntu package, which is effectively a "pristine upstream" tarball since I am generating that package myself without any Ubuntu-specific patches. It would also be (indirectly) signed as part of the PPA publishing process. However I don't know if you or Debian would have a problem with basing a Debian package off an Ubuntu package source, since it's usually the other way around.

Yeah, the anaglyph stereo effect is fun for looking at a few 3D objects in picture books, but I wouldn't want to play a whole game using it. The weird inconsistent eye colour really detracts from the image quality.

I don't think the preferred solution would be to remove .gitattributes from source control — even if its contents aren't strictly required now (which I haven't investigated), a permanent requirement to never have a .gitattributes would be somewhat restrictive since we might need its functionality at some point. The problem is that the file is appearing in the tarball, which is unnecessary and undesirable. The first thing to do would be to set the export-ignore attribute on .gitattributes itself, which should cause it to be excluded from any git archive command. I have no idea whether this will affect the automatic tarball published by GitHub, but if it doesn't, presumably it would be feasible for either us (upstream) or coldtobi to create a tarball explicitly using the git archive command from the repository.

I think people are getting hung up on the question of whether the nation of France existed, which is actually irrelevant to this discussion because in the TDM world, none of the real-world nations actually exist with their real names and political histories. Nor does it matter whether "Britain" existed, because Bridgeport is never described as being in "Britain". The question is whether the geography and climate of (what we now call) southern France match the areas which are presented in game. It seems to me that Bridgeport is modelled more on a port city of medieval England (which certainly did exist geographically, regardless of what the country was called or who ruled it at the time). But I guess you don't really perceive temperature in-game, and most missions take place at night in a small area of the city, so it could be pretty much anywhere in (what we now call) Europe.

I actually had no idea that the in-game world was supposed to map onto the shape of real-world continents. I always imagined it was a pure fantasy world like Westeros or Middle-Earth.

I agree. The Hammer interface looks like a much better way of presenting this functionality. Blender also does a good job here — in fact they recently got rid of their "Layers" functionality altogether and merged it into the Outliner/Collections window.

Yes, that was it. I never even realised there was something to pick up in the vault after the "fade to black" sequence.

Yeah, having a completely independent timer seems like a recipe for desychronisation problems. Probably what I'd do is: If the display frame rate is less than or equal to the cap value, just enable vsync and don't do any manual synchronisation — it's not adding any value beyond what vsync does naturally. If the display frame rate is greater than the cap: After a frame is actually displayed (i.e. vsync is completed and the buffer swap has happened), store the current time in a variable. When the next frame is ready to be shown, compare the current time with the value stored in the previous step. If not enough time has elapsed, pause for the required number of milliseconds (or slightly less) before displaying the next frame. Of course this assumes that there are suitable platform-specific methods to obtain the actual display frame rate. I can imagine this might be problematic on Linux given there are two different display servers and several desktop compositors in use. Perhaps the quick and dirty solution on Linux is just to enable vsync by default, then disable the frame rate cap by default (since vsync will take care of it)?