Jump to content
The Dark Mod Forums

greebo

Root
  • Posts

    16732
  • Joined

  • Days Won

    50

Everything posted by greebo

  1. Don't bang your head against this, unless you really want to. You don't strictly need the unit test project to use DR you compiled from the sources. Sounds like VS2022 has some minor difference in the google test handling, the DR solution probably has to be adjusted for that.
  2. Well, maybe the path of the header file got changed, who knows. I'll have a look at VS2022 sooner or later, but right now I don't feel like it's urgent since it's not even released yet.
  3. No, I suppose it's part of the Visual Studio test adapter that can be selected in the VS Installer: https://docs.microsoft.com/en-us/visualstudio/test/how-to-use-google-test-for-cpp?view=vs-2019 Entirely possible that the compilation guide is lacking that piece of information. It's only used for the unit tests though, so you could in theory unload the Tests project before compiling.
  4. That dialog and its functionality is ancient. It must have been introduced when there haven't been any patches available at all - Brush Number really refers to "Primitive Number". Entity 0 is the worldspawn, as you found out. Putting Entity 0 and a primitive number will look up the worldspawn brush/patch for you. I guess the dialog should be made to work with non-func_static models too, since the entity number 100 is a valid one and it should be found even if has no child primitives attached to it. Not sure about the workflow though, what's the reason you're looking up the entity by number instead of its name? I guess the Entity List would do a better job at locating entities in most cases.
  5. The master branch on Github should be compiling fine with the dependencies that it downloads using the Python script (either automatically or manually, as you did). I haven't touched VS2022 yet, as there's only just a Preview release of it. It's not unlikely that the new version is causing the trouble.
  6. I think it's this one: https://bugs.thedarkmod.com/view.php?id=5608 To reproduce in 2.12.0, you have to rotate it first, then drag the entity around, iirc.
  7. Thanks. I'm into other things at the moment, so it might be a while.
  8. Nope, not from the distance. I'd have to look into it with the debugger before being able to say anything. If it's tracked, then chances are higher for me to have a glimpse at it sooner or later.
  9. 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.
  10. 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.
  11. 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.
  12. 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).
  13. New pre-release build available in the first post, with a couple of changes. @LDAsh should find a few goodies in there.
  14. 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?
  15. 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.
  16. 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.
  17. 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.
  18. I think 356dfb4e05f1ff6ea7f570376e6a2b4692ad581a was the commit that didn't have Eigen yet. I merged it in the commit right after that.
  19. 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.
  20. 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.
  21. 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).
  22. 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.
  23. 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!
  24. You could select one of the faulty models, and then use the script "Select all Models of same Type". Does that work for you?
×
×
  • Create New...