Leaderboard

Good news for everyone who needs to bridge the time gap for the current FM contest: As a 10 year anniversary I now finished the update for my Fan Mission. It is currently being reviewed by the Team who can hopefully put it up into the mission downloader. After the Update is officially available I'll update this thread with proper information. *excited screeching*

Yes, with new changes you can hold Creep button, and you'll surely get not sound from moving/rotating an item. And I recall I added a cvar to configure whether this happens always, on walk, on creep, or never.

I added a cvar r_volumetricEnable. Note that you should run reloadModels after changing this cvar, just like you need when you change r_shadows. It seems that you don't like shadow maps in general These are the typical pixelization artefacts which I also hate in shadow maps. When there are too many shadow-mapping lights being rendered, some lights are automatically switched to lower resolution, which makes the issue even worse. And one way to somewhat mask this problem is to use soft shadow maps... which are very expensive in TDM right now. Ideally, we should render shadow map with low resolution, then render stencil shadows as usual and use them for shadowing, but use shadow maps for volumetrics. But I'm not sure having both implementations of shadows fits the renderer architecture, unfortunately. This is not noticeable in a still screenshot, but I found this location and I see the problem. I have found a similar case at 3986.7 2463.3 -222.85. I guess I should look into it. It looks like color banding, because volumetrics are computed in 8-bit FBO. I knew about this problem, but it did not look so bad on testmap, and I thought maybe I could ignore it. But in Hazard Pay, there are many places where color banding is strong. I can "simply bump" FBO to 16 bits, doubling memory bandwidth, or adding dithering... I wonder if there is another option. When I flew around this map, the brightness of security cameras looked over-the-top for me too. But now that I look at the map, it seems that volumetric_dust is set to default here. @Dragofer, maybe we should tone down security cameras by default?... Of course, this issue is greatly magnified by gamma-incorrect rendering pipeline, so when several light sources overlap, their brightness gets much larger than just their sum. Not fixable right now I can't understand how a game can be blamed for increased power consumption. Loud noise... probably means that this particular piece of hardware has bad fans. But I agree that this is a sign of greater performance cost in general, which can lower FPS for you in other cases, or for other people. I guess you need to do reloadModels, since this cvar changed shadows model of some lights. It looks like your GPU increases power consumption when you increase memory bandwidth. Computations don't matter that much. It's no wonder you see no performance drop: you have 60 FPS cap. Given that now volumetrics are rendered at half-resolution, number of samples per pixel does not affect performance so badly. Maybe I should just bump them to e.g. 24, I don't know.

In the latest build dev16256-9358, the code for holding objects and dragging unconscious bodies has been changed. It is possible to switch between the old and the new code (e.g. to compare them) using cvar: "tdm_drag_new 1": use new code (the new default). "tdm_drag_new 0": use old code (was the only option in TDM 2.09 and before). With the new code, there are three modes of dragging/moving objects: Moving items (candles, apples, crates, etc.) around in normal/"messy" mode. Moving items around in "silent" mode. Dragging bodies (ragdolls = articulated figures). The long-standing problem with moving items was that it was very hard to stay silent. An object could instantaneously reach high velocities from minor mouse movements, colliding with surrounding objects, sending them to fly all over the room and produce noise. Regular noise from bumping into the table/wall when you push an object into it was also a problem. As the result, grabbing something from a table was risky and required a lot of concentration. The new code keeps item velocity bounded, so even if it collides something, it should not cause too much chaos. Also, if you push an item into floor/table, it won't cause continuous noise anymore. The silent mode is the radical solution to the noise problem. When you move object in silent mode, it does not produce any noise and does not push surrounding objects at all. So you can be sure you won't attract nearby guards and won't topple nearby candle. However, there is a cost too: if the manipulated item is blocked by something, you won't be able to move it. For example, if a crate has a candle on it, you won't be able to move crate vertically unless you remove the candle. So while this mode can be very convenient, it is not intuitive. We have not come to conclusion about usefulness of the silent mode yet, so there is a cvar which controls when silent mode is enabled: "tdm_drag2_rigid_silentmode 0": never use silent mode. "tdm_drag2_rigid_silentmode 1": use silent mode if creep button is pressed. "tdm_drag2_rigid_silentmode 2": use silent mode when run button is not pressed. "tdm_drag2_rigid_silentmode 3": always use silent mode. Feedback is welcome As for dragging bodies, this is an entirely different mode. The new code should make it a bit smoother and more natural. For example, if you try to push a body into a wall/floor, you will see horrible convulsions with the old code. The new code does not have this problem. Another issue happens when you try to lift the body up. With the old code, it feels as if the body is stickied to the floor with magnets. The new code is more physics-based, and you won't have problem with lifting torso, head, and arms off the floor, although you will never have enough force to lift whole body and keep it in air.

Oh I thought this was always active.. Well, good to know. Edit: Ah, the silent mode is on top of the other already helping changes.

The illusion works best if the 2 rooms are completely identical. The player and moveable entities have their origins modified by the vector between the 2 rooms so they'll end up in the same location over there. Regarding the triggers, you need a reliable way of triggering the teleportation before the player reaches the far side of the room and notices the dead end. If it's just a trigger_facing the player might walk sideways/backwards and not activate the trigger. Also, the trigger zones should not overlap, otherwise the player will get endlessly teleported back and forth. The trigger_touch is just needed to register all entities inside the room so they can be teleported.

