All Activity

Yup there it is, thanks!

https://www.nytimes.com/interactive/2024/03/26/business/silicon-valley-tech-xerox-parc-sri.html?ugrp=m&unlocked_article_code=1.gE0.gM2G.ilR2kKr-h9Yf&smid=url-share

I liked the book puzzle, however, Surprisingly I didn't manage to find the necessary loot (even playing with easy difficulty), even after finishing other objectives and re-scavenging the whole area. Am I the only one here?

The commit which introduced unconditional writing of the s_mindistance and s_maxdistance spawnargs was this one: https://github.com/codereader/DarkRadiant/commit/541f2638c810588ada12e9a28360f16df6143d45 and it appears it was intended to fix this bug: https://bugs.thedarkmod.com/view.php?id=6062 The current logic is to set the spawnargs to the same values as in the sound shader, if a shader is set: // Write the s_mindistance/s_maxdistance keyvalues if we have a valid shader if (!_spawnArgs.getKeyValue(KEY_S_SHADER).empty()) { // Note: Write the spawnargs in meters _spawnArgs.setKeyValue(KEY_S_MAXDISTANCE, string::to_string(_radii.getMax(true))); _spawnArgs.setKeyValue(KEY_S_MINDISTANCE, string::to_string(_radii.getMin(true))); } This happens in the freezeTransform method which is called after performing some manipulation of the speaker entity such as moving or resizing it. In this case _radii is the object which contains the modified speaker radii, so this code is persisting the modified radii into the relevant spawnargs. This seems to be working correctly when I manipulate a speaker with a valid sound shader. The only way I can get 0 is by creating a speaker with a sound shader like blackjack_swing which does not have radii defined. In this case the speaker has a default minimum radius of 0.0 and a default maximum radius of 10.0. We could avoid setting a radius at all, but then the speaker just appears as an entity box rather than a sphere/circle, which I assume is the original reason for setting a default value. Right now I have no idea what code path would lead to having both a minimum and a maximum of 0.0. I think we'd need more detailed reproduction steps. This is the current logic for setting the spawnargs on speaker construction (rather than manipulation, which is the previous code): // Initialise the speaker with suitable distance values auto radii = soundShader->getRadii(); entity.setKeyValue("s_mindistance", string::to_string(radii.getMin(true))); entity.setKeyValue("s_maxdistance", radii.getMax(true) > 0 ? string::to_string(radii.getMax(true)) : "10"); So there is a specific check that s_maxdistance is greater than 0 before setting it as a spawnarg. Code similar to this has existed for many years, as far as I can see, and I have to go as far back as 2009 to find something different (originally all speakers just had hardcoded 16/32 radii to make them visible).

That is interesting question. I think no? In principle, I guess I can cover it as well. If I want to expose persistent info from mission as gui vars, I can as well copy some gui vars into persistent info before mission.

This last month, I've been exploring TDM's font situation, and improving the documentation as I go. In the wiki, "Font Conversion & Repair" was rewritten, with parts broken out and expanded as: Font Files Font Metrics & DAT File Format Font Bitmaps in DDS Files ExportFontToDoom3 Q3Font Refont As announced earlier, that last item is a new C++ console utility for revising font metrics in DAT files; essentially another alternative to Q3Font and Font Patcher. It now has additional functionality that provides font-coverage analysis. A summary of current results across all TDM fonts is reported in the forum thread "Analysis of 2.12 TDM Fonts". Also, refont allows its human-readable outputs to be decorated with an annotation for each character (out of 256 codepoints). Associated with that, I've just created and released 4 annotation files: 1 Cyrillic version for TDM's russian map 3 variants for TDM's custom english/european char map. One of the variants was derived from another new mapping file that is now available from existing wiki article "I18N - Charset". Within that file is a list, in a standard format, of the 256 TDM bitmap codepoints mapped to the corresponding Unicode U+NNNN value and name. This may be useful in defining TDM's mapping to TTF font editing programs. For all these wiki pages mentioned, I imagine there will be additional cross-links and tweaks. But pretty much done.

Obviously the change will only work in last night's dev snapshot and onward. But missions can already start implementing this: It's just that older TDM versions won't see the debrief screen and only future players or dev users will enjoy them.

