Jump to content
The Dark Mod Forums

greebo

Root
  • Posts

    16732
  • Joined

  • Days Won

    50

Everything posted by greebo

  1. The current script doesn't do this? If not, just put in on the tracker, it sounds like it could be an easy fix.
  2. Maybe that light has a weird rotation matrix applied? Like one that is mirroring the light planes?
  3. 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.
  4. I created accounts for the both of you, you should have mail.
  5. 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.)
  6. 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?
  7. 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.
  8. I'm currently prototyping a feature to produce a "diff" between two maps, which I figured would be a foundation for other features in this realm. Once a two-way map diff is possible, the next step would be to create a three-way map diff. Once I have that, we can more reliably identify conflicts between different "forks" of the same map, which is something that is happening all the time when angua and me are working on different sections of the same mission (of course we're using the same natural workaround to put stuff into layers and export them to prefabs later for integrating them back in the main line version). With diff-ing and a conflict resolution UI in place, it's a comparably small step to add a VCS plugin to DarkRadiant, which allows to browse commits/branches and to integrate changes into the currently opened map. It's not necessary to integrate the whole Git feature stack into DarkRadiant's UI like Visual Studio or VS Code, all that pushing, fetching, pulling and rebasing can happen in whatever Git client people are comfortable with - DR would just allow picking a version to merge. With a Git history accessible, it's rather easy to find the common base version of two maps which can be used for a three-way merge. Even if people are working alone, the benefit of being able to commit versions and have the history stored locally and/or remotely is an improvement and might reduce the amount of hair-pulling occurring after losing work on your map.
  9. I incidentally started a related post discussing version control for mappers in the other forum, it is aiming at a lower level target, but it's still related:
  10. I'd be interested in hearing about how many of our fellow mappers... ...are familiar with version control (Git)? ...are or have been using version control for their mapping projects? ...would be interested in using version control for their mapping projects? ...are or have been mapping alone, using version control? ...are or have been mapping in a team, using version control to collaborate? I know that frost_salamander used a Github repo for hosting the hare map, and angua and me are using a private one on Gitlab. We discussed a few features that could support common collaboration workflows in DarkRadiant, but I'd like to hear about others first.
  11. That's still interesting though. The way you open the map shouldn't cause this, so I'd be grateful for more insight. Can you describe what steps you did to make this fail, either here or on the tracker?
  12. Can you attach the pointfile, please? I assume it's existing and valid, but I just want to rule out any issues with the file.
  13. I just pulled OrbWeaver's fixes into my repository, you should be able to properly install these files now through CMake.
  14. That's the folder with your custom settings, yes. Colour themes, filters, keyboard binds, window positions, most recently used files, etc.
  15. That's completely undefined. It usually depends on how much time we have to work on stuff. Since it's not worth creating a release when there's only two or three minor things to ship, I'm usually waiting for one or two large changes and a bunch of bug fixes or smaller improvements. Then it's worth going through all the paperwork necessary to create a publication. It depends where your prefix folder is when you install your compiled binaries. If you leave it to the default /usr/local/ then yes, anything that's there will be overwritten. That's speaking of the binaries - your personal settings and preferences are shared between all DR builds, they are always saved to and read from ~/.darkradiant/ IIRC. Sometime ago we discussed keeping the user preferences in separate folders for each specific DarkRadiant version, like Blender, but this is not implemented yet.
  16. Hm, I guess the resource models are missing, you're likely seeing the "model not found" NullModel in the preview. There's a new folder install/resources/ in the source tree that needs to be copied to the runtime data path, like the XRC files and the scripts. I probably missed to adjust the CMakeLists.txt to copy these over to the install location.
  17. Thanks for the reminder, I had a look at the crashdump you uploaded. This seems to be a double-entering problem, the map diff method is entered twice through the idle callback. Due to the whole progress UI handling the map saving is taking longer than 123ms and the timer to trigger the map save is fired another time before the first one is finished. Down the line this causes a lock_guard to throw exceptions since it tries to lock a mutex it already holds. The MapExporter class has an option to switch off the progress UI when saving, which is likely to solve the problem. Still, the timer callback should probably be protected against double-entering too.
  18. DarkRadiant 2.12.0 is ready for download. Feature highlights include a new customisable GUI and the first iteration of the Material Editor GUI. Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/2.12.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.11.0 Feature: Customisable GUI layout Feature: Extended MaterialManager scripting interfaces by manipulation methods Feature: Material Editor GUI Feature: Same origin / duplicate detection script Feature: 3D grid feature Feature: Show light_radius on 'other' entities Feature: Show attached (light) entities Improvement: Better support for stage transform keywords in idTech4 materials Improvement: ESC to close dialogs with Cancel Improvement: Add portal_sky filter to default filters Improvement: Copy model/entity/prefab paths to clipboard (context menu in tree views) Fixed: Material stages with alpha test are incorrectly rendered as translucent Fixed: ASE importer needs to handle shared vertices with different normals Fixed: Ambients don't light sides facing away Fixed: Table lookup evaluation is not producing the same results as in the engine Fixed: Attached light radii are the wrong colour if "Override light volume colour" is active Fixed: Add missing image dimension reads to Quake 3 legacy brush parser Fixed: Opening the Create Entity dialog a second time will present an empty tree view Fixed: "Toggle 16x16 grid" function in the Particle Editor broken Fixed: Use of BITMAP field in ASE differs from TDM Fixed: Newly added or imported items don't use the location of previously selected item Fixed: Newly drawn brushes don't use height of previous selection with "Show Size Info" switched off Fixed: Rotation widget does not re-center on selected object Fixed: Duplicating model and moving with Alt-arrow results in pivot on original model when trying to rotate afterwards Fixed: Brushes with no visible surface towards orthoview "camera" are invisible in orthoview Fixed: Can't select one-sided models in certain 2D views Fixed: Twosided models can only be selected from one side The list of changes can be found on the our bugtracker changelog. Have fun mapping!
  19. I assume the crash is the one I fixed in #5586. About not being able to go back, that's not something I expected - I can open 2.11.0 after having started the newer versions just fine. The log is really short, maybe some of your DLLs in the folder are mismatching? Can you extract a portable 2.11.0 and start the instance from a different location? I'll upload a new build with the crash fix in the meantime. edit: new build (pre3) uploaded.
  20. Should be fixed, it was indeed the fragment program. I fixed it by adding a version request to the file, it's #version 120 now.
  21. It's maybe caused by one of the debug openGL assertNoErrors calls which are shutting down the app. I'll have to investigate. Another possibility would be the changes to the depth fill GLSL program, maybe they are not compiling.
  22. I've pushed an update, let's hope it's working better now
  23. In case you cloned my repository, I haven't integrated the latest changes yet, so you still need to update the submodule first. This step can be skipped once I integrated OrbWeaver's master branch.
  24. Thanks, I'll check it out in the next few days!
×
×
  • Create New...