Jump to content
The Dark Mod Forums

jonri

Member
  • Content Count

    64
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by jonri

  1. 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.
  2. 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.
  3. 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...
  4. 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.
  5. 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
  6. 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
  7. @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.
  8. 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!
  9. 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
  10. 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!
  11. 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
  12. 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 m
  13. 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:
  14. 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
  15. 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". Th
  16. 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!
  17. 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.
  18. 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.
  19. 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.
  20. 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
  21. @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.
  22. 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...
  23. 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, t
  24. 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 material
  25. 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
×
×
  • Create New...