jonri

I've found some value in this, specifically in order to combine several models into one. I over-modularized some pieces in my walls, and once I was sure of the sizing I was going to use I combined a wall, window sill, horizontal spacers, etc into two different 3-story wall slice models which are still highly reusable but much simpler to place. I've tried to avoid too much premature performance optimization but I also expect combining models to sometimes be a valid technique for reducing entity counts and drawcalls if modules or detail/clutter models push things over the edge. I think the best thing we can do as creators is make our intentions for our work clear by choosing and applying the right license. For instance, as my FM will tell my own unique story, I'll release the map itself as CC BY-NC-ND. OTOH I consider the assets I'm creating for the FM to be more of a means to that end and I'd be happy for others to use them as they saw fit to create their own stories, so I'll make those CC BY-NC-SA. If I was creating high-quality, highly-unique assets I might feel differently about them and choose a different license accordingly. We can't really prevent bad actors from doing what they want, but we can make things easier for everyone who is acting in good faith. Maybe we could come up with a way to increase the visibility of the licenses to other mappers somehow. Or maybe we should at least have a wiki article that encourages content creators to both include a license with their work, and to check for and understand the licenses that come with others' assets. We could either link here or provide our own simple examples of what the different CC licenses mean.

@greebothanks for taking the time to track down the Linux crashes with me! I did a couple hours of mapping last night using the same fix you committed, switching around between different map files a lot, and everything seems rock solid now.

I've been working on a small-ish mission that takes place in a warehouse. I've got pretty much everything blocked out and built up with modules, and I'm currently building out the other gameplay elements such as the main lighting and AI routes. I took a little detour to dress up this corner of the warehouse for overall feel, but there's plenty more to do...

This is really nice! If you're looking for additional ideas to expand the reference here are 2 more fairly universal areas: A series of decreasing tunnel sizes down to the limit, to help with sizing of sewers or ducts. The same thing, but for holes in the floor that you can fall through. I remember once having to noclip through a passage under an altar in some FM because it was too tight to get into easily. An interesting takeaway from this reference is that you can create a one-way gate for players by using a drop anywhere between 144 and 176 units in height. However, the player must fall off such a drop instead of jumping if they don't want to take damage (144 + 48 > 176).

I had been tossing this idea around in my mind as well, but struggled to come up with a UI idea that could handle all the available material options without becoming overwhelming. One idea I came up with was extracting all the keywords out of existing materials in order to determine which ones are used the most, and then making a "basic" configuration with only the most common ones. This would be optimized for easily bringing in your own textures with little additional modification, and then have the "advanced" version which exposes the less common flags for building specialized materials. I hadn't considered a node-based approach, but at first thought it could be well-suited for the way that material stages work. Considering how common node systems are nowadays, it might be an intuitive way to go. On the other hand it might add complexity to creating materials that just load a texture. This might be a little tangential, but I didn't realize you could actually see a material's definition from inside DR until recently. I always went hunting for the name directly in TDM's .mtr files. It would be nice to be able to easily load an existing TDM material into the editor, make tweaks, and save it to your map-specific .mtr file.

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 through TDM someday. This is the direction I'm leaning. One checkbox to enable/disable auto-reloading, possibly 2 if there does turn out to be a reason to toggle the core assets separately.

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 Linux or would prefer to build it yourself, grab the feature branch here. All feedback is welcome, but I'm specifically looking for the following: This is my first time building DR for Windows. Let me know if you try the pre-built version and it doesn't work for you! I seriously doubt this will eat your map, but definitely let me know if it does. Always keep good backups, doubly so when beta testing... I've started with reloading of Models, Materials, and Skins because they seemed the most useful to me, and as far as I have seen they can already handle getting updated at any moment (such as when you've got the "Choose Model" dialog open). What other reloads would be useful? I'm leaning towards skipping Readables and Particles since they have GUI editors. I imagine mappers don't hand-edit those as often, and the GUI editors would likely have to be changed in order to deal with external changes getting reloaded while they were open. That leaves "Reload Defs" currently unimplemented. I could see this being valuable to have, if it's helpful to others I'd be more willing to do the work for the cases where things like the "Create Entity" dialog need to deal with unexpected reloads. The auto-reload feature is currently always enabled. I'm already planning to add an option in the Preferences dialog to enable or disable the feature. Should this feature be on or off by default? Should auto-reload of each type (Models, Materials, Skins, etc) be enabled/disabled individually, or one checkbox for all of them? Currently this only watches your FM folder for changes. Is there any value in watching the TDM install folder as well? If we watch too many folders at a time, it's possible to run into performance problems or maybe hit a limit on the maximum number of watchers. If this would be useful for development of core assets, I would look into whether the above causes any problems. Otherwise I'll stick with just watching the FM folder. Windows does sneaky things behind your back. I primarily run Linux, and watching files for changes works just the way you'd expect it to. When testing this on Windows, sometimes files would get seen as modified the first time you accessed them, and then not again afterwards. For example, loading a map would cause one model to say it was being modified, triggering the reload models. Afterwards, loading the map again would not do this. I'm guessing maybe the virus scanner is meddling with things here. If you experience a lot of spurious reloading that you don't expect, to the point of it being disruptive, let me know and I can try to find a workaround. Apparently DarkRadiant runs on Mac? If anyone's using it there, please let me know so we can at least try to make sure this runs OK there. Currently this only auto-updates DarkRadiant, not a running instance of TDM. With the new game connection, we could probably have DR trigger the reloading of these items in-game whenever they are reloaded in DR (both from auto-reload and manual reload). I believe there was a proof-of-concept of something similar using an external script. In this case it could happen directly through DR instead. Would this be worth pursuing? Is there anything else I've overlooked? While I've dabbled with mapping for a couple years now, I haven't (yet) developed an FM to completion.

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.

