jonri

@stgatilovI went ahead and updated the related wiki page here. There are a couple of us that I know of developing FMs making use of the feature, and I'm also still planning to put a little tutorial for creating seed maps on the wiki as well. For completeness, can you verify whether the premade maps listed on that wiki page are in the correct format and location?

@MirceaKitsuneto be clear, you can still use vertex color blending to blend two materials and that shouldn't break the other maps, it was just my experimental approach to terrain that did that. And you are correct, it wouldn't be something you could attempt with patches, you'd want to build it all in a 3d modeler.

The term for this is called triplanar mapping. Before getting your hopes up, the answer is no, TDM does not have this capability. That said, I once did an experiment some time ago, I achieved some degree of success but there were some major drawbacks: The features: Using an RGB splatmap, I could paint 3 different textures onto the ground. A 4th texture would automatically be used for vertical areas using triplanar mapping. Where different textures meet, instead of linearly blending them together, they are blended based on heightmap. Lacking actual heightmap data for the textures in use here, I substituted a grayscale map of the texture and still got good results. Why you shouldn't do this: Custom shaders are fun to toy around with, but they're likely to get broken in future releases. There was another thread for discussion of this here. This isn't great for performance, it's a heavy material that will get run on large portions of your screen. All the magic happens by modulating the diffuse texture. You can't have normal or specular maps.

I got a whole lot done on the inside the past week, but decided to switch gears and try my hand at landscaping: SEED seems to do pretty well at scattering grass, but I need to tweak things to get them to floor better. I came up with a nice little trick to draw the image maps SEED can use to spawn entities: 1. Take a screenshot of the top view from DR, and import it into your favorite photo editor 2. Add a new half-transparent layer and draw your image map on top 3. Crop and export your top layer with the right settings, and apply it to your SEED entity

I've taken the poll, but please be aware that after playing with it when it first came out, I've really only gone back to using the connection feature consistently for the past week. I might find other parts more useful later on, but right now for me the biggest advantage is in setting up and tweaking lighting, and adjusting model positioning for player navigation and sight lines. I mostly just turn on "Game position follows DarkRadiant camera" and "Update entities on every change", and only have to toggle them if i restart TDM and need to force it to reconnect.

I threw together a really basic proof-of concept: https://streamable.com/9m9vgd None of the options in the dialog are actually hooked up yet, but it's just a matter of adding the math for them. The actual brush creation seems to be working ok (although I had to get a little creative with the scripting to do it, which I should probably improve in the DR source code itself).

This sounds like something I could knock out in an evening or two using a Python script. I've got no decent blocks of free time at the moment, but if nobody beats me to it I'll give it a go sometime. I've also been thinking of a script that would work something like the blender "array" modifier for easy duplication+offset of your selection, optionally combining the result. That might make the carpet placement a little faster once you drew one step's worth.

I created a script which is now included in DR to detect them so you don't have to run around you map looking for them. There's a little bit of discussion in that thread about the lack of rotation offset being a bug vs feature too.

Confirmed! When you said this, I thought maybe spawning an object too close to the AI might be disrupting it, but it seems to work no matter where I move it. Chalking this one up to the random map gremlins...

I reorganized my modules once, and what I did was just open the .map file in a text editor and use find/replace to swap out the old model path for the new one. Make sure your map isn't open in DR before doing it, and consider making a backup copy as well, but the .map file is just plain text so it should be safe to do it this way.

Here's a weird one. I have an AI on a patrol that was working fine, until I added a hacky little script. I wanted to add shouldBeOn to a candle as the result of trigger, and my solution was to spawn a new identical candle with the additional spawnarg and delete the old one. This all actually works great, the AI will notice and relight the swapped-out candle. The weird part is that if you trigger my replacement script while the AI's sit animation is playing. Then the AI gets stuck sitting and won't get up unless you alert him. I pulled out a simplified section of the map to reproduce the issue. When you start, the lever to trigger the replacement script is behind you. If you do nothing, the AI will leave the candle unlit as expected. If you pull the lever while the AI is walking, he will notice the candle and relight it. And if you pull the lever while the AI is starting to sit, then he gets stuck there forever. Any ideas? buggeroo.zip

Some preliminary results from me: This works great so far on KDE Plasma/Xorg, in addition multi-montiors and alt-tab working as expected I like the ability to resize in windowed mode. I could see that being helpful during mapping. I switched over to the Wayland version of plasma and the mouse is fairly unusable. When you move around on the main menu, it will suddenly jump back to where it was a few moments ago. I'll try to do more investigation as it could very well be plasma's fault. Plasma/wayland still has too many glitches for me to use as my daily driver so I normally stick to Xorg.

@Frost_SalamanderJust started playing this one last night - great job on the intro! Before I got too far into playing it, though, I did remember seeing your comment on collecting things for a future update. I've been noticing a handful of minor geometry issues here and there and I'd be happy to collect them as I play though, if it would be of value to you. Nothing I've seen is super-obvious or gameplay-breaking, but just smaller things I've become accustomed to looking for in my own mapping activities.

I'll give this a go on Arch Linux / KDE late this weekend or early next week. I should be able to try both X and Wayland to see what happens. Having looked at the windowing code once before I like the approach of picking up a library that's built to be good at this. Thanks for taking this on!

