Search the Community

The new update sounds very exciting! Already got it and will probably play a new FM again soon. I wasn't sure if lights make full use of portals in order to ditch even more calculations, awesome to hear that's now on the list too Reminds me of something I asked a while ago, don't think anyone knew the answer with certainty: When using a targeted light / spotlight, does it improve performance compared to omni lights? I wasn't sure if the engine knows to calculate only inside the cone they're pointing at, or if behind the curtains it still treats them as 360* projections and just visually makes them a cone. If there's an improvement I was wondering if hooded lights could be made like that by default. Visually there should be no difference: I experimented with the outdoor lamp once, by default it still shines in all directions... you don't see anything above anyway since the model self-shadows, we could likely get it looking almost identical with a wide cone. Just thought it might be a good idea to bring this up now that I remembered, for now a nice new optimization to enjoy

I hope I'm not proposing some unfeasible idea that was already imagined before, this stuff is fun to discuss so no loss still. Riding the wave of recent optimizations, I keep thinking what more could be done to reach a round 144 FPS compatible with today's monitors. An intriguing optimization came to mind which I felt I have to share: Could we gain something if we had distance-based LOD for entity updates, encompassing everything visual from models to lights? How it would work: New settings allow you to set a start distance, end distance, and minimum rate. The further an entity gets the lower its individual update rate, slowly decreasing from updating each frame (start distance and closer) to updating at the minimum rate (end distance and further). This means any visual change is preformed with frame skips on any entity: For models such as characters animations are updated at the lower rate, for lights it means shadows are recalculated less often... even changes in the position and rotation of an entity may follow it for consistency, this would especially benefit lights with a moving origin like fireplaces or torches held by guards which recalculate per-frame. Reasoning: Light recalculation even animated models or individual particles can be significant contributors to performance drain. We know the further something is from the camera the less detail it requires, this is why we have a level-of-detail system with lower-polygon LOD models for characters and even mapmodels. Thus we can go even further and extend the concept to visual updates; Similar to how you don't care if a far away guard has a low-poly helmet you won't notice, you won't care if that guard is being animated at 30 FPS out of your maximum of 60, nor if the shadow of a small distant light is being updated at 15 FPS when an AI passes in front of it. This is especially useful if you own a 144 Hz monitor and expect 144 FPS: I want to see a character in front of me move at 144 FPS, but may not even notice if a guard far away is animating at 60 FPS... I want the shadows of the light from the nearby torch to animate smoothly, but can care less if a lamp meters away updates its shadows at 30 FPS instead. The question is if this is easy to implement in a way that offers the full benefit. If we use GPU skinning for instance, the graphics card should be told to animate the model at a lower FPS in order to actually preserve cycles... does OpenGL (and in the future Vulkan) let us do this per individual model? I know the engine has control over light recalculations which would probably yield the biggest benefit. Might add more points later as to not make the post too big, for now what are your thoughts?

I don't recall a system for noise masking. It sounds like it'd be a good idea, but when you get into the details you realize it'd be complicated to implement. It's not only noise that that goes into it, I think. E.g., a high register can cut through even a loud but low register rumble. And it's not like the .wav file even has data on the register of what it's playing. So either you have to add meta-data (which is insane), or you have to have a system to literally check pitch on the .wav data and paramaterize it in time to know when it's going to cut through what other parameters from other sounds. For that matter, it doesn't even have the data on the loudness either, so you'd have to get that off the file too and time the peaks with the "simultaneous" moment at arbitrary places in every other sound file correctly. And then position is going to matter independently for each AI. So it's not like you can have one computation that works the same for all AI. You'd have to compute the masking level for each one, and then you get into the expense you're mentioning. I know there was a long discussion about it in the internal forums, and probably on the public subforums too, but it's been so long ago now I can't even remember the gist of them. Anyway the main issue is I don't know if you'll find a champion that wants to work on it. But if you're really curious to see how it might work, you could always try your hand at coding & implementing it. Nothing beats a good demo to test an idea in action. And there's no better way to learn how to code than a little project like that. I always encourage people to try to implement an idea they have, whether or not it may be a good idea, just because it shows the power of an open source game. We fans can try anything we want and see if it works!

