OrbWeaver

I don't think you can use OpenGL at all on M1 macs (natively). Anyone who wants to make that port is going to need to write a complete Metal replacement for the renderer.

This does seem to be the cause of the problems. Replacing all calls to FindPage() with GetPageIndex() fixes the issue for me.

I've done more debugging, and it seems like it is FindPage() that is failing for reasons which are unclear. It even fails immediately after the page is added in addControl(), i.e. bool succ = AddPage(content, control->getDisplayName(), false, tabIconIndex); wxASSERT(succ); // succeeds wxASSERT(FindPage(content) != wxNOT_FOUND); // FAILS I guess this means one of two things: A bug in Ubuntu's wxWidgets 3.0.x package (it wouldn't be the first time), or the GTK wxWidgets build more generally. A false assumption in our code about when/how wxAuiNotebook::FindPage() is able to work. For example, perhaps it only works once the AUI interface has actually been displayed on the screen, rather than during the setup process. EDIT: I wonder if it is this bug: https://github.com/wxWidgets/wxWidgets/issues/15932 I can armour restoreState() against passing an invalid index to GetPage() and friends, which avoids the assertion, but then I have multiple copies of every tab in the group widget. On the other hand, I can completely disable the contents of restoreState() and everything looks fine with all tabs present and correct (although I presume any changes to tab layout wouldn't be preserved), so I wonder if it's even necessary for restoreState() to add new tabs at all?

It looks like GetPageCount() and GetPage() are working with size_t indices which (on Linux) are equivalent to unsigned int, so I guess this is wrap-around behaviour. Yes, it's very strange that the index should be -1 immediately after the page was added — I'll do more debugging and see if I can find out which function call isn't working as expected.

I'm also seeing an assertion failure, although it doesn't seem to have anything in common with what other people have posted. This appears at startup before the main window is shown, and appears to be fatal (attempting to Continue just produces the same assertion again). ASSERT INFO: ../src/aui/auibook.cpp(2270): assert "page_idx < m_tabs.GetPageCount()" failed in GetPage(). BACKTRACE: [1] wxAuiNotebook::GetPage(unsigned long) const [2] sigc::internal::signal_emit0<void, sigc::nil>::emit(sigc::internal::signal_impl*) [3] sigc::signal0<void, sigc::nil>::emit() const [4] module::ModuleRegistry::loadAndInitialiseModules() [5] radiant::Radiant::startup() [6] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [7] wxEvtHandler::SearchDynamicEventTable(wxEvent&) [8] wxEvtHandler::TryHereOnly(wxEvent&) [9] wxEvtHandler::ProcessEventLocally(wxEvent&) [10] wxEvtHandler::ProcessEvent(wxEvent&) [11] wxEvtHandler::ProcessPendingEvents() [12] wxApp::DoIdle() [13] g_main_context_dispatch [14] g_main_loop_run [15] gtk_main [16] wxGUIEventLoop::DoRun() [17] wxEventLoopBase::Run() [18] wxAppConsoleBase::MainLoop() [19] wxEntry(int&, wchar_t**) [20] __libc_start_main More info from LLDB (since the built-in stacktrace seems to miss out a lot of function calls): frame #10: 0x00007ffff6a9eeca libwx_gtk3u_aui-3.0.so.0`wxAuiNotebook::GetPage(unsigned long) const + 106 frame #11: 0x0000555555d4f768 darkradiant`ui::PropertyNotebook::restoreState(this=0x000055555611c490) at PropertyNotebook.cpp:264:34 frame #12: 0x0000555555d3f7b6 darkradiant`ui::AuiLayout::restoreStateFromRegistry(this=0x0000555557179c10) at AuiLayout.cpp:654:36 frame #13: 0x0000555555d46817 darkradiant`ui::MainFrame::construct(this=0x00005555560c53a0) at MainFrame.cpp:271:38 frame #14: 0x0000555555d46680 darkradiant`ui::MainFrame::postModuleInitialisation(this=0x00005555560c53a0) at MainFrame.cpp:211:11 frame #15: 0x0000555555d4c024 darkradiant`sigc::bound_mem_functor0<void, ui::MainFrame>::operator(this=0x0000555556cd1258)() const at mem_fun.h:1991:48 frame #16: 0x0000555555d4ba80 darkradiant`sigc::adaptor_functor<sigc::bound_mem_functor0<void, ui::MainFrame> >::operator(this=0x0000555556cd1250)() const at adaptor_trait.h:256:20 frame #17: 0x0000555555d4b22c darkradiant`sigc::internal::slot_call<sigc::bound_mem_functor0<void, ui::MainFrame>, void>::call_it(rep=0x0000555556cd1220) at slot.h:483:35 frame #18: 0x0000555555aec9e2 darkradiant`sigc::internal::signal_emit0<void, sigc::nil>::emit(impl=0x0000555556a31300) at signal.h:798:79 frame #19: 0x0000555555aee4a8 darkradiant`sigc::signal0<void, sigc::nil>::emit(this=0x0000555556163398) const at signal.h:2804:32 frame #20: 0x00007fffeba2acfb libradiantcore.so`module::ModuleRegistry::loadAndInitialiseModules(this=0x0000555556163320) at ModuleRegistry.cpp:192:32 frame #21: 0x00007fffeba8bc87 libradiantcore.so`radiant::Radiant::startup(this=0x00005555562af760) at Radiant.cpp:97:58 frame #22: 0x0000555555be315f darkradiant`RadiantApp::onStartupEvent(this=0x00005555560a4660, ev=0x00005555562dc8d0) at RadiantApp.cpp:230:30 This is the actual line of code which fails in PropertyNotebook.cpp. It seems that existingIndex is actually -1 here.

