Jump to content
The Dark Mod Forums


  • Content Count

  • Joined

  • Days Won


greebo last won the day on July 5 2010

greebo had the most liked content!

Community Reputation

29 Good

About greebo

  • Rank
    Heroic Coder
  • Birthday 11/26/1979

Contact Methods

  • Website URL
  • ICQ

Profile Information

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

Recent Profile Visitors

10796 profile views
  1. If you can describe the scenario well in a bug tracker entry, I can look into the duplicate behaviour some time.
  2. I created the DR macOS app, DR 2.8 has a working Xcode project. (I just did it for fun, I don't think there's many (if any) DR users on Mac.) TDM is a different story, I know that we had a working Xcode project back in 2012. Can't say what happened after that.
  3. You're saying downgrading to DR 2.6 did not solve the issue? If that is the case, I guess it's something to do with the setup. Can you see and edit the readables in DR fine? Anything in DR's console indicating that something is wrong with readables, xdata or similar?
  4. Is this something that had been working before? I'm not aware of the specific entity setup, but if it was working before, please report it to the tracker, I'll look into it. As far as the texture path is concerned, I think you can right-click the tile in the texture browser to seek it out in the media browser. Or you can pick it with MMB and then look at the shader clipboard info in the status bar.
  5. Ok, I was planning to include the fix for this in a short-term 2.8.1 bugfix release, so let me know. If it isn't reproducible, I think there's only one other issue to be fixed for this release - so I'm probably skip that, no need to do a new version just for one fix.
  6. It's not crashing for me, tried a couple of maps. You got a crash dump for me, perhaps?
  7. In 2.8.0 a limit of maximum grid lines was introduced to fix a near-infinite loop - I guess that was a bit over-ambitious. Can you open an issue on the tracker and maybe add what dimensions / grid sizes you're using?
  8. DR 2.8.0 is out now, thanks for testing, friends!
  9. DarkRadiant 2.8.0 is ready for download. Next to a considerable number of bugfixes and improvements, a nice amount of new editing features made it into this build. There's a new way to select items by filter, it's possible to retain grouping information when copy-pasting between DarkRadiant sessions, a new "Select Parent Entities" command has been added, and more. A new DarkRadiant User Guide is being worked on and available on the website https://www.darkradiant.net/userguide (also accessible through the About > User Guide menu option). Windows and Mac Downloads are available on github: https://github.com/codereader/DarkRadiant/releases/tag/2.8.0 and of course linked from the website https://www.darkradiant.net Thanks go out to all who helped testing this release! 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. Changes since 2.7.0 Feature: Selection by Filter Feature: Preserve grouping information when copy-pasting between multiple open instances of DR Feature: Add Portable Map Format storing map and additional data in one single file Feature: Preserve grouping information in prefabs Feature: Model chooser now lists .md3 models Feature: The Dark Mod: Let DR look for either 32-bit or 64-bit TDM .exe's Feature: The Dark Mod: Added ability to edit difficulty names Feature: The Dark Mod: Add Move up/down buttons to Conversation Editor Feature: Add type-to-search ability to AI vocal set and head chooser dialogs Feature: Let DR remember the shader in ShaderClipboard after closing Feature: Add option to show "Other Materials" in Texture Browser Fixed: Edit Objectives dialog doesn't adjust its height when selecting a component Fixed: DR can't find materials whose names start with table Fixed: It's possible to delete the classname spawnarg through the context menu Fixed: All spawnargs with the same value as the "name" spawnarg iterate when the entity is cloned Fixed: Removing a Stim/Response entry can break the remaining entries Fixed: Loading error caused by non-Latin character in filename Fixed: Texture Tool: crashes on brush surfaces with texture scale 0 Fixed: Undo after thickening a cylinder cap along vertex normals causes crash Fixed: Readable Editor Crash Fixed: Python 3.8 does not get linked (Linux) Fixed: ConnectNamespacedWalker Warning when cloning selection containing links and targets Fixed: Show English difficulty names in the Difficulty Editor instead of the #strNNNNN IDs Fixed: 'Reload models' reveals hidden models Fixed: 'Show help' etc. checkboxes in entity inspector aren't remembered by DR Fixed: 'Show help' tooltip text updates incorrectly Fixed: Changing classname ties entity's visibility to 'Default' layer Fixed: Resized Models lose their scale in auto-saved maps Fixed: Autosaves don't save last camera angle & position Fixed ToggleFullScreenCamera command for Embedded and RegularLeft layouts Tweak: Removed/disabled close button from all dialogs Tweak: Allow fixed Subdivisions to go higher than 32 Tweak: Targeting projected lights: let the line point to the light source instead of the light volume's midpoint Tweak: Collapsing a folder in a treeview now collapses all child elements too The list of changes can be found on the our bugtracker changelog. Have fun mapping!
  10. Yes, something lazy-acquiring the render-resources will give us enough room to breath to set up a test for a BrushNode or a brush parser. You're of course right with the distinction between unit and integration tests. I'm rather sloppy when it comes to using these terms (people call me out on this at work for all the time too) - I guess it's because for me there's not too much of a difference in practice. Unit tests and integration tests are mixed together into the same test assembly or test compilation unit, and both are run by the same testing framework. I didn't often encounter 100% pure unit tests that are only focusing on one single interface either, the test-worthy things (those that caused trouble in the past, usually) are generally covered by integration tests. But that shouldn't be an excuse for sloppy term usage on my behalf. I managed to make some more progress today, and I'm at the point where it's justified to briefly look into the Linux compilation, just to see whether that module separation works as I planned in the gcc binaries. I'm pretty positive though, there's no hacks or over-the-top-latest-C++ standard code involved.
  11. There are a lot of details that make it so hard, like the following snippet (creating a BrushNode is something our map parser would do): BrushNode::BrushNode() : scene::SelectableNode(), m_lightList(&GlobalRenderSystem().attachLitObject(*this)), m_brush(*this), _selectedPoints(GL_POINTS), _faceCentroidPointsCulled(GL_POINTS), m_viewChanged(false), _renderableComponentsNeedUpdate(true), _untransformedOriginChanged(true) { m_brush.attach(*this); // BrushObserver SelectableNode::setTransformChangedCallback(std::bind(&BrushNode::lightsChanged, this)); } Notice the GlobalRenderSystem() call right in the constructor... that's not saying this cannot be refactored or changed (in fact the whole LitObject approach needs some love), but it's probably taking so much time that I get lost in the process before I get to write the first unit test. The GlobalRenderSystem() above needs the GlobalOpenGL() module, which in turn needs to be properly initialised, otherwise the shaders cannot be realised. It's likely possible to go without realised shaders for this particular test, but texdef manipulation is something I want to be able to test too... Another thought I had is that I don't want the test environment differ too much from the production setup, ideally it should be identical. Modules can indeed be mocked, for some modules this might actually be not that hard. Main downside I see with this approach is that there are so many modules, the decision which modules need to be mocked in a particular unit test might differ for every single test setup (which scared me off). So I figured we'd get more unit tests faster when we just leave the DR module setup as it is, but make it accessible from not just the main exe. Refactoring the modules is still possible and needs to continue for the next couple of years at least. Another problem I'm yet to face is the game resources used for the automated tests. This might be harder than I want it to be, extracting the necessary resources to get DR in a working state such that it can be initialised and tested. My hope is that I can get away with a small 1-2 MB PK4 containing the necessary stuff, but I didn't cross that bridge yet. As for the ongoing refactoring, I've already made some solid progress on separating the stuff (only in Windows at the moment, but I think I know how to get the Makefiles in a proper state too). I already have a core module containing the ModuleRegistry, the Logging and the XMLRegistry, and DR is starting up fine so far. Now I plan to move over those modules that are not related to UI step-by-step.
  12. Thanks for the pointer, I'll check the tutorial and if there is some sort studio plugin for this.
  13. Yep, I noticed that, and I welcome every effort getting unit test into the picture. I recently tried to get some tests done validating the save/load process. It turned out that even the "simplest" operations in DarkRadiant rely on a fully loaded module network, hardly anything can be extracted and tested on its own. I went on trying to get some modules set up, which led me to the second problem, that DR is only capable of starting up when run by the main executable - too many statics and other things only working in the main exe. I'm currently on a branch changing that architecture, such that the core DR functionality is extracted from the main binary into a separate module. This module should be instantiable from both the EXE as well as a unit test module - the only thing required will be an implementation of the ApplicationContext interface. After that step is done, I'll try to get some unit tests running against test resources that are not relying on having the whole TDM game lying around. If I'm successful with all that (which is not guaranteed) I'd like to see it taken further such that DarkRadiant's UI is separated from the map editing logic, but that is even further stretched out than the previous goal, so let's see how it works out step by step. Speaking of unit test frameworks, I'll see what Boost Test can do in comparison to Google Test (which has a smaller footprint than the whole boost library tree). There are test plugins available for Visual Studio for both of them, so I guess both offer the same convenience for me as a primary VC++ user.
  14. If no troubles have been popping up in the meantime, I'll aim for a release in the next few days.
  • Create New...