Jump to content
The Dark Mod Forums

OrbWeaver

Active Developer
  • Content Count

    7988
  • Joined

  • Last visited

  • Days Won

    35

Everything posted by OrbWeaver

  1. The location may not be exposed directly to the user, who does not need to care about which PK4 a particular image is in, but the underlying filesystem definitely has to keep track of this information, otherwise it would have no idea how to load resource files. It's not enough for the engine to know that textures/darkmod/blah.tga is "somewhere in the PK4 structure". It has to know exactly which PK4 and exactly which byte offsets to use when extracting the image data from the ZIP. Maybe not a full parser, but you would need some kind of parsing at least, even if it's just keeping t
  2. The logical place for this would be either DR or the game itself, since both of these are already parsing the asset tree and know what they are loading or not loading in a particular map. Doing it in a standalone script is of course possible, but then you have to start from scratch with parsing entity defs, MTR files and the like.
  3. I think I got most of the way through this mission, but it seems to be stuck and uncompleteable.
  4. Yes, I see that. I guess each different test fixture becomes a top-level node, with its tests underneath it, so it's possible to group things which share a test fixture but if you need a different fixture for a particular group of tests you automatically get a new node. Perhaps there are more explicit ways to group the tests but I haven't looked into it yet. At my work we use QtTest from the Qt library (and a horrific in-house build system based on QMake which is possibly one of the worst build tools ever written), and some of our tests take 10 minutes or more to run, so honestly this
  5. @greeboThanks for getting the tests working in CMake. I had got as far as compiling and installing the binary but it always hung after the first few tests, and without being an expert on GTest I had no idea how to solve this. I only noticed yesterday that you had fixed the test resources directory and now all of the tests succeed. I must say I really like this new test mechanism. It is so much easier to use and more comprehensive than the old approach that could only test standalone classes. Being able to create a new test fixture in a couple of lines and immediately start calling GlobalE
  6. Conversation editor restored in Git commit 72c6c52bdf0b6fa1f1ae76ede51ae5bf971258ab
  7. Oops, that's my fault. It seems I missed out the conversation plugin when setting up the CMake build.
  8. If you pull my master branch you'll get some tweaks to the Connection menu items (replace separate enable/disable options with a standard menu toggle) and two new icons in the camera window toolbar which correspond to the camera sync connection options. There is also better error handling, so if the connection cannot be made an error dialog will appear instead of nothing happening. I didn't create a bugtracker entry so far since these sort of GUI tweaks are something of an ongoing process, but I'm happy to create an item to cover these specific changes so it can appear in the changelog.
  9. @Zerg Rush Thanks, grayman sent me a PM giving me some helpful hints, so I'm on my way to completing the missio now.
  10. OK, I'm going to have to admit defeat on this one. I must have wandered around this map for hours, but I still have no idea where I'm even trying to go, much less how to get there. I've found the theater, which seems important and suspicious but despite looking in every room and reading the two or three readables, I couldn't find anything which advanced any of my objectives. I've also been inside a hotel, a couple of workshops, a builder chapel and a lighthouse but still, nothing.
  11. It may be that he is not referring so much to the capabilities of the engine, or even the resolution of the textures and models (which is not all that easy to notice if you are not specifically looking for it), but to the style of map creation. I have noticed that some missions tend to use design techniques which were common in the simpler Thief games but look less realistic compared to the level of detail in modern games, e.g.: Truncated slivers of bricks around and above a doorway rather than a realistic supporting beam or lintel, making it appear that the door or window is just cut
  12. Agreed. Unless there is a strong reason to only monitor a particular type of asset, it would be better to have a single option "Monitor for asset changes" which is either on or off. I don't agree with this, it seems like the common "We can't agree on the correct behaviour so we'll just dump it onto the user through dozens of preferences" approach. Also the DarkRadiant preferences dialog is somewhat limited in terms of UI layout (it's not manually designed, but automatically generated based on adding particular options in code), and having a vertical list of 10 different checkboxes is g
  13. Looks like a great new feature. I'm curious though, how will things like models and sound shaders be created from this view? Will they be dragged and dropped into the 2D view, or will you double-click them and they appear at some default location (e.g. the center)? And this in turn raises the question: could we use this same interface for all assets, not just Favourites? We could turn the Media tab into an Assets tab and allow the same creation mechanism (D&D or double-click), while listing not just textures but models, entities and everything in a single tree structure.
  14. There already is a blacklist mechanism, but it requires changes to the mod asset tree, rather than being accessed through the GUI. https://www.darkradiant.net/userguide/#_features_for_game_distributors
  15. Boost.Process can handle this, however we don't currently have Boost in DarkRadiant (since all of the Boost features we were originally using are now part of Standard C++, and I understand the Boost dependency complicates the build on Windows). I see that wxWidgets has some process related classes, would these be sufficient?
  16. Sounds like what you want is exactly what's implemented, except that it's currently a menu item rather than a button. Again, that's complicating things by introducing a need for DR to "take orders" from another process and trigger UI changes that don't correspond to keyboard or mouse events from the user (and might conflict with those events). It's much safer and simpler to have the currently implementation whereby the trigger to synchronise locations comes from DR menu/button events rather than commands from inside the game.
  17. I believe the reason 2-way sync doesn't exist is because DR is event driven, i.e. it responds to user mouse and keyboard events, therefore all of the sync options are triggered by DarkRadiant (even if the effect is to receive data from the game, such as "Sync camera back now"). Having DR respond to "events" received asynchronously over a network connection, which do not correspond to any wxWidgets input events, would probably require multiple threads and all of the ensuing timing and race conditions that arise when trying to combine multiple event streams.
  18. I'm fine with that wording if users consider it clear enough. Such a question should be addressed to @stgatilov I think, since he implemented this functionality. My only concern is fitting an appropriate DarkRadiant UI around the features. For what it's worth, I tend to agree: if dynamic hot reload works fine (without saving the map), I'm not sure of the benefit of an extra option which only reloads after save. But perhaps there was a good reason for separating this functionality (performance maybe?). No disagreement from me here, and it should be easy to automatically act
  19. "Load camera" from game means moving the DR camera to match the current player position. "Send camera" does the opposite, moving the player position to match the DR camera position but it does this dynamically (whenever you move the camera), hence a checkbox rather than a button. I'm open to suggestions for clearer wording for these options, which need to make clear that the checkbox and button work in different directions (so just labelling them "camera sync" is confusing). That's exactly what a checkbox is, isn't it? "Update on change" activates continuous hot reload (so any ent
  20. Here's another mockup with just the options that make sense: one checkbox and one button for each row, with the names changed to indicate more clearly what each row's options do:
  21. The overall layout looks promising, however in wxWidgets we are not drawing custom buttons/UI but using the system-styled widgets. This is what your layout might look like in wxWidgets: However, the problem with this layout is that there are far too many combinations, many of which don't make sense. Camera sync is either "on movement" or "when button is clicked". So we only need one checkbox and one button on this row. Reload map is either "on save" or "when button is clicked". One button, one checkbox. There is no "on change" because a change which is not saved will h
  22. You can try, but it probably won't work. The minimum version is set based on the used CMake features.
×
×
  • Create New...