Jump to content
The Dark Mod Forums

greebo

Root
  • Content Count

    16206
  • Joined

  • Days Won

    12

Everything posted by greebo

  1. 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.
  2. 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.
  3. 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.
  4. 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 t
  5. 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.
  6. 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.
  7. 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 r
  8. 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.
  9. 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.
  10. 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 t
  11. 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.
  12. 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.
  13. Ok, I think I got it fixed now. Here's a pre-release build, can you please give it a shot? It's a portable version, you can just extract it and use it from there. DarkRadiant 2.9.2pre2 In this version you should be able to change the brush colour and see the changes in the preview too.
  14. This is what I got: I managed to get the blue fallback colour, so I can look into a fix now.
  15. Thanks. It confirms that there is indeed no worldspawn entityDef defined anywhere, which makes me wonder how your game is working. The target engine is Q4, isn't it? Anyway, I'll try to replicate that setup on my machine.
  16. The colour for unselected geometry should indeed be the one in the Colours dialog, it just doesn't seem to take effect on your end and I need to find out why. (I know that it might be frustrating, since 2.8.0 worked and 2.9.0 does not, but I cannot just revert things since I would lose the fixes I need for other the TDM game setup, which is the main focus for DarkRadiant. We'll find a way to make it work for you too, I just need some more info.) Can you paste that in the Script tab input field in DR and hit "Run script", please? It should print the effective value of the worldspawn e
  17. What's q4base in that screenie? Is that a Quake 4 installation? If yes, it might contain an entityDef with the editor_color spawnarg set that DR might be able to use too.
  18. Oh wow, that's a Quake .def file? Looks completely different from what Doom 3 is using. (I never had any Quake in my hands, so I don't know anything.) It doesn't show any default values in the entity class tree, it seems, and I think that's why it falls back to a blue value - it's the hardcoded default in DarkRadiant for entities that don't define any editor_color in their .def - that might explain a few things, since I added a fix to DR 2.9.0 to respect the colourscheme setting , but obviously this is not working in your case. Since your worldspawn is not defining any colour, it seems DR
  19. One more thing: can you please open the menu option Entity > Entity Class Tree... and show me the worldspawn entity (type "worldspawn" to highlight it in the tree). I'd like to see the spawnargs it has defined, especially the editor_color spawnarg. (The entityDef in your project can define a default colour for any primitives below that entity.)
  20. What do those files look like? Can you show me the contents?
  21. Almost! I'd like to have all .xml files in the folder, please, especially the colours.xml file.
  22. First, there is a newer version 2.9.1, that should fix a freeze when saving during shut down, which you might want to get. But you can upgrade whenever you feel like it, there's no change with regard to the colours. Speaking of the colours, can you give me another dump of your settings files in AppData\Roaming, please? You're saying the brushes stay blue even though the "Brushes" are set to black? edit: tracked in https://bugs.thedarkmod.com/view.php?id=5430
  23. I'm seeing people running into messed up colour schemes when upgrading to the 2.9.x branch. Could a few of you who are still on on DR 2.8.0 send me a zip package of their user data folder in C:\Users\<user>\AppData\Roaming\DarkRadiant, please? Ideally these files are from before you touched 2.9.x, that'd be perfect. I'd love to have a few configs to be able to check the colour loading and upgrading process when upgrading to 2.9.x.
×
×
  • Create New...