Jump to content
The Dark Mod Forums

jonri

Member
  • Content Count

    40
  • Joined

  • Last visited

  • Days Won

    1

jonri last won the day on December 30 2020

jonri had the most liked content!

Community Reputation

29 Good

About jonri

  • Rank
    Member

Profile Information

  • Gender
    Male
  • Location
    Charlotte, NC

Recent Profile Visitors

451 profile views
  1. Good to know, thanks! And yes, since DR uses wxWidgets, the logical choice was to use wxFileSystemWatcher. That's exactly what I was thinking originally. To the others' point, though, the ideal situation would indeed be to cut out the middleman and have TDM reload the files directly as well. I suspect it would be a lot more work to do this directly in TDM, though, and that's why it hasn't been done. Since the DR => TDM command passing interface is already there, the "middleman" method shouldn't be hard to do, with the hope that it might be replaced with a better method directly
  2. I've recently started working on making some small quality-of-life improvements to DarkRadiant, and I think this one will be of interest of anyone who tends to make a lot of custom models or materials. Instead of manually going to "Reload Models", "Reload Materials", or "Reload Skins", DarkRadiant will automatically monitor your models, materials, and skins folders inside your FM for changes. Whenever a file gets added, removed, or modified, the appropriate reload command will happen automatically. To try this out, I've pre-built a Windows version available here. If you're on Lin
  3. I've got a proof-of-concept of this working in DarkRadiant right now. I'm not sure it would be as easy to do directly in TDM due to cross-platform stuff that wxWidgets takes care of in DR. Having this feature combined with the hot-reload, though, would provide the same end result as long as DR was running to relay the reload command.
  4. @stgatilovWhat do you think about having the hot reload also reload models, materials, skins, scripts, etc when the same is done in DR?
  5. Yup, I agree with the others and I changed my mind back The GameConnection already uses a wxTimer to poll for incoming messages ~10 times per second, and it probably already runs on the right thread. Shouldn't be hard to have DR send TDM a polling command which replies with the latest location the user flagged from TDM. Within reason, I'd rather start from what UX makes the most sense to the mapper and deal with the technical implications, than create a clunky experience in the name of simplicity. I'm just trying to brainstorm some other ideas to avoid the overwhelming sea of
  6. To me, the main justification for TDM => DR camera sync would be for pinpointing locations where things go wrong in order to fix them. For instance you find a place where you've got z-fighting, or an AI is getting stuck on an object, and you want to jump to it in DR. As this is a more occasional thing, this would bring me back to wanting a button for it instead of it enabled all the time. Alternatively, we could have a keybinding in TDM to push the location back to DR (or rather queue the location and have DR poll for updates to the value). And maybe instead of moving the camera in
  7. At the risk of introducing another alternative, why not combine both and have two-way sync? If you move in DR, it updates in TDM. If you move in TDM, it updates in DR. If you want to be in two different places, you turn off the sync. I agree, but due to the above I see this as 2 toggle buttons: Sync Camera and Sync Entities. Both of these toggle the continuous updates, no instant update buttons. In my use of the reloadMap command so far, there are some things hot reload (at least currently) doesn't deal with, that restarting the map does. So, this gives us 1 more toggle bu
  8. Thanks for getting this merged into the upcoming 2.10.0! In case anyone is interested in my batch export script, I've put it up on github here.
  9. I went to take a look and realized there has to be a release tag in Github first. I'll let Greebo take care of it, he's already been maintaining that file consistently anyways
  10. I've noticed that the python scripts are no longer found (on Linux at least, it might be fine on Windows): CMake will install the scripts to PKGDATADIR: # Install scripts install(DIRECTORY install/scripts DESTINATION ${PKGDATADIR} FILES_MATCHING PATTERN "*.py") ScriptingSystem.cpp looks for the scripts in PKGLIBDIR: #if defined(POSIX) && defined(PKGLIBDIR) _scriptPath = std::string(PKGLIBDIR) + "/scripts/"; #else _scriptPath = ctx.getRuntimeDataPath() + "scripts/"; #endif Changing the install location to ${PKGLIBDIR} should take care of this.
  11. I suppose the other alternative is to save the player's position, dmap and reload the map, and put the player back into the same position. You'd lose anything else that had progressed over time, but if you're just blocking out your map that's not as important. Of course, this approach could have side effects if you've drawn a brush over the player's position, but not much worse than what you'd get if you added the brush as a model. The model approach wouldn't let you delete brushes either.
  12. Built and starts up fine for me so far on Linux, but I did notice the PKGBUILD hasn't been updated for cmake yet. I can fix that up for you guys tonight if you want.
  13. I've got all the functions from the LayerManager class exposed to python, the last thing I want to do is make a test script that covers every function. Once I'm happy with it I'll make a PR on github. Thanks!
  14. Well, I decided to just jump in and do it. I took a good look through all the commands and didn't find anything, so I created and registered a LayerInterface class modeled off the existing SelectionGroupInterface class. I've added one method for proof-of-concept and now I can get the layer ID of any named layer from python. It shouldn't be any trouble for me to round this out, it's mostly just boilerplate code.
  15. I've got a dedicated DarkRadiant map that I've been using to create modular components. I've settled on a workflow of putting each module on its own layer (both for organization and for positioning relative to the origin). Exporting all these out to .ase files is a bit of a chore, so I had the idea to write a python batch export script. I'd like to select everything layer by layer and export it to a common directory, each file with the same name as the layer it came from. The only piece I'm missing is that I didn't see anything here about accessing layer information, and I was curious
×
×
  • Create New...