greebo

One more pre-release build available in the first post, before 2.13.0 will be posted on the website. I've finished the first implementation of a three-way map merge, allowing to incorporate changes from another map into the active one - by specifying the base version both maps have been started from. This way all the changes that have been made to the loaded map will stay intact, and only the actual changes made to the other map will be applied to this one. Just a quick textual description, before any tutorial is going to be posted eventually. Let's say mapper A takes the map M1 and works on the harbour section of the mission, then saves it as M2. Mapper B took the same map M1 and added a house in a different section of the mission, saving it as M3. When merging M3 into M2, only the house from M3 will be imported into the active M2 map. Including layer changes and selection groups. In case both mappers manipulated the same section of the map, the merger will still try to incorporate the changes, unless there's no reasonable way to do so - in this case the conflicting elements will be highlighted in the map and the mapper is asked to resolve it. By default, no conflicting change will be imported, unless the mapper chooses "Accept this change". The whole thing is meant to form the algorithmic base for adding version control support to DR, most likely in the form of a Git plugin. This is something that has to be discussed though, feel free to share your thoughts.

I'm pretty sure that this is out of our control. DR is using wxWidgets, and the whole point of using that framework is that one gets the native controls of Linux, Windows and Mac - so you're basically stuck with the controls those systems provide for better or worse. Sometimes there's a flag one can set on the controls that might have some impact on how the native controls get rendered: for the wxNotebook control this is basically what we have: wxNB_TOP: Place tabs on the top side. wxNB_LEFT: Place tabs on the left side. wxNB_RIGHT: Place tabs on the right side. wxNB_BOTTOM: Place tabs under instead of above the notebook pages. wxNB_FIXEDWIDTH: (Windows only) All tabs will have same width. wxNB_MULTILINE: (Windows only) There can be several rows of tabs. Apart from playing around with these flags, the only other alternative would be to roll our own and create a custom Notebook-style control, using toggle buttons or whatever. While possible, I'm not really in favour of doing that unless I really have to. Or take a step back and re-think the whole dialog, and whether it's necessary to have all of them in that one place.

That'd be awesome!

Hm, yes. Drawing out a brush and then cutting it up into N steps with a defined height might be something that is feasable for a machine. Maybe it could even be done with a Python script, I think DR has all the functions available in the scripting API. It can only be a basic scenario that's covered by the code, I assume that any machine-generated result will never be something one can be happy with immediately.

Entities are indeed matched by name, as OrbWeaver correctly assumed, so the scenario you describe is actually a problem for the simple two-way diff algorithm which is currently in effect: it would detect the other entity with the same name as a change to the one that has been created in this map. This problem will be solved by implementing the three-way merge pattern, which is what I'm currently working on. This way I can detect what the actual steps were that lead up to the other map which is going to be merged - I can detect conflicts and let the user decide what to do about them. If both maps had entities added that ended up with the same name, this is going to be resolved (by the namespace merge algorithms which have already been in place in DarkRadiant since a long time).

New pre-release build available in the first post, with a couple of changes. @LDAsh should find a few goodies in there.

I just checked, the angle method is used to detect whether vectors are parallel and to calculate rotation matrices from two given angles. I guess these are ok. Do I get this right, that if the error is ~3e-4, the corresponding error is ~0.02 degrees - for floats. In DR all the structures are using doubles, so I'm having a hard time imagining where this could be a problem?

Since DR has so many little features that might be less known than they are useful, I felt like opening a thread to collect some suggestions from the mapping folks. I'd like to have some short one or two-liners that can be cycled through if one wants to read more, maybe after clicking on some small "bulb" icon in the top right of the toolbar. It definitely shouldn't end up as obnoxious as I've seen such tips in other programs, where the popup usually just gets in my way when I just want to do something else, so it should be something that is optional, users can try their luck by clicking on it or not. As an example: "You can increase/decrease the camera movement speed by pressing +/- on your numpad" I'm sure that mappers have some of those to share, and if I can collect enough of these I'd like to integrate them in DarkRadiant.

Getting this to work would pay off big time. I recall doing that once for the TDM source code in Linux, and it was a huge improvement there too. But we were using Scons back then which caused the build to always think it was out of date and one had to recompile everything even if just changing a non-header file - understandably annoying, even with PCH.

VC++ is not a slow compiler, I think it's actually doing pretty good. When I switched from MinGW to VC++ my life became a lot easier. Build times went down even more (by almost one order of magnitude, iirc) when I added the precompiled headers to the heavier projects, like the DarkRadiant main binary, the S/R and Objectives plugins, and the Scripting plugin. It really pays off, you can literally see how it chews through the compilation units much faster than before. Precompiled headers are possible in gcc too, and we should see the same difference when we manage to add it to the CMakeLists. The Linux compilations in my VMs are awfully slow compared to what I'm used to in Windows.

I think 356dfb4e05f1ff6ea7f570376e6a2b4692ad581a was the commit that didn't have Eigen yet. I merged it in the commit right after that.

Thanks, man. I've been rather motivated to do that, obviously that makes a difference. I hope I can make it work with groups and layers too, these are much more complicated to handle. It needs some serious feedback though, that's why I decided to upload a new pre-release with what DR currently has, I hope people try to make use of it, and point out what's missing.

That sounds a bit frustrated. Have you been bringing up these issues before? I've read through those, but except for the first two it doesn't feel like I've read of any of them in the past.