Well, the 7600 XT is considered sus for putting 16 GB on 128-bit, but it clearly works in some scenarios. Also IIRC GDDR7 will have about +30% bandwidth over GDDR6X right out of the gate, rising to about +100% as the generation progresses. Big caches (Infinity Cache L3 for AMD, lots of L2 for Nvidia) have made smaller bus widths more viable, and I think they have improved compression techniques and other factors over time to help alleviate bandwidth demands. There's already a little bit of analysis of what we can expect to see in RDNA3+ and RDNA4, very technical though: https://chipsandcheese.com/2024/02/04/amd-rdna-3-5s-llvm-changes/ I am eager to see if AMD is bold enough to do (or allow AIBs to put) 32 GB on the top RDNA4 card, which has long been rumored to be slower than the 7900 XTX in raster, but will hopefully beat it in raytracing and other areas such as AI/ML perf. And I think that card will have a 256-bit bus and 16 GB memory normally.

@The Black Arrow That's a good analysis. I don't disagree but we're referring to different time periods with different quality aims: In the early days of 3D and low-res CRT screens when we had 256x256 textures, detail textures were used to make surfaces appear as if they have 1024x1024 textures... today in the age of 1080p monitors such texture can appear blurry from up close, we want to make 1024x1024 textures appear of 4096x4096 quality. Back then the goal was to get at least a little bit of perceived sharpness, today the goal is to see those microscopic details on every surface as if everything is real... while the concept of detail textures is old it scales to cover both aims. As you correctly pointed out, the ideal solution would be upgrading the actual textures themselves. Sadly there are two big problems with this that will likely never be possible to overcome: Someone must create or find identical textures to replace existing ones, which have to retroactively fit every old FM. That would be a huge effort for so many images, and will not look exactly the same way so people would complain how "this wall used to be made of small red bricks which are now larger and yellower which isn't what I intended and no longer line up". An advanced upscaling filter may be able to bump the resolution with good results, this would be a lot less effort and retain the exact appearance of textures. The even greater issue is storage and memory use would go through the roof. Imagine all our textures (from surfaces to entity skins) being 4096x4096 which would be the aim for decent quality today: TDM could take over 100 GB of drive space, you'd need at least 16 GB of RAM to run it, and the loading time of a FM will be 5 minutes. Detail textures are a magic solution for both problems: They're overlayed in realtime on top of the standard textures without changing their base appearance. This means you see pixels several times the scale of the image without requiring any image to actually be at that resolution, no vRAM or loading time increase. And if detail layers are disabled with distance you also don't lose FPS in per-pixels calculations when distant lights update.

yeah its a jungle out there but a 12 gb card on a 128 bit bus would only be viable with dlss and then only just . but there will probably be plenty of options as you mention though id still go for something that would atleast be able to drag the ammount of vram without workarounds. strangely the old amd R9 390 had a 512 bit bus and could probably have accepted 32 gb vram but the card is to slow to do 4k in modern titles. even so the 8 gb model actually ran quite nicely in games such as the first horizon in 4K but would probably choke and die on forbidden west . minor wtf moment is crysis remastered it runs it at 4k in can it run crysis with a gazillion fps looks quite purty to but i suspect this is a bug.

You don't. That is one of the 3 xy views. So you have to remove one of the other ones. This is how you do it: First uncouple everything and make sure you have 2 (extra) xy-views. Move the camera-view to the side. It takes up the full height Move the first xy-view to the bottom. It takes up the full width. Move the second xy-view to the side inside the other xy-view Now you get this and you can simply resize these windows. Maybe something for in the wiki?

I could be wrong, but I think you could build a button-controled (de)briefing which shows a video on the last slide.

