Jump to content
The Dark Mod Forums

jonri

Member
  • Content Count

    59
  • Joined

  • Last visited

  • Days Won

    4

jonri last won the day on March 29

jonri had the most liked content!

Community Reputation

72 Excellent

About jonri

  • Rank
    Member

Profile Information

  • Gender
    Male
  • Location
    Charlotte, NC

Recent Profile Visitors

680 profile views
  1. 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
  2. @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.
  3. 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!
  4. 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
  5. 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!
  6. 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
  7. 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
  8. 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:
  9. 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
  10. 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
  11. 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!
  12. 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.
  13. 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.
  14. 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.
  15. 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
×
×
  • Create New...