On #5623: Merge Map Feature - import only the changes of another map with the ability to preview and choose: It currently works with two maps only. The one you pick in the dialog will be analysed and the difference can be merged into the currently loaded map. On clicking "Load and Compare" DarkRadiant switches into "Merge Mode", where the changes can be selected only. It's not forbidden to mess around with other nodes and do editing, but DR will try to prevent you from doing that, it's encouraged to only inspect and reject incoming changes. Additions are highlighted green, deletions are red, modifications are blue. Entity key value changes are visible in the Entity Inspector. Each change can be selected and rejected by hitting the button in the Merge dialog or by deleting them using your regular delete keybind (Backspace). Once you're happy with the import, you click on "Finish Merge Operation" which will apply the changes (that have not been rejected) to your map. This operation is undoable, so you can hit Ctrl-Z to switch back before the merge. If you don't want to import anything and maybe just want to have a look at the map comparison, the merge can be aborted anytime without altering your map. It won't merge Layer information and it won't merge Selection Groups. I haven't looked into that yet, it's more involved. Right now, everything that is imported goes into your active layer, iirc. There's more to come. I plan to work on a three-way merge, where editing conflicts can be recognised and resolved. And of course the vision of pushing and syncing your map with some VCS server would be something I'd like to see implemented (not least because I want for my own work).

On #5603: Ability to choose from several different pointfiles (to support the TDM internal leak reporting feature) It recognises the special .lin files which are created by TDM's map compiler to diagnose internal leaks. If there is more than one .lin file available for the current map, the File > PointFile... option will show a list to pick the pointfile to display. If there's only one pointfile available, it will bypass the dialog and work as in previous builds.

Here's the DR 2.13.0pre3 build for every interested mapper to test. For more things that have changed or fixed, see the list below. Download Windows Portable x64: https://drive.google.com/file/d/1cLLk3L44W-53dEn4Ax7HX-3r3Rm4dmrC/view?usp=sharing Download Windows Installer x64: https://drive.google.com/file/d/1gPMjVFci8w8yk0ZpdCSWNqIHj2JNtosB/view?usp=sharing Linux folks need to compile this stuff from source, instructions for various distributions are on the wiki. If you happen to run into a crash, please record a crashdump: How to record a crashdump Changes since 2.12.0 can be seen on the Bugtracker changelog, here's the summary: #5623: Merge Map Feature - import only the changes of another map with the ability to preview and choose #5603: Ability to choose from several different pointfiles (to support the TDM internal leak reporting feature) #5628: Some ASE models do not load #5620: Prefabs importing miles away #5608: Path entites rotate 15 degrees, each time when dragged. #5555: Crash when activating GameConnection Feature "update entities on every change" #5609: Model previewer not displaying ASE or LWO models #5607: Crash when selecting an MD5 model in "Create Model..." menu #5602: Crash when activating the Material Editor in Doom3 game config Changes since 2.13.0pre1 #5639: Support Layers when merging Maps #5638: Support Selection Groups when merging Maps #5642: Entity & Speaker windows don't remember their size #5632: Restore non-uniform scaling for texture browser #5634: Paste material-header to surface from clipboard with hotkey #5637: Increase maximum zoom level of 2D views #5629: "Shift textures randomly" shifts all selected faces by the same amount #5621: Display editor_usage in the Entity Inspector window when "classname" is selected Changes since 2.13.0pre2 #5561: Refresh entity inspector when reloading defs #5107: 'Change game/project' fails to save if a decent-sized .map was loaded #5652: Reload Defs is messing up the entityDefs #5651: Crash when using Reloading Defs after placing an Entity #5557: “Choose entity...” button for all def_ spawnargs #5649: CTRL-MMB in orthoview: place camera at height of most recent selection #5650: Add "Show Material Definition" to ShaderSelector tree views #5643: Three-Way Map Merge #5634: Paste material-header to surface from clipboard with hotkey. #5635: Selection by coords possible through the console or scripting Thanks for testing, as always!

You could select one of the faulty models, and then use the script "Select all Models of same Type". Does that work for you?

The current script doesn't do this? If not, just put in on the tracker, it sounds like it could be an easy fix.

Maybe that light has a weird rotation matrix applied? Like one that is mirroring the light planes?

There's a script in the main menu which can shift textures by a random amount. Don't know if it's cutting it for you, but it might be worth a shot.

I created accounts for the both of you, you should have mail.

Nothing happens immediately when you change the .map file on disk, DR will not care and continue working with what you have loaded into memory. In one of the recent versions, I forget which one, a safeguard has been introduced: once you hit "Save" DarkRadiant will warn you if the file has been changed in the meantime, possibly by some other process like git or a text editor. You can choose to overwrite or cancel (and save it somewhere else if you need to). When I decide to update the working copy using Git on my end, for instance pulling a change from her laptop to mine, the map file will obviously be changed (which I expect to happen, no problems there). Still, I often had the thought that it'd be nice to have a small status indicator in the toolbar, such that I can see that the .map file has been altered by something other than the current DarkRadiant session. (An option to have those changes automatically integrate the changes from that file to my loaded version is a concept I'm currently trying to prove to be working.)

While it's very interesting to have the predictable discussion about which is the only true way to use git correctly, my original intention before opening this thread was of course more directed towards getting some input about DarkRadiant and maybe what basic functions need to be added to make the VCS benefits more easily accessible to mappers, and/or to make collaborating with other members on the same map file a smoother experience. Obviously, even with the current state of DR development it's possible to use a VCS to make mapping work more secure or more collaborative, but what functionality would make life easier?

Done, you should have mail.

Yes, the downside of the VCS integration is that folks need to learn their way around them - learning Git is something I saw quite a few programmers fail at, so I'm kind of afraid that mappers might not buy into it because of the entry barrier. Mapping itself is full of learning curves, having to work with something like Git might break one's back. Whatever tool support we have, a tutorial-like wiki article would definitely be helpful, I totally agree with you on that.