greebo

If it's just appearing as point, can you confirm you've appropriately zoomed in? In the video above, I notice you're almost completely zoomed out with coordinates around 8k to 16k. That's awfully large, a prefab is usually just a few dozen units.

By the way, was this performance issue fixed? No. I can't just remove that code, it is the workaround that has the func_static brushes written properly to the map format, since the engine map loader expects them to be saved relative to its parent entity. I recall placing that hack more than a decade ago, since DR at that time wasn't able to deal with these entity-grouped brushes, they were not rotating correctly. I wasn't able to fix it back then, so I put in the workaround to move the brushes around before and after map saving such that they are saved as the engine expects them. I agree that it's a hack, but fixing it properly isn't exactly trivial. There are a few saving and loading tests, but there is no coverage of saving and loading func_static brushes yet. I can't comment the GUI part, since I don't know what half of these options are doing. But it's certainly possible to pack it into a floating tool window like the AAS Area Viewer or the Surface/Light/Patch Inspectors.

Sorry for not replying earlier, but it seems you already took the initiative to implement a layer manager ScriptInterface. Scripting in DR is heavily under-used, that's probably the reason nobody noticed the lack of that functionality. Do you have a patch or pull request for me? I'm happy to integrate or expand the interface you created.

I've been involved in creating and expanding TDM up until 2012, and I've been working on DarkRadiant for the past 14 years (but DR might not be that interesting for a Thief-themed podcast). Anyway, I'm not a native speaker, and I've been focusing on the technical aspects of the mod - when it comes to game design or overall questions about what drove the team, I think Eric @Springheel or Tim @New Horizonmight be better picks. I'm definitely around if anybody has questions about the first 6 years of TDM though.

Thanks

I ran into the same issue and pushed a new set of windeps binaries to my repository. I was planning to publish a new release soon, so people get the new download link, but in the meantime you can use this one: https://drive.google.com/file/d/1EAdIi0e90jhZtANWge6vyLmrVe8vg88b/view?usp=sharing Extract it over your repository clone, replacing any files.

I'd prefer to have this implemented, it should provide enough warnings for a mapper to not overwrite the existing map file with outdated data. @HMartCould you please open an issue tracker entry with the request to add overwriting protection of newer files?

Sounds very nice, I already saw your commits and the cmake files look so much less complicated than the makefiles, I'll definitely shed no tear when we get rid of automake. And I can relate to your comment about the automake docs - whenever I tried to look up a configure or makefile problem I either found nothing or it was not applicable to our setup. Not a single good tutorial getting you up to speed. One often ends up reading other projects' makefiles in the hope of finding anything useful there. And I might add that I find the use of mailing lists to get support was probably cool in 1992. I've recently subscribed to the GNU autoconf mailing list to get notified about a AC_CHECK_LIB problem and now I end up deleting 3 or 5 unrelated messages from my inbox every day.

I see. I hope you could recover some stuff from the .bak file that is created from before a file is overwritten? I think there are some ways to add safeguards or warnings to make that less likely to happen. What most text editors are doing is (I assume) adding a file watcher to the target file and/or checking the modification date of the file they're writing to. Even without modification date comparison or watchers, it'd be possible to introduce something like a version counter in the .darkradiant file, that could be checked by the instance before saving to the map. If the version counter was different to the expected value, DR could issue a warning that it thinks the file has been modified in the meantime. That doesn't cover modifications in a non-DR application like text editors though. Lastly, it'd be possible to add some platform-dependent code detecting other running instances of DR and checking whether one or more of them are working on the same map. Technically the most difficult option I guess, but not even 100% safe since files could also be modified through the network or other applications.

Should be working again

Might be the cubic clipping setting which might hide the prefab if it's too far from the camera.

Ok, what was your installation experience with siduction like and how long have you been running siduction? I've failed two times now trying to install it and update it to the latest packages - the installation medium is from 2018, and it's full of old packages. Running updates / dist-upgrades (downloading almost 1.5 gigabytes of new sid packages everytime) etc. manoevred my system into a state where I cannot get past the login screen anymore (I can only log in through the Ctrl-Alt-F2 TTYs). It happened twice now, and I don't know what I could have done wrong, didn't find any solutions either. This is really frustrating. I've seen quite a few distro installations and installers in the meantime, Debian, Fedora, Gentoo, Slackware, Arch, openSUSE, Mageia, countless Ubuntus - but this is by far the worst of it all.

Hm, everything sounds pretty normal to me. The wxWidgets version of your system can be seen in the Help > About dialog, but I assume it's something like 3.0.4 or 3.0.5, since the debian package is referencing those. There is a newer DR 2.9.1 package for Debian sid: https://packages.debian.org/sid/darkradiant - is this available for your distro too? Apart from those things, I don't have any idea what might be going wrong. I'd need to set up that distro of yours in a VM to check it out myself.

Ok, ok. I need to know more about your setup. Which DarkRadiant version are you using, and where did you get it from? Did you compile from source? What wxWidgets version is it built against? Are there any other steps you had to perform before you got it running? This is running on an actual PC, I suppose, or are you perhaps using a virtual machine? Any warnings in the console, or the command line? I know nothing about that distribution, but if it's Debian-based, it should work in principle.

