Leaderboard

Currently the components that make up a LOD-enabled model are usually stored in various different places. Taking the aphrodite statue as an example: - The most detailed model stage is found in darkmod/decorative/statues. - All the other stages are found in darkmod/misc/lod, probably so that the decorative statues folder is less cluttered. - The LOD entity that makes use of all these stages is in a different menu altogether, Create Entity > LOD/decorative/statues. I've seen that a lot of the times, even though a LOD entity is available for a particular model, mappers just use the most detailed stage in a simple func_static, missing out completely on the LOD optimisation. I suppose this is because mappers mainly use the Model Chooser instead of the Entity Chooser for decorating the map and don't realise how the LOD system works/forget to check every time whether a LOD entity exists for any of the models they create. Some possible ways to address this: - Let the Model Chooser check whether there's a LOD entity that makes use of a model the mapper is about to create. If yes, it could create that entity instead of a func_static. - Wellingtoncrab suggested an overhaul by combining the Entity Chooser and Model Chooser into an integrated asset chooser which could show flags for certain models, i.e. LOD. This would also make it easier at a glance to see what's available.

Keep at it, don't bite off more than you can chew though!!!! 90% of all mission authors give up after a short time because the project seems insurmountable. It's why the A-Z guide focuses on such a small little mission, it's complete-able in a reasonable amount of time.

"Yoku's Island Express" is free on Epic right now and I can totally recommend it. This game is a metroidvania, jump'n'run, pinball-game and this interesting combination of gameplay mechanics is a ton of fun. It is single-player, but it is still enjoyable to play this together by hot-seating. It is also family-friendly, so you could enjoy it with your kids or life partner or whatever. I played it a few years ago with my gf when we were on a holiday trip to Crete. We had some bad-weather-days, so we played this game, and it instantly lightened the mood with it's chill and positive soundtrack and holiday-like athmosphere.

Is throwing in TDM so linear that an aiming point can help or do you mean it's like a crosshair for the bow? I never use it and with the box-while-frobbing-info from above it could indeed be renamed to crosshair or similar. As for r_frobIgnoreDepth 0, this should indeed be the default as it gets rid of the worst of the not-antialiasing artifacts. I still think there should be an option to turn the outline off completely, for visual and gameplay reasons.

Still chugging along on my mansion level. It's so easy to get disheartened because what you're building looks like poo, but it all looks so much worse in DarkRadiant than it does in game. Even a stark, empty room looks not so awful in the actual game.

It's one of those things that appears to be simple to do, but really isn't. At the end of the day, there are really only two ways to do it: Mark the highlight mesh in the stencil buffer, then draw an extruded version of the mesh, skipping any pixels marked in the stencil and thus producing the outline. Works with depth out of the box, but will typically produce a hard border, not a soft glow. However, creating the extruded mesh is not a trivial thing for any non-convex mesh. Might be that Unity has tools for this, but we don't, and spending the time to implement something like this for an effect that's already controversial, anyway, seems like a huge waste of effort. There are some techniques with geometry shaders that can be used here, but you still need to preprocess the mesh data for them to work. Do an image-based effect. Draw the object to a separate color buffer, then blur it to create a soft screen-space silhouette. Can then be applied to the original buffer, again using a stencil mask to cut away the insides of the object. This is what TDM currently does, it looks pretty decent and is relatively easy to do. However, it has no concept of depth, at all. I've tried some hackery on top to get it to respect depth, which is what r_frobIgnoreDepth 0 does, but it's not pretty. Might be able to do better, but that would eat more development time with uncertain outcome. In the end, the current implementation is what you can do in TDM with moderate effort. Anything better requires significantly more effort, and given the lukewarm reaction to the feature, I really don't think it's worth that development time.

Well, in my short testing, r_frobIgnoreDepth 0 does indeed get worse performance.......by 0.3 fps..... In bakery job, the front door open and highlighted, I get 153.3 fps with it set to 0, and 153.0 fps with it set to 1........ Is this really what expensive hack means? Looking at the door THROUGH the fireplace with it set to 1 gets me 143.1 fps, with it set to 0 I get 142.9-143.0 fps....... The only issue I see here is that there are some visual glitches on the door when it's closed, but they're liveable.

Now for something completely different: I have the latest release dev16350-9577 installed and there are missing strings in the mainmenu_settings_audio.gui to turn subtitles on. Both for the title itself and the possible options.

Or at least make it optional. Why is it so hard to get that through to the core developers?