I'm using the version from kcghost. I just tested and I can't see any difference inside the inventory. On the stats itself it doesn't show the different loot types (still seen in the inventory), but instead gives more info on stealth score. Edit: I see Dragofer made an updated version of his script. I have to check that out. Edit2: That version works: https://forums.thedarkmod.com/applications/core/interface/file/attachment.php?id=21272&key=02755164a3bed10498683771fe9a0453

I looked but didn't see this video posted in these forums. It's pretty cool.

It wasn't a "sacrifice", it was a deliberate decision. People wanted the game to be as close as possible to the original, including pixelated graphics. If you ask me, the former version based on the Unity engine looked and felt better. But, hey... I guess I'm not the right person to judge that, as I never played the original, and always found that the art style of System Shock 2 is much better anyway. This also illustrates the issue with community funded games: Too many cooks spoil the broth. In game design, you need freedom, not thousands of people who want you to do this and this and that. Just take a look at the Steam forums and see how all those wimps complain again about everything. Hopeless.

So giving it none of those tags, but making the AI invisible, silent, non-solid, and on a team neutral to everyone would not work? Oh well, it was a horrible inelegant idea anyway.

What I understood is that the idea of TDM was born from that it was unclear if T3 would get a level editor at the time. Source: https://web.archive.org/web/20050218173856/http://evilavatar.com/forums/showthread.php?t=268

This one is really essential: https://www.ttlg.com/forums/showthread.php?t=138607 Should work fine with the GOG version.

https://www.ttlg.com/forums/showthread.php?t=152224 There is a new mapping contest over on TTLG for the Thief: Deadly Shadows 20th Anniversary and the organizers were kind enough to include The Dark Mod along with all of the Thief games as an options for making a mission to submit as an entry. The deadline is a year from yesterday and the rules are pretty open. I recommend going to the original thread for the details but I will summarize here: Rules: - The mission(s) can be for Thief 1, Thief 2, Deadly Shadows or The Dark Mod. - Collaborations are allowed. - Contestants can use any custom resource they want, though TDM cannot use the Deadly Shadows resource pack. - Contestants can submit more than one mission. - Contestants can enter anonymously. - The mission(s) can be of any size. Using prefabs is allowed but the idea is this is a new mission and starting from an abandoned map or importing large areas from other maps is not allowed. Naturally this is on the honor system as we have no way of validating. Mission themes and contents: There is no requirement from a theme or story viewpoint, however contestants might consider that many players may expect or prefer missions to be celebratory of Thief: Deadly Shadows in this respect: castles, manors, museums, ruins inhabited by Pagans and the like, with a balance of magic versus technology. This is entirely up to the authors, though, to follow or not - it is just mentioned here as an FYI and, while individual voters may of course choose to vote higher or lower based on this on their own, it will not be a criteria used explicitly in voting or scoring. Deadline: May 25th, 2024 at 23:59 Pacific Time. See the TTLG thread for details on submissions and the voting process. Provided I can make the deadline I hope to participate. It would be nice to see the entire community do something together, and expressing our complicated relationship with this divisive game seems as good a pretext as any.

OK that makes sense. Looking at some of the other window material definitions some of them don't have that keyword. Also, if you are outside and noclip up so you are outside the window next to the other lamp (the standing copper one), you can see the lightgem light up. So I guess one workaround if you really wanted to use that material is to just make your own version and remove the 'noshadows' from it?

Yeah I just noticed also, the lamp from outside is also bleeding inside through the windows when the door is opened.

It's not that lamp - it's the one above it

Try deleting the lamp and adding it back in? Make sure it isn't set to no_shadows as one of it's spawnargs?

I have no idea what's causing this. It's the oil lamp just inside that window on the upper deck of that room. Stuff like this drives me crazy. Also, while I was just sitting outside staring at it, sometimes the light bleed would just suddenly appear even when the door was closed, or it would remain visible after the door was closed and would disappear if you moved/looked around. I thought it might have been another door opening somewhere, but that doesn't appear to be the case. I can't seem to reproduce this at all. I thought it was a similar issue that I had in another section with the ambient light changing slightly, but I can't see any difference crossing between those rooms. Anyone else notice it?

