greebo

The wxAUI framework we're using for the docking is a bit limited, it appears. It's not possible to drag windows/panes in and out of wxAuiNotebooks, which would make things very flexible. The windows like the Console or the Texture Browser would need a different way to be converted to dockable panes.

I think the drop indicators are out of my control, they are subject to the platform wxWidgets is running on. But I'm open to suggestions, if anyone has ideas on how to improve the hierarchy arrangement.

Pushed the changes to master, feedback is appreciated.

Hm, I might try that to see if it feels intuitive.

Gotta love these little platform-specific differences. The wxDataViewEvent sent in wxGTK is not delivering the correct column, so the event handler is not reacting. I rewrote the event handler in #6130, the checkbox should work now. About the drag-and-drop: this is another problem that seems to affect wxGTK only... in Windows, I can drag the layer to the top border of the view and it will deliver an empty target wxDataViewItem, which means make it toplevel - in wxGTK it doesn't seem to be possible to drag it to the top.(*) I can think of two possibilities right away either restrict the system such that the Default layer can never have child layers. Dragging a layer onto the Default layer will make the dragged layer a top-level layer Add a context menu item called "Make Top-Level" I don't like either of the two very much. Suggestions? (*) Yes, there's a guard in the wxGTK event handler: wxDataViewItem item(GetOwner()->GTKPathToItem(path)); if ( !item ) return FALSE; this prevents any empty item from being forwarded to the event.

I just pushed a fix to issue #6129 to github, I think it'll be working now I wish I could do something about it... I have no machine with an AMD card around, neither at home nor at work, or anybody I know.

DarkRadiant 3.4.0 is ready for download. What's new: Feature: Allow Layers to be arranged into a Tree Fixed: Readable Editor displays "shader not found" in view Fixed: Undoing snap to grid with prefabs causes crash Fixed: Include doc in building instructions Fixed: Decal textures causes DR to crash - (textures/darkmod/decals/dirt/long_drip_pattern01) Fixed: Skin chooser: double click on materials list closes window Fixed: Selecting and deselecting a filtered child brush through layers leaves the brush selected Fixed: Material editor re-sorts stages on pasting image map resulting in wrong material stages list and wrong selected stage Fixed: Crash on start if engine path is choosen (Doom 3) Feature: Layers can now be arranged to form a hierarchy Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.4.0 and of course linked from the website https://www.darkradiant.net Thanks to all the awesome people who keep using DarkRadiant to create Fan Missions - they are the main reason for me to keep going. Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. The list of changes can be found on the our bugtracker changelog. Have fun mapping!

I don't recall changing anything in that regard, I didn't rename or change anything between these two releases. But it's easy to click on one of those toggle buttons by mistake, I'm doing that myself here and then.

Is this option enabled on your end?

That's an interesting suggestion. It's possible for modules to add settings to the pref pages, but only simple stuff like checkboxes and dropdowns. Having a way to integrate more complex modules like the mouse binding editor would require some work, I guess. But I like the overall idea of having the mouse bindings integrated with the rest of the settings.

It must have interfered and locked the file, that's my guess. Kudos to you for being fearless and compiling from source.

Sorry, I meant that package: libwxgtk3.0-dev There's usually only one wxgtk dev package in every package manager, so yes, that's the correct one. It should work fine though, so I can't tell you exactly why it's not linking. Maybe make clean and a full rebuild helps. I could recompile just fine in my Debian 10 machine, with all the aptitude stuff upgraded to the latest version (though I remember having to set the --allow-releaseinfo-change option when using apt-get update) Upgrading is probably a wise choice, but that's up to you.

Not sure I can do anything about the linker problems, that's something that seems related to the deb packages. Do you have the libwxgtku3.0-devel packages installed correctly? It links fine on my Deb10 machine.

I hope I've fixed all compilation problems in Debian 10 now, see latest master.

The Debian 10 package of libgit2 is 3 years old and the libgit2-Team introduced a lot of new functions since then, deprecating old ones, that's why it fails so hard. I've been trying to get it to compile, maybe it's just a few preprocessor #IFs. I also spotted a couple of other compilation problems in Debian 10, which are mostly due to missing #includes, I intend to sort that out.

I pushed a fix, I think this should do it. It's interesting that this compilation problem doesn't arise on the Ubuntu machine that is used to automatically compile the source in Github after every push. I usually get notified when gcc compilation breaks by the build process. libgit2 is used for the optional VCS plugin, it's not a deal-breaker if it's not present. Nonetheless, I've included the synaptic package on the wiki page. edit: pushed another VCS build fix. My Debian 10 machine has been using 3-year-old libgit2 headers.

Some include seems to be missing, I'll try and fix it.

Thanks, I've added libeigen3-dev to that section. libgtest-dev should already take care of the gtest dependency, but this didn't work for you it seems?

Sync or pull doesn't restore any files that have been locally deleted. You need to use "Git > Revert...". (Or alternatively Git > Checkout "master" (with force) or Git > Reset (hard) to restore your working copy to a committed revision.) The repo-browser is ok to restore specific files manually, but Git > Revert is better.

The file should be there in radiantcore/patch/PatchConstants.h. Can you confirm?

Please open a bugtracker entry for this, I assume the parser needs to be adjusted to handle the rect-100. It's entirely possible that this is a regression of some sort.

I don't think that the file has problematic code in it, but I can't prove it to you. I'm afraid these positive detections happen every now and then, something is triggering the scanners. Uploading the sound.dll file to the online scan services shows this: https://www.virustotal.com/gui/file/7fe3607c7dd33cfee7cef53d0ccbdd3142a9f8860cfe24d639c4be043136c4dc It confirms that BitDefender doesn't like the file, for what it's worth. I could look into creating a checksum of the uploaded files next time I create a release, but this doesn't really add much value other than you're being able to prove that the file's the same as the original on my system. If the sound.dll gets infected on my machine while I build the release, the checksum would still be matching. One could make sure and compile DR from source code, to rule out anyone messed with the released files on my computer or on Github.

This is fixed in source now

I can confirm the problem with the vanilla D3 resources, the parser is running into a bug in the pak0005.pk4/materials/patd.mtr file. Issue: https://bugs.thedarkmod.com/view.php?id=6108

There is a lightscale setting in the .game file, which can be used to make lights brighter or darker in DR's render view. Not sure how this could help when exporting scenes to other engines, but that's about the only thing we have here to adjust light brightness globally, other than changing every light in the scene. See for example doom3.game, Line 133: <lightScale>2</lightScale>