@stgatilovWhat do you think about having the hot reload also reload models, materials, skins, scripts, etc when the same is done in DR?

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 buttons/checkboxes. Generally speaking, locating buttons/commands close to where you expect the user to be when they need them is a good thing. On the other hand, TDM keybindings are less intuitive than buttons so that might be a good argument in favor of the DR button.

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 DR when this happens, use the location value to draw a "breadcrumb" in DR (maybe have it look similar to a player start entity but make it easy to find).

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 button: restart map on save. No need for the instant button, since you have to save first for it to be useful anyways. The same logic as restarting the map should apply here, if it wasn't for performance. Perhaps we start with a manual dmap button, and if we get an incremental dmap someday, we can switch over to a "dmap on save" toggle button or better yet fold it into the "restart map on save" button. This gives us a total of 4 buttons - distilling each row from the mockup into only one element. Based on which buttons are toggled/pressed, we should be able to enable the Game Connection without a dedicated button. When any toggle is turned on or the dmap button is pressed, enable the connection. When they're all off, disable the connection. If we can really boil it down to just four buttons, I'd personally lean towards putting them on the toolbar above the 3D view in DR. It's got some empty space and toolbars are well suited for both toggle and normal buttons.

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.

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

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.

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.

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.

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!

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.

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 if there was any functionality that wasn't documented. I know a lot of people don't usually work with layers so I also considered using groups or func_statics, but the problem is you'd have to break them back down to brushes in order edit them, and in doing so you lose any name information you had set on the entity. My goal is to be able to iterate on my modules easily, batch-export them, and then reloadModels to see the changes. Any thoughts? I'm not opposed to coding up a new layer interface in DR (GlobalLayerManager?) if needed, as long as someone can point me in the right direction and work with me on what functions to build into it.

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.

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.

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. These aren't very multi-monitor friendly and librandr has superseded these calls for quite some time now. Since the platform-specific windowing code is really self-contained, I don't think it will be too hard for me to swap it out and see if things improve. The same area of the code already sets some X Window hints, I believe I could tack on a few more here to create a borderless mode equivalent as I previously described without much additional effort. It seems like this is more or less what several other fullscreen applications do on Linux too.

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 believe there are some window manager hints that we could set to automatically achieve this, this sounds about like the Linux equivalent of "borderless" mode anyways. I don't think the poor experience is a driver-specific issue, just the fact that multi-monitors in linux has always been a pain, and also changing the resolution on the fly tends to ruin your desktop even if the program is nice enough to change it back for you afterwards. It might also be better to detect the current resolution on first run and use it by default instead of resizing to whatever the current default value is. I think forcefully changing resolutions like that was more acceptable back when Doom 3 came out than it is now. As far as X vs Wayland goes, fullscreen is one of the areas where native X vs the XWayland compatibility layer may not work identically. I'd expect XWayland to disallow some of the more invasive screen resolution changes, but I haven't really played with it to know for sure. For reference, here are my relevant specs: OS: Arch Linux Graphics driver: AMDGPU Desktop: KDE (plasma5) using Xorg I could do a little research and see if there are any modern guidelines/best practices for fullscreen on Linux and at least make some recommendations. If I get enough free time I might be able to look at the code as well.

Wow, didn't realize NC was a TDM hotbed! Not a native, but moved to Charlotte a few years ago.