Search the Community

aye the rtx 3060 was another weird one, it only has a 128 bit bus which is to low to effectively handle 12 gb so it did not really help with the extra vram in higher resolutions. sadly they decided to continue with the same eh "mistake" with the rtx 4060 16 gb model . id call that deception to make users pay more for a card which is not even rated for 4K... sadly. the 16 gb 3070 model was scrapped by nvidia because it would be a contender for the much higher priced 3080 non ti i guess as it has a 256 bit bus and hence would be a capable 4k card. the 3060 ti 8 gb was a much better card sadly. https://www.techradar.com/reviews/evga-geforce-rtx-3060-black-xc

well i am habitual to using iptables to a certain extent. The simplicity of BSD's packet filter is fascinating. I begin to muse on the possibility of rolling my own x86 router and the pros&cons of it

The brightness was set at three clicks from max and gamma was about mid range. On some levels like down in a cavern or basement it was always too dark that is why I had it set high I'm not a youngster anymore can't see that well now!! I'll be 65 this year! P.S. I wanted to thank you for this great but short mission!!!!

I've found a: Also, is there a key for the first door you come to after you leave your apartment?

I've added your much better description of the process to the existing mention of resizing speakers in https://wiki.thedarkmod.com/index.php?title=Setting_Up_Speakers#maxDistance%2F_s_maxdistance

To the "Path Nodes" wiki article, I've added a few sentences about path_follow_actor. It mentions that it currently doesn't support the actor being the player, and has pointers to the new bug report and the workaround given in this thread. The entry for path_follow_actor in the Entity Database now reads "... actor (= other AI, not player)...

Interesting! Does it update all default textures so it's used on everything in the world? I should replay it and check that out: It would give us a good view of how the effect will feel in practice. Looking at the page, they seem to do it the conventional way I was thinking of trying out, which is currently supported by the engine but more limited than a proper implementation. It also looks like they're only doing it for the albedo channel, to be effective detail should be applied to all maps... the normal map is where the improvement should be most noticeable as it responds to lighting and modifies everything else. The implementation I'm thinking of should be universal like all effects and work on any FM new and old. It would be controlled by a menu setting, no one needs to enable it if they don't like how it looks or it impacts performance. Each detail pass should fade and be hidden with distance, we don't want to stress pixel lighting by having it compute thousands of dots on distant surfaces each frame. Just like the TDM ambient method, we'll likely need a special segment for materials meant to indicate what kind of detail each texture wants, then based on settings and camera position the renderer must modify each surface accordingly.

There's been talk over the years on how we could improve texture quality, often to no avail as it requires new high-resolution replacements that need to be created and will look different and add a strain on system resources. The sharpness post-process filter was supposed to improve that, but even with it you see ugly blurry pixels on any nearby surface. Yet there is a way, a highly efficient technique used by some engines in the 90's notably the first Unreal engine, and as it did wonders then it can still do so today: Detail textures. Base concept: You have a grayscale pattern for various surfaces, such as metal scratches or the waves of polished wood or the stucco of a rough rock, usually only a few highly generic patterns are needed. Each pattern is overlayed on top of corresponding textures several times, every iteration at a smaller... as with model LOD smaller iterations fade with camera distance as to not waste resources, the closer you get the more detail you see. This does wonders in making any texture look much sharper without changing the resolution of the original image, and because the final mixture is unique you don't perceive any repetitiveness! Here's a good resource from UE5 which seems to support them to this day: https://dev.epicgames.com/documentation/en-us/unreal-engine/adding-detail-textures-to-unreal-engine-materials Who else agrees this is something we can use and would greatly improve graphical fidelity? No one's ever going to replace every texture with a higher resolution version in vanilla TDM; Without this technique we'll always be stuck with early 2000's graphics, with it we have a magic way of making it look close to AAA games today! Imagine being able to see all those fine scratches on a guard's helmet as light shines on it, the thousands of little holes on a brick, the waves of wood as you lean into a table... all without even losing much performance nor a considerable increase in the size of game data. It's like the best deal one could hope for! The idTech 4 material system should already have what we need, namely the ability to mix any textures at independent sizes; Unlike the old days when only a diffuse texture was used, the pattern would now need to be applied to both albedo / specular / normal maps, to my knowledge there are shader keywords to combine each. Needless to say it would require editing every single material to specify its detail texture with a base scale and rotation: It would be painful but doable with a text injection script... I made a bash script to add cubemap reflections once, if it were worth it I could try adapting it to inject the base notation for details. A few changes will be needed of course: Details must be controlled by a main menu setting activating this system and specifying the level of detail, materials properties can't be controlled by cvars. Ultimately we may need to overlay them in realtime, rather than permanently modifying every material at load time which may have a bigger performance impact; We want each iteration to fade with distance and only appear a certain length from the camera, the effect will cause per-pixel lighting to have to render more detail per light - surface interaction so we'll need to control the pixel density.

My first thought would have been to use a rat or spider babby on the grounds that it's small.