Alright, so, I'm a Texture Artist myself for more than 20 years, which means I know what I'm talking about, but my word isn't law at all, remember that. I've worked (mostly as mods, I am a professional but I much prefer being a freelance) with old DX8 games up to DX12. When it comes to Detail Textures, for my workflow, I never ever use it except rarely when it's actually good (which, I emphasize on "rarely"). This is one reason I thought mentioning that I worked with DX8 was logical. One of the few times it's good is when you make a game that can't have textures higher than what would be average today, such as, World Textures at 1024x1024. Making detail textures for ANY (World, Model) textures that are lower than 128x128 is generally appealable. Another is when the game has no other, much better options for texturing, such as Normal Maps and Parallax Mapping. Personally, I think having Detail Textures for The Dark Mod is arguably pointless. I know TDM never had a model and texture update since 2010 or so, but most textures do seem to at least be 1024x1024, if there's any world texture that's lower than 256x256, I might understand the need of Detail Textures. Now, if this was a game meant to be made in 2024 with 2020+ standards, I would say that we should not care about the "strain" high resolution textures add, however, I do have a better proposition: Mipmaps. There are many games, mostly old than new ones, that use mipmaps not just for its general purpose but also to act as a "downscaler". With that in mind, you boys can add a "Texture Resolution" option that goes from Low to High, or even Lowest to Highest. As an example, we can add a 2048x2048 (or even 4096x4096) world texture that, if set to Lowest, it would use the smallest Mipmap the texture was made with, which depends on how the artist did it, could be a multiplication of 1x1 or 4x4. One problem with this is that, while it will help in the game with people who have less VRAM than usual these days, it won't help with the size. 4096x4096 is 4096x4096, that's about 32mb compressed with DXT1 (which is not something TDM can use, DXT is for DirectX, sadly I do not know how OpenGL compresses its textures). I would much rather prefer the option to have better, baked Normal Maps as well as Parallax Mapping for the World Textures. I'm still okay with Detail Textures, I doubt this will add anything negative to the game or engine, very sure the code will also be simple enough it will probably only add 0.001ms for the loading times, or even none at all. But I would also like it as an option, just like how Half-Life has it, so I'm glad you mentioned that. But yet again, I much prefer better Normal Maps and Parallax Mapping than any Detail Textures. On another note...Wasn't Doom 3, also, one of the first games that started using Baked Normal Maps?

Is it already possible to pass information from the briefing to the mission? I don't think I ever saw this implemented apart from the starter-location selection. TDM is currelently in early dev, maybe a bit soon to start implementing in missions? I think it's better to wait for beta, so no changes will be done to the system.

So back to trying this again, How do I get rid of the layout on the right?

No there is not.

Uh, you surely didn't pick the easiest map to start with. This is more like bat shit crazy complexity. Kudos for persevering and even enjoying it though. It's a nice mission. It's just... big and complex.

God knows since when have I last registered or posted on a traditional internet forum, but had to do so to pay my respects for the developers and map makers of this game. I have no history of the original thief series, and had no expectations for the mod. This is the first FM I played. After running around in a bit of a haste, becoming increasingly desperate of the complexity of the map, I learned to enjoy the feeling of being lost, calmed down and started to pay attention to the surroundings and listening to the ambient sounds and music. It is a truly immersive experience. I do have to admit that I could not find the entrance to the mansion, and had to resolve to a walkthrough to figure out how to enter, and at the end of the day did not manage to finish the mission. This mod is a great achievement, thank you for all the work and passion you have put into it.

Greatly enjoyed the moment of starting the mission and hearing the Beethoven's symphony. Well fit for the atmosphere of the game and provided the mood for the FM as well. I found acting against my own will by shutting off the music.

I agree! I never even noticed that there was a title there. I will include this in my patch until it's included in core...

Thank you for the lovely change! I wonder if anyone can let FM authors know about it: I think this is a great opportunity to update old FM's if their authors are still around and willing to... if anyone does maybe drop a mention here, I'll be happy to replay them for this addition alone.

The new behavior is available in the latest dev17026-10712. If you set cvar s_overrideParmsMode to 1, then you get the new behavior. The old behavior is under value 0, which is default yet. Also there is "debug mode" if you set value to 2. In this case the new behavior is used, but console warnings are posted when a sound being started shows difference in behavior (i.e. the engine computes both behaviors and complains if they are different). Right now you'll see regular warnings about various AI sounds: they have wrong effective volume in TDM 2.12 and before due to this issue. As for modifying the missions, I think the main blocker is the new DarkRadiant behavior. @greebo @OrbWeaver, could you please comment why DR automatically sets s_minDistance and s_maxDistance spawnargs since recently?

The new behavior is available in the latest dev17026-10712. If you set cvar r_envmapBumpyBehavior to 1, then you get new behavior. The old behavior is for value 0, which is default yet. The missions/core files are not adjusted yet. But I'd say everything is ready to do it.

In the latest dev17026-10712, GUI debriefing is supported. It works exactly the same way as GUI briefing. It would be great if someone tries it For the nearest future, I'd like to support passing information from game script to GUI debriefing. So that you could show different things in debriefing depending on what player did in the mission.