I ran into that a while back and what I discovered is that your module clipping into the worldspawn isn't a problem on its own, the corner case happened when the bounding box or origin of the module was even with the "outside" of the sealing geometry. In this instance, the module was inconsistently reachable from the other side, for me it varied based on which way the model was rotated but I assume it comes down to floating point weirdness when 2 things are in the same location. For that reason I've designed my modules to be used with 8-unit thick sealing walls, but the sealing walls must extend +4 / - 4 from the major grid, and the modules themselves will snap to the major grid. The main visible geometry of the module starts 4 units off the model origin to accommodate this, and things like windows can recess back to 0. Since the modules never cross the centerline of the worldspawn, they won't leak into adjoining visleafs.

Lots of great looking screenshots this year! Mine is still very much a WIP, but I've got AI routes and main lighting generally where I want them and now I'm doing initial detail passes. I'm trying to focus on the areas I expect to be the most performance-intensive first, to minimize any fundamental rework I might have to do. I do need to set this aside for a little while in order to focus on some other projects though, so this is also a self-reminder to pick it back up in June To everyone else, keep up the great work!

First off, I love that this is actually happening! Even if the interface is busy it offers a newbie the option to explore what keywords exist and see the results in realtime, rather than hunting them down off of various wikis that (besides ours) barely seem to exist anymore. That alone is a massive improvement. If I may constructively add a few thoughts: 1. I think that even for someone who knows what every single field means (not sure that describes anyone but John Carmack, lol), there is a lot of value in having a basic set of fields that makes it easy for people to cut through the clutter and quickly bring in materials that don't need any special treatment. We could call it Basic/Advanced or Common/All. This isn't about gatekeeping people who are overwhelmed, but making it easier for daily use. I had the idea of doing a word-count on all the keywords contained within all existing material files in order to figure out which ones are the most important to mappers. The most frequent ones should go on the Common tab, and on the All tab they should be placed (within reason) with the most common ones in the prime locations (top / left, tabs ordered by commonality). 1a. The Basic / Common tab could have a checkbox or button to generate a standard frob stage for the material, according to whatever our current best practices are. Even the advanced tab could do something to detect the frob stages and put them in a dedicated stage tab so you don't have to piecemeal it together. 2. If all the texture fields had the option to open a file selection dialog, you could derive the texture name from the selected file path instead of making the user type it out. 3. Having a good set of tooltips might go a long way on this page. Obviously we can't explain everything, but for example a reminder of what the _MACRO options select could be done, anything that can be explained or just jog the user's memory in a one-liner would be helpful. Some of these may not be worth the effort, but those were the ideas that came to mind.

It does, but I'm really only talking about having 6 duplicates out of the 1200 entities in my map so far, and 1-5 duplicates in each of the large released missions I tested it on. That means 99.5% of the time I didn't screw up (and others are 99.9%+) , but if you scatter enough junk around your map you're bound to make this mistake somewhere. You might be more likely to create a duplicate when you're making a straight line of repeated objects, you accidentally have something else selected when you duplicate/move another entity, and/or the DR autosave butts in while you're in the middle of moving something.

I had taken a look at the Linux code a little while back too. I had tried to do something to detect the desktop resolution but IIRC the game wanted to know what resolution to use before the connection to the X server was made. At that point I figured this needed a bigger rework and just stuck with my borderless window workaround. If/when others revisit this I'd be happy to help test. Here's the previous thread for reference:

Ha! Well, I'll let this sit here a few days in case there's any feedback, and then I'll add this to the DR repo so we can close the 14-year old feature request

Anyone ever done this in their maps? It's easy to duplicate an entity, move it back on top of itself, and move on without even knowing it happened. You can't visually distinguish them in DR, but in-game models will appear to be lit twice, lights will be twice as bright, sounds twice as loud, etc. I created a script to scan your entire map for these duplicates: https://github.com/jonri/darkradiant-scripts/blob/main/find_duplicate_entities.py If you drop this into your DarkRadiant scripts/commands folder, you'll get a new menu option called "Find Duplicate Entities". This will select all entities that share the same origin, model, classname, and rotation. Once selected you can either delete them, isolate them with ctrl-shift-h for further inspection, or just hunt down the selections manually. I opened a handful of FMs in order to do performance testing on the script, and many of them have a few duplicated items. One FM had a duplicated clock sound, another recent one had a whole duplicated bedroom set. Others had non-visible items like location separators on top of each other. And of course my own had a whole bunch, which is what motivated me to write the script. So, I think this might be useful to others. If enough people think this is valuable I could have this script included with DR by default. I'd also welcome any suggestions for improvements, for example if this mis-detects any legitimate entities.

I was trying to avoid this approach so that I didn't lose the ability to see the light volumes in DR. Now this put me on the right track! The noshadows_lit spawnarg doesn't exist on the regular light entity, but it does on atdm:static_electric_light_lit_quiet_base. I just switched my entity to inherit from that and then it had noshadows_lit both defined and set to 1 by default. This fixed my shadowing issue and since it's still a light I can see its volume in DR. Thanks!

I made a light entity that has a model property, which I found to be quite convenient trying out different placements. I was wondering if it is possible to set properties on the model itself rather than the light in this setup. Specifically, I'd like to set noshadows on the model but not the light. If it's not possible, I'll separate them back out as I think I've got my placement set.

Nice, this definitely seems like the same thing. In the case of ladders and swimming you're outside of normal movement logic so I imagine some check is not getting run in those modes. I added a note to the bug report in case the water version is easier to reproduce in an existing map.

I think I've found a bug, albeit an amusing one: https://streamable.com/qasfb5 1. Throw body into water 2. Go underwater and frob body 3. Swim a far away as you'd like, but stay in the water 4. Continue to manipulate the ragdoll because your frob never disengaged 5. Get back onto dry land to stop the madness It doesn't seem to happen all the time, but probably more like 90% of the time for me. I can file a bug report if this isn't already a known issue.