Jump to content
The Dark Mod Forums

jonri

Member
  • Posts

    79
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by jonri

  1. I'll make use of however much extension time is decided upon. I think being closer to the 2.10 release makes sense, maybe add the month of January to the contest. This would still leave a couple post-deadline weeks before the 2.10 release. If beta testers for the contest maps shake out additional bugs that get fixed during January, it might work out that an official beta or release candidate build could be timed to coincide with the contest deadline.
  2. I'm really digging the cabinet1 extension pack, the new pieces really tie the room together! With one month left in the challenge, I'm not sure I'll get everything the way I want it, but I'm aiming for at least beta quality with the primary objectives.
  3. Thanks, not sure how I missed it. It's right there when you check "Show inherited properties" in DR...
  4. While I'm here, does anyone know if there is a way to set the phase of a func_pendulum? I have some things I want to be out-of-sync with each other. If there's no direct solution, I could probably set the speed to be slightly different on each one and they should get sufficiently jumbled up by the time the player gets there.
  5. If you select your light and go into vertex mode (hit "v"), you can set the origin of your light to be off-center. You can then place the light such that the origin is near your wall and the entirety of the light volume is where you want it. The downside is that the center of the falloff texture does not get moved to your new origin, so you might need to make a new one for things to look right. If you're not quite sure what I mean, build a little test room where you can compare a regular light to one with a moved origin. I ended up making a texture like this: And since I reused this light a bunch of times I made an entitydef for it with this falloff texture and the origin already at the correct offset.
  6. It does OK a lot of the time, the two exceptions I found are textures with both light and dark sections being used as trim sheets, and metal textures that are probably right around that 50% mark: I think a button next to the light/dark modes to toggle auto-detection would be perfect, so you can temporarily disable it while you're working with such textures. I'll add 2 feature requests to the tracker.
  7. I'm really enjoying using the improved Texture Tool, and I've noticed a few other minor polish items: The selection of dark/light mode gets lost when you deselect and select a face. This one actually can get annoying if you're texturing several faces with something that's only usable in the opposite mode, or selecting/deselecting/tweaking something several times to see how it looks. There doesn't seem to be a limit on how far you can zoom in or out. Not a practical issue but I'm not sure how far you would go before crashing or getting side effects from a lack of precision. You already took care of the grid not getting small enough, thanks for anticipating this one If you're considering additional features, having a free scale button that lets you drag the corners to scale might be easier than using the panel on the right side in some cases, and it would complement the free rotate feature.
  8. Given the great work on the texture tool in 2.14 lately, I wanted to ask about something with texturing patches that I run into from time to time: Sometimes you want the texture to flow around the corner of a patch (the default, and the left half above), but sometimes you'd rather have it flow with the surrounding geometry (right half). This is possible to take care of manually, although in this case it's cumbersome to separate the UV vertices that are on top of each other: Is there a way to easily match the UVs up with the patch geometry in this fashion? Basically a cross between UV projection from a 3D modeler and the "Natural" button. Such a button would be a nice addition EDIT: Since trying this in DR 2.14, it seems like a regular (non-natural) paste does this. I swear I had tried everything in the past to make this work, have there been any fixes in the past couple versions or am I just dumb?
  9. The backstory to my still-WIP warehouse FM contains a few loose connections already, so I've decided to flesh it out a little more and turn the story into its own little FM for the challenge. I've given myself a cap on the number of "rooms" to avoid feature creep, and I'm about 80% done with the blockout. Hopefully the deadline will help me push this one over the finish line, plus having a prequel will let me cut back on the intro and readables in the following FM.
  10. @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?
  11. @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.
  12. 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.
  13. 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
  14. 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.
  15. 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).
  16. 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.
  17. 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.
  18. 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...
  19. 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.
  20. 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
  21. 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.
  22. @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.
  23. 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!
  24. 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.
  25. 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!
×
×
  • Create New...