MirceaKitsune

That looks amazing! New AI models are something I've been hoping we could see for some time: We can definitely use more steampunk robots, fantasy creatures, and why not some bigger and scarier undead like Doom?! I hope those models can be perfected and included in a future release.

It would explain why volumes don't work with parallel lights then: They're being forced to stencil in that case. Hopefully the large lights limitation won't be around forever and all lights will use shadow maps eventually. Makes me wonder: What if the scale of shadow maps changed with light size? I remember it's a fixed setting, say 1024 global shadow map resolution; If they're unique per light maybe they should snap to the nearest increment (in powers of 2) based on the radius of the lamp, which would hopefully improve performance without overusing (v)RAM. For example: A candle can likely have a shadow map of just 128px or 256px, a torch flame 512px, street lamps are large enough to be 1024px... for a sun light it could stretch all the way to 2048px or even 4096px but it would only be for one light so most GPU's should handle it especially since the data is grayscale so just one color channel for intensity.

Looks gorgeous! Don't forget to use cubemap lighting with the skybox image, it greatly improves scenes visually. Though note that it seems to break the Fresnel mod and requires patching it up per FM last I checked.

Sadly I updated the FM after I finished my playthrough. I saw the post about it above and it didn't mention that sky brush so I figured I'd post this observation. I may replay the updated version again since I liked this so much: If the different difficulty levels were used I may have played it 3 times, sadly the author went with the "All The Same" approach.

Had a little thought in mind I wanted to share, for a little secret objective in case this FM is updated again.

What a beautiful FM! I enjoyed every bit of it. Pleasant town design, great story, great execution of this story through the world and objectives. Haven't found any secrets so I presume there just aren't any? As far as issues go, only noticed one area from which you can see the sky brush cut through a building behind it: You can see it if you climb over the church wall through the balcony then look behind. One more issue otherwise, not sure if it was fixed in the updated version which I only noticed later, will spoiler this one as it's related to a story bit.

Oh: For Sword and Blackjack it should work as those are one-handed. I had the bow and arrows in mind which require both hands so that's likely a blocker.

I am! The advantage is they look good and this adds more realism and immersion, which I presume is the main goal.

I don't know the internal definitions well enough to answer with certainty, but based on general knowledge: If you can access the light entity attached to the player by the lantern item, you should be able to check if it's on or off. Try the getLightLevel script function, the documentation suggests its value should be 0 when off and greater otherwise. https://wiki.thedarkmod.com/index.php?title=TDM_Script_Reference#idLight If that doesn't work you could set a custom key on the player entity, I did that for a couple of mods; It's a cleaner solution to using a temporary cvar, but less ideal than reading the light entity directly if you can do that. Try $player1.setKey to register it and $player1.getBoolKey to read the value.

Cheers. I'm sure some way to add a custom Z-order or fix it another way can be found later, attachments are definitely the right choice. The bow does it too from what I remember when editing weapons: There's only one bow md5mesh, each arrow is attached to a special bone when selecting or firing that arrow. I'm strongly in favor of doing the same for the sword and blackjack to make them more customizable, but that's a different story for later.

It gets more amazing by the day. Just making sure: Are the lantern and compass attached as separate entities, with items having the ability to define the attached entity its offset and the hand animations to use? I'm presuming they aren't all a single md5 mesh: The attachment approach would be needed to support custom items, as nearly no FM author will change the hands to add each custom item to the mesh.

I wouldn't go for something as overly complicated as trying to make the weapon and item hands interact, especially right now. For now it seems best to just show the empty / item hands (if enabled) if no weapon is selected or the existing weapon POV otherwise. Maybe later this can be further improved, right now I think it's good enough without, the priority is having this finished for all items in a way that's clean and customizable.

Agreed: We want to change as little as possible functionally, changing the light location may have gameplay implications. The hands will need a setting to turn them off which shouldn't cause the light to jump to different places.

Yes: A round patch should mitigate the effect of parallax being constrained to real geometry. Just make sure the material coordinates are perfectly aligned. For buildings my advice would be to have a pillar brush jutting out in corners. Which reminds me of my question earlier, still curious to hear answers: Can we have material based building modules with parallax, as an alternative to the building module meshes? The new building modules are great but I'm definitely running into my fair share of issues with them: Having depth-based beams and panels for both building exteriors and interiors could look really amazing!

Just realized something: The new parallax effect would be a great way to get model-less building modules, for creators who'd rather try those over the model panels! They provide enough depth to realistically simulate bricks and beams and even windows, enough to look as good as sets like "models/darkmod/architecture/modules/exteriors/ext_timber01" and the others: You'd only need to create some extra geometry for corner pillars to hide the geometry edge effect in parallax, otherwise it should offer the needed depth to have detailed 3D building walls directly on brushes

Absolutely amazing! Exactly what I imagined apart from envisioning it in the right hand.

The building modules don't come with any prefabs to my knowledge: You need to guess how they're supposed to be used. It actually took me some experimenting to figure out how they're meant to fit together, when I first learned them I had to try many different wall sizes. They're quite beautiful but issues were made in their designing: Many don't have a proper origin and got bad offsets, which would be risky to fix now since existing FM's are already using them and could end up broken. In my case I know how they're supposed to be used. At least the way I configure them on my maps, the answer may not be universal for everyone. Which is why it should be a well designed spawnarg for mappers that know what they're doing when they're certain they need it. In the cases above I know I don't need the exterior wall to show from an enclosed room, it's never possible to see and only wastes precious performance. I actually discovered this by accident while noclipping and peeking behind the interior panels, even if I knew the bounding boxes may poke through the walls at times.

Found a new bug while playing The Last Offering: Some items will show a quantity of 0 when their amount is 1. Arrows seem to be fine but the mine and health potion did that for me. I'm sure it was introduced now as I've been playing for a while on the previous development snapshots and haven't seen it, plus the change log mentioned something about an item quantity spawnarg.

The good news is tone mapping is applied to those GUI's as well. This reduces the white value on readables and even the main menu, it actually makes them look pretty good! They're far more bearable and natural looking with r_postprocess_brightness 1.5, still can't go as high as 2 which looks good in-world but blasts the GUI in over-brightness.

Sad that r_tonemapOnlyGame3d doesn't prevent tone mapping from over-brightening in-world readables, only the main menu is fixed. Otherwise everything looks absolutely wonderful with r_postprocess_compress, no need to tweak anything else after turning that on: It's subtle but everything looks perfect to me, especially when it comes to handling bright areas and avoiding unrealistic pure white.

It still feels unbelievable that I'm seeing these in TheDarkMod, the detail is absolutely staggering

Yes, one of the best updates. Can't wait to check how tone mapping with range compression will look! Also thanks for offering a way to no longer apply post-process effects to the GUI, now I can finally crank up the brightness without the main menu and readables becoming completely white

That's unfortunate. Sounds like a big oversight from the developers of the forum software. If it can't be patched out we can live without, would have just made some things a little easier.

Just a little something I had to add...

I'm definitely in favor of the idea. I just don't get what's missing: If you give any object the invName spawnarg, does the label not show when picking it up, is it only limited to bodies by default? This should be possible to do for all the default entities once the best way is identified.