It seems the crosshair is appearing in the middle of the camera view, which means that you entered the free look mode. But it seems, you aren't able to rotate the view using the mouse, is that correct? Is there something to see in the map in the first place? The ortho views seem terribly empty to me.

Yes, as a last resort this is definitely an option. I'd like to avoid it as long as possible though, since it puts more maintenance work on our shoulders. Would that be even compatible or allowed with the Debian packaging? (In Windows we're indeed shipping the wx binaries along with DarkRadiant, since there's no package management - though I'm not compiling wxWidgets from source, I'm using the public releases (currently it's 3.1.3 since that includes binaries built with Visual Studio 2019). I still have to compile the libraries like libpng, libxml2, libzlib, freetype, ftgl since some of them don't or at least didn't provide any Windows x64 binaries.)

Yeah, I even tried calling SetSashPosition(GetSashPosition() + 1) followed by SetSashPosition(GetSashPosition() - 1), but to no avail. At least there's the silver lining that wx3.1 will get published as stable release sooner or later. Rather later, since the wx team endures long intervals even between minor releases. The project is really alive (which is good for DarkRadiant), but hey, 3.1.0 was published in 2016, and now we're at 3.1.4.

Added an additional Update() call in the TexturePreviewCombo and the TextureBrowser, specifically targetted at wxGTK 3.1.2 and earlier. I failed to find anything that could force an artifical size or redraw event, so I'm going to leave it at that.

I tried doing it as the docs describe, calling Refresh(false) + Update() afterwards, and it changes the behaviour to be almost correct. With that refresh/update combination, the GLWidget will receive Paint events after the window resize event and it appears to work fine after overcoming this first glitch. Yes, exactly this. I compiled a debug build of wxWidgets to see where this is coming from, and after switching back from another application this is happening in the course of idle event processing. It's all bound to the "draw" event that is fired by GTK3+. The same happens when you resize the splitter window - it invalidates some stuff and then the ide processing will issue the OnPaint event. Reading the wxGTK sources and investigating why this event is not fired immediately, there is some custom expose handling and an "m_exposed" flag in the GLCanvas implementation (it's set to true in the "draw" event handler). The wxWindowGTK::Update() method should trigger a "draw" event by calling gtk_widget_queue_draw_area, but an if-else construct is preventing that from being invoked, so I agree that this is a combination of changed GTK3+ expose behaviour as well as problematic wxWidgets processing code. Digging further, I saw that all that custom processing code has been removed in 2019. This is not in wx3.0, but part of wx3.1, so I compiled from latest git and voilà, the problem is not happening there. So, with wxGTK 3.0.x it seems the change to call Update() immediately after Refresh() will improve the behaviour, such that it paints after switching between apps or resizing the splitters. And in wx3.1 the problem is not present at all, whenever that branch will be released. It's been worked on for years now, so that might still be a while. I'll do some more digging to see if I can artificially trigger that first paint event by force, otherwise I'm going to not spend any more time on that.

This appears to be pretty close. I set some rConsole output in the TexturePreviewCombo::draw() method, and it is never invoked when selecting different shaders (even though _glWidget->Refresh() is called, which should trigger an OnPaint event.) When resizing, lots of console lines are printed. I already tried experimentally changing the _glWidget->Refresh() to _glWidget->Update(), which should do an immediate paint, but this doesn't help.

When using the older wxWidgets 3.0.4 in Ubuntu 20.10: problem persists Whereas in Ubuntu 19.10, where the problem doesn't occur: compiling against the newer wxWidgets 3.0.5: problem occurs I had to compile wxWidgets 3.0.5 from source in Ubuntu 19.10 and install the libgtk-3-dev package - maybe that's connected to the problem. I'll try to find out what the native Ubuntu 19.10 wxGTK 3.0.4 is compiled against. edit: the package seems to use GTK3.0, so using libgtk-3-dev should be ok.

This issue has been occurring in the last few weeks, and my first thought was that it is due to a regression that happened during the code reorganisation and the necessary changes to GL context handling. In my Ubuntu 20.10 machine I walked back the git history up to the point of the DR 2.8.0 release, but as it turns out, the problem is happening there too. When switching between Media and Texture tabs, the GL widget is not refreshed, unless you resize the tabs using the splitter between cam and orthoview: So I launched my other VM running Ubuntu 19.10 and was rather surprised that this problem does not happen there, even with the latest git checkout: I'm not sure where this behaviour is coming from all of a sudden. While I can't rule out that DR is doing something wrong in terms of context handling, there sure seems to be a difference between the two Ubuntu 19/20 setups. Any suggestions on how to go ahead and find out where the problem is rooted? The one idea I have: Since Ubuntu 19 is using wxGTK 3.0.4 and Ubuntu 20 is using the latest wxGTK 3.0.5, I will try to compile the older wxWidgets 3.0.4 release from source and use that in the newer Ubuntu 20 version, to see if the problem goes away.

Yes, all versions share their settings, but I think in 2.9.0 it was introduced that DR saves its settings to ~/.config/darkradiant instead of ~/.darkradiant, so that might explain any difference in behaviour you might see.

This is something that is observed in all Linux distros by now. I'm curious if this has been introduced in 2.9.x recently? I have to check out earlier sources and see whether this is something new.

Nice, thanks for the confirmation!