I don't see how DoF can possibly work in a game which isn't tracking your eyes. How does the game know what you are looking at? Your eyes could be focussed anywhere on screen, which might show objects at a variety of distances. If the depth is taken from the central aim point, that means that instead of just moving your eyes to look at something on screen, you'd also need to move the mouse to remove the artificial blur. DoF looks nice in photos, and as stgatilov says it might work in a VR simulation with eye tracking, but for a 2D image on a standard screen I can't see it adding any value.

I'm a big fan of Rust. It's an well-designed language with excellent tooling. But it doesn't have great GUI support yet (although there are a few toolkits available), and integrating it into a larger C++ application is non-trivial (although possible). Designing a new loader from scratch in Rust with an Electron-based front-end — that might actually be possible, although it would probably need somebody with more than my beginner-level Rust knowledge.

In addition to what Greebo says about the center view, note that you can freely dock floating widgets on the right as well as the left (or the top or the bottom). Just drag them into position and you will get a visual cue when they are ready to be docked.

An excellent step forward. After the recent discussion in one of the newbie threads about limitations of the dockable layout, I was actually wondering whether and when should look into this, but you're way ahead of me as usual.

What do you use to drag out a new brush?

I actually had a go at this myself once, but found it far too difficult. Personally I too hate the default input style, particularly the requirement to constantly hold down modifiers just to select things, but changing the defaults just breaks too much stuff because the selection system isn't designed to work that way. In order to allow "normal" selection rules, we would also need: A different method to create a new brush (since left-drag is now a selection or manipulation operation), for example something like Blender's Shift+A shortcut. A different way to resize brushes. Currently dragging anywhere outside the brush performs a resize, but if clicking/dragging on empty space is supposed to define a new selection, this will no longer work. So we would need something like traditional resize handles instead of the planar dragging approach. The selection system to decide what operation is being performed after the initial click or drag starts (as Greebo already mentioned). [Optional but almost certainly necessary] A system for setting up alternative keyboard profiles so people could choose between classic Radiant selection or the new system, since not everybody would agree with the changes.

The odd thing is that GTK itself can clearly distinguish the two cases, because I see different "drop destination lines" when dragging to the top of the view (one line above) versus dragging onto the first layer (one line above and one line below). So wxWidgets itself is actually swallowing up the event, even though it would actually be useful and consistent with the Windows behaviour, and the purpose of wxWidgets is for creating cross-platform UIs? I can't really see the logic of that, but I guess it was probably introduced to fix some bug without really considering the consequences. My suggested UI would be to add a couple of buttons (which are more discoverable than a context menu), perhaps next to the existing rename and delete buttons since the New button already has more than enough width. One button would move the selected layer up by 1 in the hierarchy, and the other would move it all the way to the top.

To be honest I can't remember ever using TAB to choose between items in a group. I certainly wasn't aware of it when writing the user guide, which is why the section on converting to func_static mentions using TAB, but the section on grouping doesn't. But it would certainly be useful and consistent behaviour.

I can reproduce this. It doesn't surprise me much since these legacy GtkRadiant layouts are hardly maintained or tested these days. I recommend using the Dockable layout instead and dragging the dock windows to the positions you want. I also see the checkboxes not doing anything. Drag and drop partially works for me, although I can only create a parent relationship. I cannot find a way to unparent a layer and bring it back to the top level. I think the Dockable layout would avoid that problem too (because the media browser would no longer be a top-level window).

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.