It was a relatively strong mid-range card that obviously has less VRAM than it should. And it's still funny that the RTX 3060 packs 12 GB while the RTX 3080 copes with 10 GB. Game devs would like PC users to have 12-16 GB VRAM, but they'll support 8 GB and do little tricks like downgrading the textures automatically.

Cool yeah that's my bad, the image I'm using on the screen is just too bright. Thats good to know, thanks. Out of curiosity what was your gamma and brightness set to before?

Kingsal I don't have any mods it was the brightness and gamma settings. I adjusted those and all is good.

Each time I check the objectives in game (pressing O), this warning appears in the console: I checked a few missions (MoongateRuckus, Eye On The Prize, By the Cookbook, Spider and the Finch) and they all do this. Doesn't happen with TDM 2.11. I reinstalled 2.12, but still get this behaviour. Is anyone else seeing this?

Might be worth a try. I browsed the source code yesterday a little, but I had no idea where to even start looking for it. I've been building a sort of starter-project for it, but it's not public yet. But my support for DR is not ready for production or anything. Everything seems to work fine, except I'm having issues with textures, and tbh I'm not sure I'm gonna make it. I am about to make my repo public regardless of that, though, but I still need to get a lot of stuff in order. Meanwhile, if you'd like to move forward without DR, you could try NetRadiantCustom or TrenchBroom. Personally I recommend NRC (although TB might be a bit easier to start with). The plugin I'm using is FuncGodot (formerly known as Qodot). It's currently the most recommendable. Patches and NURBS aren't supported by any plugins yet, btw.

I can certainly help to locate and identify the relevant code, but I didn't write it myself and I'm not really a maths guy so the help I can provide with respect to its logic might be limited.

Hm after testing: This does actually work fine. Both in DR and in tdm. I guess there's no point in specifing the model path, because then it only works on one specific func_static.

Could you store that somewhere? For example in Github. I'm learning Godot at the moment and might be interested in this in the future.

You were on to something with that, but TDM won't let atdm:ai_base use another class's aas file. I changed tactics and switched it to atdm:steambot_base instead (it also happens to be the only AI base that doesn't say "do not use"). Dmap auto-generates the associated aas file (aas96) so there is no warning when the player starts. More importantly, it actually still works! So my AI will now follow the player with no errors or warnings.

ok so after getting myself a rtx 3070 im left with a bit of a wonder about all the fud on the net. elitist users claim the 3070 cant do 4k (debunked it handles 4k just fine but you need to lower the texture resolution in some titles to not overshoot the frankly rather low amount of vram -> 8 gb). some back and forth on the 2080ti some claim that the 3070 is faster while others claim the 2080ti is. (from my own experience the 2080ti is a bit faster in 4k while the 3070 is a bit faster in lower resolutions). if you play exclusively in 4k go for the 2080ti -> reason it has more vram 11gb vs 8gb this might not sound like a huge deal but the extra 3gb helps a lot with ultra high texture resolutions. debunked (claims that the 3070 uses newer dlss features, it does not. the 2080ti supports the exact same dlss features that the 3070 does, it even supports dlss 3 minus the framegen feature. some claims the 3070 uses newer tensor cores which are faster, well is they are i dont see it... the 2080 ti has 4 times the amount of tensor cores compared to the 3070 while the 3070 has around 1000 more cuda cores hmm ???). the real reason i think the 3070 got so popular is that it delivered close to the same performance of the insanely overpriced 2080ti, i cant fault people for that choice but i would like some realism in the comparison and not something based on just the price. the 2080ti was a highend card back when it was new while the 3070 is a mid range card at half the price of the 2080ti with at least comparable performance but lacks enough vram to play all titles at 4k with everything cranked to the max. playing hzd forbidden west on the 3070 atm in 4k with everything on max except texture resolution which i have on high and i get > 80 fps with the framegen mod and around 45 fps without it (dlss is flaky in this game though), the 2080ti in the same game in 4k gets around 100 fps with the framegen mod and 55 fps without it with texture resolution at the highest setting).

No, just modified darkmod.txt files with < and > added to mission name so the A and The sorting doesn't work!

Skins don't require a model path, that's just a convenience feature to allow the skins to be associated with the model(s) in the editor. However I have no idea if an unassociated skin can be used on a func_static. I suppose there's no reason why it couldn't work, but it's not something I've ever tested and I wouldn't be surprised if it fails to do anything (either in the editor or the game).

Is it possble to make skins for brushes/patches by conferting them to func_static? Models are func_static when you add them in DR, but in the skin file you reference them with the model name instead of the entity name. When you convert a brush/patch though, it converts it uses a model with the same name as the entity name, so in this case func_static_1 for example. Would it be enough to use that in the skin file? Allthough the wiki article states it's important to add an extension.

Ok I added info about this in on the wiki page: https://wiki.thedarkmod.com/index.php?title=Creating_Multiple_Skins_For_A_Model

I had tried that before, but couldn't seem to get DR to recognize the skins. I may have just been missing something. Even as a programmer, I tend to forget a lot of stuff when I'm tired

Could be- I am still messing with the UI elements but if the brightness is cranked really high it might blow out that background image too much. Its something I can fix down the road.