Jump to content
The Dark Mod Forums

jonri

Member
  • Content Count

    40
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by jonri

  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
  16. Here was my workaround: Basically, set it up as a windowed app sized to your native resolution and then tell your window manager to make it borderless. I would expect this to work on Wayland as well, unless there's another issue preventing it from running even in windowed mode there. I started working on modernizing the fullscreen code but have been busy with real work lately. Since we have a workaround I wasn't going to push for a change in 2.08 and instead was planning to take the time to make sure the reworked code works out-of-the-box in both Wayland and X.
  17. Nice! I never paid much attention to the render scale option, I assumed it was just something for DPI scaling. We'll still have to grab the screen resolution at startup but everything else should be simplified after that. I'll look at the Windows code for comparison of the logical results. Taking care of this should lead to a better first impression and overall experience on Linux.
  18. It was easy enough to find the relevant code so I took a first look at this. Here's what I found: On Windows, there's a function to get the current desktop screen resolution and use it on first run. On other platforms that function is a no-op and you end up with an 800x600 resolution by default. Without going into details, this function is called too early in the startup process for it to work on Linux. I've got 2 possible ways to work around this that I'm trying out. The current mode-setting code for choosing a resolution uses the original, old-school X API calls. The
  19. I've actually got the same situation with dual-monitors on my Linux desktop. I was recently reminded that this happens out-of-the-box by wiping settings for the 2.08 beta (where it does still happen). The workaround I've always used is to run it windowed at the full resolution of my monitor. Then (in KDE at least, I'm sure others have similar settings), apply window- or application-specific properties to select a monitor, remove the window border, and disable compositing. This also has the benefit of letting you access your other monitor whenever you open the in-game console. I be
  20. Wow, didn't realize NC was a TDM hotbed! Not a native, but moved to Charlotte a few years ago.
  21. Should be an easy enough fix. Your .mtr file goes in testmission/materials, and your "goth_cab" on the first line should be "textures/darkmod/furniture/gothcab" instead. I'm not sure about the "\" vs using a "/" in the MATERIAL_NAME within your model, but I'd imagine that's ok.
  22. Here's an alternative approach: https://drive.google.com/open?id=1wHJGv1txRJrpcYnqR94BL3_kBRsVAn1n The difference here is that instead of generating a cubemap, you have a single texture with the front wall in the center and the sides/ceiling/floor in perspective: I feel like this will be easier for a mapper to make, either in-game or from an external source. For this one I took a 1024x1024 envshot from roughly where the window would sit (I didn't try to be too precise), and kept only the _forward texture. I brought that into Gimp and scaled it so that the front wall was
  23. There is a major shader overhaul in 2.08, so shaders written for one won't be compatible with the other. You could copy out a segment of your existing map into a new one for trying this out in 2.08 without messing up the work you've done. And once this feature gets settled and 2.08 is out you could update your full map accordingly.
  24. Because I'm a programmer and I'll go to any length working on cool things that help me avoid tedious/repetitive work! A case could be made that once you've built up a handful of cubemaps, placing prefab windows with this material becomes a piece of cake. Relative to a plane with an interior map, a physical cubicle clutters up the map and is a lot harder to move around once you make it. Although, realistically this is something you'd do as a final detail pass after your map's layout and major details are all totally done. There was some interest in trying this in conjunctio
  25. I'm fine with this, with a couple conditions: We make a reasonable attempt not to break things in an update without a good reason Breaking changes get documented in the beta release notes so fixes can get applied before the final release If this is going to be officially "blessed" we'll want a wiki page detailing how to use it. I can probably help out with that if needed.
×
×
  • Create New...