Thanks, @Goldwell! The animations are so fast that your sounds are way too long but your samples are so rich that I found a nice texture that I think gives the lamp some personality. Hope you like the result. v0.4 at the bottom. Console command to spawn the lantern: spawn mod:weapon_playerlamp z_handheld_lamp_v0.4.pk4

Was this model made in DR? The uvmap is all over the place, meaning it falls outside the 0 1 area. But that is not the problem, the problem is that It add a missing face in the back of the lamp thing, so you could see to the outside thought it. I put a face there that should solve the problem. mod_playerlamp_model.lwo

@HMart You can find it here (under models/darkmod/weapons): https://github.com/thedarkmodcommunity/mod-handheld-lamp direct link: https://github.com/thedarkmodcommunity/mod-handheld-lamp/blob/main/models/darkmod/weapons/mod_playerlamp_model.lwo

You maintain it for FMs and I offer it for general use. The more people toying with the lamp the more feedback / support we may get. I noticed the lens part of the model is transparent. We need a modeler.

Nice! I've got a branch where I'm converting it to a version that can be added to an FM. The scripts can be loaded via tdm_custom_scripts.script instead of tdm_user_addons.script. I got all that working, but then ran into the double lamp thing. I might separate these into different repositories - but then do we think we need both versions? What are the chances of anyone using this as a mod?

It seems we killed two birds with one stone (double model / lights on) by moving the attachment from the entity to the animation: anim idle models/md5/weapons/mod_playerlamp/idle.md5anim { frame 1 attach mod:attachment_playerlamp hand_r frame 1 sound_weapon blackjack_sheath frame 12 melee_hold } The lamp no longer auto-spawns but script/tdm_user_addons.script is still required to load script/mod_weapon_playerlamp.script. Console command to spawn the lantern: spawn mod:weapon_playerlamp In v0.2 I also updated def/tdm_player_thief.def to version 2.11 (thanks to @Dragofer). z_handheld_lamp_v0.2.pk4

Can confirm. Any idea why this is? Is it because of this line? https://github.com/thedarkmodcommunity/mod-handheld-lamp/blob/f871527938df96a7efc308fc3ee85c70d8271544/def/mod_weapon_playelamp.def#L38 Other weapons (like the shortsword) have this attachment as well, but they don't show up attached to each other like that. We could just have a separate entity of that model to just for the plater to frob and kick off a frob_action_script to set everything up instead I guess?

That's right. If a mapper decides to adopt tdm_player_thief.def then the next question is: how do you let players know where the lamp is / how to use it? The lamp can replace the blackjack, sword or any arrow type. Just let the player know which slot it is replacing. The lamp can remain in one of the unused slots but then players must know how to cycle through weapons or you must invite them to check the in-game inventory screen. The lamp can remain hidden in one of the unused slots and players could have an item (inventory tool) that operates the lamp. The lamp can remain in one of the unused slots and you can force-bind a dedicated key for players and ask them to use that key. This method is a little intrusive - use at your own risk. Now, if you want players to pick up the lamp then there's more work ahead. When I tested this feature with the lamp model another lamp was attached to my lamp (two models). Furthermore, the lamp was on by default. Perhaps we want to start there. And thinking of improvements, since the lamp is a weapon, it could be operated with the attack button: Click: open aperture (low intensity) Click: medium intensity Click: high intensity Click: close aperture

It looks like script/tdm_user_addons.script just adds the lamp to the player inventory, so that can be removed and a mapper could just spawn the lamp in a map somewhere and the player could pick it up. And in def/tdm_player_thief.def an extra weapon attachment is created for the lamp. If this could be done dynamically in a script we could remove that file as well. Has anything else in this file been changed (or do we need to get the diff viewer out...)?

Great initiative! Thanks for that. Anything you want. The more stuff going on, the merrier. Looking forward to the results! You are the keeper. I don't think I will be toying with the lamp again any time soon because I met a dead end and I don't know how to bring it to the game without touching core files. I tried - just to see if I could - replacing the lantern with the lamp but both items exist in different worlds (tool vs weapon) and it required more tricks than I am willing to do (keep it simple).