This post is quite frustrating for me, because it sounds quite critical. In person, it would be easier to point out the good parts and ask what's going on with other parts. Without that, unfortunately, it's just using this limited medium of text and a few screenshots to point out things and hoping there is a solution, which isn't an ideal way to communicate. Edit: The main thing is that I know that you, @stgatilov, did a lot of great work on this. I've seen the commits and improvements over time, and I appreciate you spending your time to improve this game we like to play. So, I really don't like to talk about aspects I don't enjoy, and unfortunately, I'm not enjoying volumetric lighting. The volumetric lighting in Hazard Pay has quite a few issues that degrade its look, but the one volumetric light I noticed in Iris (Moonlit Manse area) looks good. So, maybe it really depends on the volumetric settings in each map, and they can be tweaked/fixed. I'd like to see an option in the settings menu to enable/disable volumetric lights. Could you please add that cvar? Something like r_volumetricLights 0/1. This has three benefits: For those who prefer the look of the game without volumetric lights, they can turn it off. This is really not different from being able to toggle bloom, ambient occlusion, color precision, and shadows maps vs stencil shadows, so why not volumetric lights as well? It'll help those who are having performance issues or need to keep the temperature of their graphics card at a minimum. Volumetric lights (or maybe it's really the shadow maps?) add between 5 to 25 watts of power to the graphics card I measured. I imagine those playing on a laptop would be impacted the most. Others may get unwanted fan noise. It'll help with measuring and comparing the performance between volumetric lights off and on. As for player preference, the moving volumetric lights in Hazard Pay cast shadow maps with edges that wiggle/wave whereas stencil shadows are static/still. That wiggle/wave doesn't look good and is distracting. Maybe the shadow maps can be improved to fix that? It also has fog that has graphical artifacts that look like distorted waves, but those can be fixed/reduced by increasing r_volumetricSamples from 8 to 24 (screenshot #1). Other volumetric lights have fog with multiple ring artifacts that no setting I tried fixed/reduced them (screenshot #2 with ring pattern marked). The rings seemed to be where the fog touches the wall. There are some volumetric lights that make areas of a scene overly bright, especially when two volumetric lights overlap (screenshot #3). Given all that, the look of stencil shadows without volumetric lights is preferred. As for performance, it's probably pretty good to great, but I don't know how to quantify it other than that it adds 5 to 25 watts of power to my graphics card, generating more heat. (Again, maybe it's really the shadow maps?) The FPS is a steady 60 fps even with all settings maxed out. r_softShadowsMipmaps 0: Added ~10 watts in one scene. r_volumetricForShadowMaps 0: Turns off shadows completely where there is a volumetric light. Stencil shadows are not used/seen. r_shadowMapSize 512: Reduced ~5 watts in one scene. r_volumetricSamples 0: Can significantly reduce wattage (~10 watts in one case), but then it looks blocky, of course. Interestingly, when I set r_volumetricSamples from 8 to 100, it might add ~5 watts without an FPS drop. I hope volumetric lights can improve a bit more along with an option in the settings to enable/disable them.

Yeah, but I couldn't wait any longer. I just played and finished Iris & The Black Mage. Working on Lucy now. Still got Written In Stone to do too. None of these would work with an asus with windows 7. Now I can take all these old pc's and laptops and recycle them. The batteries suck and the desktops/towers are all outdated. I used to build my own for just gaming, but now tech is so far forward that even a Lenovo can do it & then there's the idea of building my own TDM FM one day, with 12 cores of processing power maybe now I can get the water in the moat to work. That's when I stopped last. The water kept crashing the old pc's Now I just have to relearn Dark Radiant again... When is the Christmas contest due? Maybe I can make a little snowy one... I love the snow in T2 & TDM & just incase, the water will be frozen lol

Keep on Creeping on...

Lenovo IdeaCentre 5 Gaming Desktop - 12th Gen Intel Core i7-12700 - GeForce RTX 3060 - Windows 11, 16Gb ram, 512Gb SSD, 1 Tb HDD.

I am not saying I am always happy with this. It's just the kind of inconsistencies one gets when several working on something every now and then with no clear hierarchical order behind that specifies the rules and concept. As you say, a fan project. The question is whether this or any other workaround justifies your needs or you (and preferable a few more people) would prefer a change beeing made. In the latter case all that is left is to convince the team to change it and someone to implement it

Snd_move helps a bit, but as you say, it works both for opening and closing. I guess that makes sense for fan project overall, but cases like that (core systems) it needs some extra care, as it will be hard or impossible to change later. It's kinda too late for that, but it probably should have been something like snd_open / snd_opening, snd_closing / snd_closed. This way you have a bit more freedom, e.g. you can make more simple system, with just snd_opening/closing, where the two sounds include pressing the handle and door squeaking / squeaking and doors being shut. The downside is that the opening / closing time has to be systemic as well, it has to match the sounds. Or, you can have more complex 4 sound setup and you can change the door opening/closing speed.

I noticed one weird inconsistency about door system: there are snd_open and snd_opened sounds, and they work as expected (sound when you start opening the door, and at the end of it), but for some reason closing works in a different way. There's only snd_close, and it doesn't start when door begins to close, it plays at the end of it. So you can have a squeaky wooden door that has the sound of turning the knob and the squeaky sound that comes next, but you can't have the same for closing. It has to be silent and you only hear the sound of the door being shut. Why is that?