r_frobIgnoreDepth 0 isn't a good idea for a default setting. As stated before, it's a rather expensive hack, and it can produce visual artifacts (of the kind where the outline is partially leaking into depth-occluded territory) that are not fixable. If the outline is so controversial, better to remove it entirely than enable it with that hack.

I vaguely remember this being discussed a while ago, and I have the impression that the save file is a somewhat unstructured binary dump of data structures (clearly can't quite be that ... pointers and all that, you know), and changes to any data structure or the meaning of a field can completely trash the machine state. So yeah, loading an old save file into a newer build is going to be dodgy; might work, might go hideously wrong. To be honest, I'm just grieving (apart from grumbling about the nasty software issues alluded to) about having to restart The Painter's Wife, which I've not been able to play before, haven't finished yet, and is gigantic! Never mind, I'll get to know it very well in the end...

This has been implemented in a few missions where items like loot are set to frobable after a drawer is opened. But there's an occasional bug where the item does not become frobbable and then you're screwed until you restart the mission or load a previous save.

Here are my latest settings: r_frobHighlightColorAddB = "0.00001" r_frobHighlightColorAddG = "0.00001" r_frobHighlightColorAddR = "0.00001" r_frobHighlightColorMulB = "0.3" r_frobHighlightColorMulG = "0.3" r_frobHighlightColorMulR = "0.3" r_frobOutlineColorA = "0.4" r_frobOutlineColorB = "0.4" r_frobOutlineColorG = "0.4" r_frobOutlineColorR = "0.4" r_frobOutline = "1" r_frobDepthOffset = "0.004" r_frobIgnoreDepth = "0" This produces a more subtle frob that more closely resembles the original version but has a slight glow due to the frob outline.

Time I think to revisit the debate: set r_frobIgnoreDepth to 0 by default? I say yes, please! I see nothing wrong with the new frob highlight with this setting, and I think there are a lot of words above to the effect that 1 is troublesome.

These area's are not fully finished with optimization, but they are running quite fine with just basic visportaling for now. I've also adjusted the architecture to help with optimization. That way the the engine is not drawing anything past certain heavy areas with high density.

But this would not help the hundreds of already existing missions where the new highlight could reveal secrets the authors were hiding on purpose. If this can't be fixed by setting r_frobIgnoreDepth 0 as default I don't think the highlight should be included at all! I still remember how the core team refused to include exstinguishable oil lamps because this might affect existing missions. This seems to me much worse...

Do you have stencil shadows enabled? Does the flickering go away if you switch to shadow maps? If you KO a guard and frob-highlight the body, do you see same flickering? I had such issue with guard bodies, and did a small fix which (for not very clear reason) fixed the problem for me. I guess I'll publish a new dev build soon. As for the ease of discoverability of secrets, that's an interesting question. Somehow, we thought it is not a big problem, and in fact can be a benefit (detect items frobable through walls and such), but now it seems to be a real issue. By the way, when I could not find something, I often walked around the rooms of interest while constantly frobbing all walls/tables/everything...

Ive seen this happen where the AI will be alerted during a conversation but wont take action until after the conversation loop is finished. This is usually from a build up of audio alerts. If they clearly see you they’ll usually stop. Just a heads up conversations and scripts can get pretty messy. Ive experimented with this is my current fm and its seems like any functions called directly to the ai ($guard.moveTo() for example) will happen after the conversation is done and as Dragofer mentioned you can’t always depend on a conversation being done… After my first mission I kind of learned to just design areas around conversations so there’s less chance of them being interrupted by the player. Making sure they start while the player has a good hiding spot, removing noisy surfaces and things the player might bump in to, and also trying to start the conversation before the player sees the AI so they don’t accidentally shoot them with an arrow or flash bomb them.

You can use setAcuity("type", number) in a script, where types can be "aud", "vis" or "tact". So like $ai1.setAcuity("aud", 50); The risky thing about doing something after a conversation is that the conversation can get interrupted and the thing never happens, i.e. the AIs stay blind and deaf. So you'd need to put the script events on a timer that begins with the conversation. But if there is/will be an official fix, then adding your own scripted method on top might be too much of a good thing.

To anyone attempting to ignore our beloved Kurshok - you're going to miss out on his fresh hot take on the OnlyFans canine-fellatio scandals!!!

How much difference would it make to this conversation if seta r_frobIgnoreDepth "0" was made the default for future releases? I have added that into my autoexec.cfg for now, and the frob highlight hasn't given me any issues yet.

Another argument to replace the frob helper with the frob outline option as the former never made much sense to me.