Jump to content
The Dark Mod Forums


  • Posts

  • Joined

  • Days Won


greebo last won the day on June 12

greebo had the most liked content!

About greebo

  • Birthday 11/26/1979

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Gender
  • Location
    conduction band
  • Interests
    Physics, Sports, Guitar, Coding

Recent Profile Visitors

16204 profile views

greebo's Achievements

Mod hero

Mod hero (5/5)



  1. Have you tried Scripts > "Select all Models of same type"? It should select all entities with the same model spawnarg.
  2. Note that when you enable com_automation for the first time, the Windows Firewall will ask you for permission. Most players won't have interest neither in mapping nor in having their game process to listen for connections - I think enabling this feature and confirming the firewall dialog should be something that is done on purpose, once when people start playing around with the editor. On the other ideas, I think there's nothing stopping DarkRadiant from launching the game with the +com_automation 1 parameters. That would be useful and resembles some of the functionality that was present in DoomEdit.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. Thanks. I'm into other things at the moment, so it might be a while.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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).
  • Create New...