Search the Community

"When the leaves change and the air is still, there is a quiet." -Lady Blackbriar -=| DISPLACEMENT |=- BY AMADEUS & WELLINGTONCRAB = DOWNLOAD = <( | )> -PLAYS BEST ON 2.14- -JOIN THE BETA NOW- "Seek not the prideful sin that is perfection The Builder's light shines through all flaws. It is His wisdom to recognize a thing is done Before it is ever truly finished." -St. Edgar's Sermon of Rust LAMPFIRE HILLS... They say the woods around here give the tourists bad dreams, but I don't mind. I like it here. I feel like a piece of me belongs here. ... That it fits. DISPLACEMENT is a medium-sized traditional manor mission with a highly variable playtime. *2.14 provides a number of improvements to gameplay, performance, and stability. It is strongly encouraged to play on the latest 2.14 beta release. Join in testing now!* *Mods such as the “Unofficial Patch” and “TDM Modpack” are not supported by this mission and should be used at your own risk* https://www.thiefguild.com/fanmissions/97429/displacement CREDITS: ADDITIONAL MUSIC: -AIRSHIP BALLET -GIGAGOOGA ADDITIONAL SCRIPTING: -DRAGOFER -OBSTORTTE -FROST SALAMANDER -KINGSAL ADDITIONAL ASSETS: -KINGSAL -TDASH -SKACKY -BIKERDUDE -GOLDWELL -EPIFIRE -STRUNK -SHANNEN ART -POLYHAVEN -TEXTURES.COM -SKETCHFAB CULTURAL HERITAGE CC0 COMMUNITY -LOISTE INTERACTIVE -COLINFIZGIG -CDMIR BETA TESTERS: -KINGSAL -GOLDWELL -MAT99 -FROST SALAMANDER -MIKE A -STGATILOV -STIFU -MARBLEMAN -DETEEFF -THEBIGH FURTHER ACKNOWLEDGMENTS: -STIFU FOR HIS EFFORT IN FIXING THE NOTORIOUS STUCK AI AND ARROW CRASH BUGS. -STGATILOV WHO MADE A NUMBER OF 2.14 OPTIMIZATIONS AND BUG FIXES. -KINGSAL FOR PROVIDING SOME OF THE MAIN MENU GUI ASSETS -PURAH FOR ORIGINATING THE SETTING OF LAMPFIRE HILLS, REIMAGINED HERE, IN HIS THIEF FMS. -GUY-ON THE COUCH AND JAM61 FOR THEIR SILENT HILL COMMUNITY MAPS WHICH HEAVILY INSPIRED THE LAMPFIRE HILLS REGION MAP. -SPECIAL THANKS TO LOISTE INTERACTIVE FOR ALLOWING US TO USE ASSETS FROM THEIR GAME "INFRA." SOME ADDIITONAL DETAILED LICENSING INFORMATION: SOME NOTES ON PERFORMANCE: NOTE TO MAPPERS: MOST OF THE NEW ASSETS IN THE MISSION ARE INCLUDED IN THE 2.14 BETA RELEASE.

I think it's time to replace the frob material stages with a shader (probably add a param to the existing ambient shader) There is more than one angle to this issue but I am mainly concerned about too many stages in materials that are somewhat taxing in terms of performance. Imagine rendering of 3K surfaces interacting with 3 lights in average and using materials with 7 stages in average. The renderer loops through every stage for every surface making it ~ 20K checks per loop. It has to happen during the depth stage, then each light and then the ambient pass resulting in 100K checks. It makes sense to try to reduce this load, especially considering that the frob stage is relatively rarely invoked and the checks happen on the backend making it hard to parallelize the computation. I am thinking adding a top-level material keyword that would apply as frob color and get passed to the ambient shader when the surface is a part of a frobable entity. I would like to hear your thoughts from the mapper/designer POV.

While playing the great free roam mission "Displacement" I often got lost because there were so many areas to explore and I sometimes forgot important places only because I spend too much time chasing something else. What would help a lot with this would be a feature to mark locations on your map with a pin or a cross, e.g. like "Monomyth" does. The latter has four different coloured pins and you can even add written comments, but just left mouse button set a mark and right mouse button remove it should be enough for TDM. Would this be possible as a new feature for 2.15?

@STiFUIm glad to see this is back on the menu! Looks really nice. A neutral grey or a very subtle "golden" hue for all frobable objects is the way to go. Colored shaders can get messy with different lighting scenarios, different loot object colors, always fighting players preferences, ect. Also object specific frob colors will open up a brand new communication channel that wasnt there before. Its just messy imo. I did some early prototypes for colors a long time ago, might be in the dev forums somewhere actually. Anyways, great to see it getting worked on. Thanks for doing it.

Back in the day, Tels managed a squad of volunteer translators for TDM. I am not Tels, and could never do that. Nowadays, language translation using AI, either traditional machine learning (ML) models or large language models (LLMs), is common and increasingly fluent. It is often used as an adjunct to speed the work of professional human translators. By itself, AI translation can be imperfect but usually sufficient. Can this "sufficient" approach be used for TDM, to expedite translations? Let's see. I gave some initial thought to a bulk-translation daemon that might range across FMs and fill in all missing translations, without necessarily involving mappers. In the future, possibly AI could tackle that whole enchilada. I was at first visualizing something more modest: a backbone in a standard programming language (I sketched out C++ and C# projects, but lots of other possibilities) that would make calls to an API (I looked at those of Google Translate and ChatGPT). However, I changed focus due to certain concerns... Different FMs, and subsets with each FM, would likely have far better translations if they were properly grouped, ordered, and translated separately, with an appropriate context (e.g., phrase engineering) added. The FM's mapper is best placed to provide this grouping and context. I'll detail what I mean in the next few posts. The mapper would not be expected to know any TDM-supported languages besides English. Instead, each translated phrase could be back-translated to English and examined. Is the "round-trip" meaning OK, even if the English words have changed? Problematic translations could have their context tweaked and rerun. Many AI systems, particularly for API access, require a billing commitment (e.g., credit card). For a professional translator, this is no problem, and subscriptions allow access to more (and putatively better) models and higher quotas. This seems less appealing for TDM. A few paid AI systems have a no-subscription, pay-as-you-go account tier. The cost per translate is typically pennies. But it does introduce quota- and expense-management, and may exclude API usage. Access via API requires an API key (or at the higher end more elaborate security regime), with attendant key-security headaches. Which AI model is thought "best" for translation? Doesn't matter too much, because we can't afford the best. Furthermore, there's endless churn among AI models, with antidotal reports that a given model fluctuates in quality over time, and successor models can be worse than their predecessors. So, with these concerns in mind, I looked for public web-based AI sites that require no billing and provide low-quota but adequate AI. The mapper would enter and retrieve data manually. I will focus on ChatGPT in this exploration, after a quick preliminary test confirmed some promise. Also, as this exploration proceeds, I hope to propose changes to TDM to make it more viable for "sufficient" quality machine translation. Problem areas are incomplete fonts, space-constraints, and layout issues for translated strings. My proposals will likely surface as separate forum threads. That's enough for now. I'll be trying for 1 or 2 substantive posts per week, as I tackle a particular FM.

Yeah, I guess it was something different, sorry that wasn't any help. I played a couple of times with 2.13 and am going to see what beta of 2.14 is available and will try to load that and see how different the experience is. Good luck and maybe now I'll cause some new problem no one has seen! Going to a new directory with this, I won't update my regular directory until the new version comes out.

I have previously posted about automation efforts in this thread about watching over asset files. I decided to create a more generic thread for whatever discussions related to automation. The most recent version of automation library and scripts (by the time this topic was created) can be downloaded from this link. More information can be found in readme.md. It should run properly against any beta version of TDM 2.07. Some new Python 3 is required to run automation stuff. I'm afraid that decent skills in Python are needed if you want to do anything advanced with it. If you have some tedious work that you regularly do with TDM, and feel that it can be automated, post ideas here. UPDATE: Current version (2019.02.22) is available here. It should run properly against TDM 2.07.

Miscellaneous asset fixes done: * More fixes in fonts and better support for Cyrillic and Romanian (post, 6642, 6661). * Added all missing mipmaps in DDS textures (post). * Fixed shop description of slow match (6629). * wood/panels/trim_wood_grunge_moulding_desat: fixed parallax confusion. * models/md5/chars/builders/guard/builder_armor material: brought back specularmap. * textures/darkmod/stone/brick/blocks_light_stained_trimmed material: fixed specularmap. * prefabs/doors/trapdoor_w-padlock prefab: fixed wrong particle (6662). * prefabs/mechanical/switches/wall_lever01 prefab: fixed frobbox of the lever (6060). * models/darkmod/architecture/doors/door*hinge models: fixed gaps in almost all versions (6671) [02]. * models/darkmod/furniture/wardrobe_open model and prefab: fixed clipping through frame (6272) [02]. * models/md5/chars/heads/female03_head_local and dds/models/md5/chars/heads/face_freckle textures: replaced (5545) [03]. * models/darkmod/readables/book_* model: fixed UV maps in sp1 and red1 versions, texture fix (6672) [03]. * prefabs/doors/curvedtop_door_96x48_3hinge_w-frame prefab: fixed hinge material (3212) [03]. * models/darkmod/readables/book_tome model: minor fixes [03]. New assets added: * atdm:ai_undressed_old_man_01: added new character model, including LODs, ragdoll, swappable head. * textures/darkmod/wood/panels/trim_wood_* material: added red variants. * textures/darkmod/wood/panels/panel_decorative_redder_grated material. * textures/darkmod/paint_paper/gold_pedals_* material: added RGB versions. * textures/darkmod/paint_paper/fleur_* material: added RGB versions. * textures/darkmod/stone/brick/red_worn_dirty_trim_wet material. * textures/darkmod/stone/brick/old_bricks_darkgrey_wet material. * models/darkmod/lights/non-extinguishable/painting_downlight model. * models/darkmod/containers/openable/safe_door_003_* and safe_wheel_003: added wall-in-safe door model and prefabs (6590). And there is a big set of assets added by @Wellingtoncrab and @Amadeus from the upcoming mission "Displacement". New models by TDash: * models/darkmod/furniture/beds/rustickingbed with skins DRustBed* * models/darkmod/furniture/seating/darmch1 with skins ArmCh* * models/darkmod/furniture/desk_pagan with skin JPagDesk2 * models/darkmod/furniture/steps_library with skin LibStepup1 * models/darkmod/mechanical/typewriter * models/darkmod/kitchen/wine_bottles_shelved*: versions A, B, C, D * models/darkmod/kitchen/whiskeyglass_silver * models/darkmod/kitchen/bottle_simple_* * models/darkmod/containers/crate_long_* * models/darkmod/containers/crate_simple* * trunk/models/darkmod/containers/wine_crate_03 * models/darkmod/furniture/cabinets/cupboard_* More models: * prefabs/mechanical/switches/red_button prefab along with models/darkmod/mechanical/switches/switch_redbutton* and switch_toggle* models and redbutton_glow* skins * models/darkmod/decorative/statues/bust_emperor_* model (and bust_emperess) * models/darkmod/kitchen/food/bread_loaf*: new versions 02, 03, 04, 05, 06 * models/darkmod/kitchen/food/croissant * models/darkmod/lights/non-extinguishable/streetlamps/streetlamp_iron_01 with skins streetlamp_iron_01_lit, streetlamp_iron_01_unlit * models/darkmod/decorative/trophy_plaque_* * models/darkmod/decorative/stuffed_hart* * models/darkmod/decorative/statues/statue_face_cover* * models/darkmod/loot/loot_golden_goblet* * models/darkmod/loot/loot_golden_vase_* * models/darkmod/decorative/ashtray * models/darkmod/decorative/cigar* with skins cigar and cigar_unlit * models/darkmod/loot/loot_crystalore* (and loot_rareore) New skins: * cabinet1_* for furniture: versions A, B, C * book_sp1_gold_crest for various books Stone, cobblestone, brick materials: * textures/darkmod/stone/brick/bricks_old_light* * textures/darkmod/stone/brick/blocks_sandstone_grime_trimmed * textures/darkmod/stone/brick/blocks_concrete_small_trimmed2 * textures/darkmod/stone/cobblestones/flagstones_bricks_multicolored* * textures/darkmod/stone/flat/tile_dirty_terracotta * textures/darkmod/stone/flat/tile_herringbone_grime* * textures/darkmod/stone/flat/tile_checkered_grime_tricolor* * textures/darkmod/stone/flat/tile_checkered_grime_small* * textures/darkmod/stone/natural/gravel_multi_color Other materials materials: * textures/darkmod/paint_paper/wallpaper_grunge_* * textures/darkmod/plaster/plaster_worn_painted_peeling_autumnal* * textures/darkmod/roof/rooftiles_clay_red_decorative* * textures/darkmod/wood/boards/planks_floor_* * textures/darkmod/glass/glass_brick_clear [03] * lights/watercaustics01 Note: [03] at the end of line means that this change appeared only in beta214-03.

Bug tracker: https://bugs.thedarkmod.com/view.php?id=6676 Hi, I've noticed some light leaks that only appear when playing with shadow maps (as opposed to stencil shadows). I'll show two cases that I think are not simply errors in modeling/mapping, but rather may indicate a general bug with shadow maps. The first case can be seen in many missions: both of these bucket models allow light to leak inside them from certain angles when shadow maps are enabled (see images below). When playing with stencil shadows, the interiors of these buckets are fully shadowed as expected. I brought this up to some devs, but @Bikerdude found that the bucket light leaks couldn't be fixed at the shadow mesh level, and he suggested it was a general shadow maps issue instead. Hearing this, I realized it could explain a tiny light leak I had seen in my WIP mission. I decided to make a simple test map with similar brushwork to clearly show the problem. So, that test map is the second case: these grid-aligned worldspawn stairs leak light through the corners when playing with shadow maps (see image below). When playing with stencil shadows, the corners between stairs block light correctly (see image below): Out of curiosity I put the buckets in the test map too. The light volume is quite large (776x776x776), which seems to exacerbate the light leak (see comparison images below): I'm playing TDM 2.13 on Windows 11. The test map file is attached to this post if you're curious. Bug tracker: https://bugs.thedarkmod.com/view.php?id=6676 smt.map

https://www.pcgamer.com/games/fps/lasting-consequences-where-every-action-could-leave-a-trail-back-to-you-is-just-what-i-want-to-hear-from-a-medieval-thievery-simulator-so-this-first-person-sneaker-is-now-one-of-my-most-anticipated-games/

TDM 2.14 is ready for beta test This is how to get beta versions: Upgrade from any version (fast): 1 - Start tdm_installer in darkmod folder. 2 - On the first screen, check "Get custom version" and click "Next". Choose the first name in beta/2.14 list, should look like "beta214-NN". 3 - Click on "Refresh" button to ensure that it is not going to download too much stuff. 4 - Continue installing with "Next". Fresh install (slow): 1 - Create darkmod folder anywhere you like. 2 - Download the TDM Installer from downloads section of the website. Extract tdm_installer executable from the downloaded ZIP and place it into your darkmod folder. 3 - Start tdm_installer (in case of Linux, first edit file permissions to allow executing it). 4 - On the first screen, check "Get custom version" and click "Next". Choose the first name in beta/2.14 list, should look like "beta214-NN". 5 - Continue installing with "Next". In general, upgrade is recommended over fresh install. If you don't want to lose your current TDM installation, then you can copy the whole TDM directory and upgrade the copy. This way you can have both 2.14 beta and 2.13 at the same time. At the end of installation, tdm_installer resets your config by renaming darkmod.cfg to darkmod_{datatime}.cfg. This is a recommended procedure on upgrade, otherwise you are likely to have issues due to old config. If you need your old config for some reason, you can always find it in darkmod folder. Notes 1 - Please try to be specific when reporting a problem. What you were doing, where you were when the problem occurred, can you reproduce it, etc. This wiki article provides many suggestions for good bug reports. 2 - This effort is to find out if we broke anything in TDM with our 2.14 changes, if a new 2.14 feature isn't working correctly. We won't be trying to fix bugs that have been around for a long time. Instead, we will create an issue in bugtracker (if not yet present), to fix it after beta. 3 - If you find something wrong, it would be helpful if you report whether the issue happens in 2.13 too. By the way, you can easily get 2.13 version: just copy your darkmod folder and run tdm_installer on the copy, selecting "release213" on the custom version screen. Thank you for testing !

Right now, the change is only on trunk. @stgatilov is preparing the next beta build at the moment. Since we usually don't allow new developments to go in during beta, I let him decide whether to include it or not.

Fixed at Rev. 11144. @Amadeus, @Wellingtoncrab, just a heads up: I renamed the cvars to something more meaningful: r_frobOutlineValuables, r_frobOutlineValuablesColor*. I have also added two new presets 7 and 8 to r_frobOutlinePreset: 7 - geometric, yellow for valuables, grey for junk (STiFU) 8 - geometric, yellow valuables, none for junk (STiFU)

I completely agree! The mission was so complex that I often forgot where I still needed to go while chasing some other direction. What it needs, what TDM needs, is a feature in which you can mark locations on the map! Like in Monomyth. I'll start a new thread on the main board right now :).

I think on 2.14 beta-03, you should be good. We had introduced a major frob handling refactor, new frob control styles and a new long frob door control in beta-02. The latter feature broke a few things, but those are now resolved.

There is a new system in 2.14 for generating smoke particles (6309). In general, it reuses more common code from the other ways to generate particles (particle models and particle deform) and its behavior is more aligned with those other ways. Here are some of the differences compared to the old system that I know of. 1) The new system is FPS-independent. If I'm not mistaken, the old one I think generates 5x particles on 300 FPS and 25% of the particles on 15 FPS. 2) Two systems have a bit different spawning time. Particle stages normally work on periods of length (particleLife + deadTime). In the old system, particles spawn uniformly during the first (bunching * (particleLife + deadTime)) time, while in the new system they spawn during the first (bunching * particleLife) time, same as in particle models and particle deforms. 3) The old system does not respect cycling settings in the particle decl. It plays only one period of every particle stage and stops. However, func_smoke specifically has a high-level logic: it restarts itself if all the particles have been generated. This looks like infinite looping, but all the particle stages have the same period in this case (the maximum one). The new system can respect "cycles" parameter from .prt file if you set spawnarg "use_cycles" = "1" on func_smoke entity. So if your .prt file has e.g. 3 stages with different period and "cycles" = "0", then each stages will cycle infinitely with its own period. And if your .prt has "cycles" "10", then func_smoke will play 10 periods and stop. Note that without "use_cycles" spawnarg both systems just play one period of all particle stages. This is a very recent change. The new system is enabled by default, but it is controlled by cvar g_newSmokeParticles. If we discover serious problems with it during beta, we'll have to flip the cvar...

If I try to rotate a model, only the Rotation option is available in the transformation window. No option to scale: Is this normal? Also not able to do so in NetRadiant-custom. Found a solution: https://wiki.thedarkmod.com/index.php?title=Model_Scaling Mods, please delete. Sorry about being dumb.

Gorgeous FM! Working my way through it now and am enjoying it immensely. So far the only issue I've run into is the "Tasty Beverage" crashing my game to desktop (Linux, 2.13) but I'm not too worried about it. In the mean time, I have a "tasty beverage" IRL to compensate... Belated congrats on the new release!

If the pk4 name changes, the downloader treats it like a new mission. Can't win either way, rename pk4's and players will complain about duplicates in their mission lists.

Thanks for this wonderful new appearance in TDM everything has to be picked to if it´s loot I´ll take it for a Beta - so here some bugs ( minor , bigger and silly ) played on 2.14beta2 more when i go ahead

I'm looking for the bulletin board papers, wanted signs, etc. I've seen them posted on walls in several missions, but I can't find them in the TDM models, readables, decals or prefabs.

This thread is intended for discussing and reporting things about the new frob changes during beta. Most of the description below was already given in a previous thread. Bugtracker: #6658, #6668. New Frob Control Styles I have completely refactored the frob-handling code. Now, it is easy to setup different frob control styles. There are currently 3 (and a half), which you can try in 2.14 beta. Under "Settings > Gameplay > General > Hold Frob/Interact" (cvar tdm_frob_control_style), you can change the frob control style. This setting replaced the previous hold frob delay setting (tdm_holdfrob_delay), because I think that nobody would touch that value unless they want to disable the holdfrob mechanic, which can now be achieved by the new setting as well. The currently available control styles are: Disabled: No hold-frob mechanic, i.e., pre v2.12 control style TDM: Short frob is the same as pre v2.12, but long frob is a shortcut for "grab and then use" (use-type interactions) Thief (v2.12): Same as TDM, but behaviour for bodies is swapped. Body limbs are interacted with via "drag and drop". TDM-inverted: Short frob for use-type interactions, hold frob to "drag and drop" objects (when you release the mouse button, you will release the object) I always loved the drag and drop interaction with body limbs created by Daft Mugi and I wanted to see it consistently extended to all objects, which motivated the refactor. I am very happy with the result and I hope you players enjoy it as much as I do. The Thief control style will still remain the default settings, however, as I didn't want to open that can of worms. Hold-Frob Mechanic for Doors There was previously no hold-frob mechanic for doors, except for experimental manual door control feature. I have added two additional new control modes for hold-frob on doors, which you can activate through the cvar tdm_door_control. The modes are: 0: Disabled 1: Manual door fine control (experimental, existing feature) 2: Hold frob to slowly move doors. They are opened and closed alternatingly, just like regular frobbing a door, but interrupting a moving door is skipped. 3: Hold frob to slowly open doors. Additionally, I added in the ability to quickly force close a door by holding frob and pressing attack. It felt like mode 3 ("Slow Open") gave the most benefits and most direct controls to the player and pairs well with the force-close mechanic. So, I just set "Slow Open" as the default and I did not add it to the settings menu, but you are of course encouraged to try the other modes as well. The idea behind this addition is that the player can now slowly sneak and peak through a door, but then can also quickly shut the door again if the player deems the situation unsafe. This adds more skill expression and creates further immersion. 2.14 Beta Please use this thread to report any issues with frobbing (always state tdm_frob_control_style and tdm_door_control configuration), the new door control modes (please test them rigorously) and to give feedback on any of the above changes. Pinging players that previously showed interest in this: @wesp5, @snatcher, @Baal, @Skaruts, @Wellingtoncrab, @Amadeus

Thanks for the hint. I'm pretty sure I noticed this when I rode the elevator the first time, but then forgot about it because the mission is so huge and complex! I don't know if this is the correct solution, but I stopped the elevator with my head and got the final item ;). Then I entered the break room, but nothing happened. Was that it? As with the cats, an optional objective that appears when you talk with Curio would have made this easier. Also I still have the interesting key and the mysterious potions. Overall a really fantastic mission though, with lots of cool new assets which made it look fresh !

My patch only changes minor things that shouldn't directly affect a mission and it never has stopped me from finishing one. I was just surprised that the main objective of Displacement was reached so easily with no need to explore much of the map! I did the cat thing in the meantime, got the relic and then it was clear what to do. A great new area you created down there! Now guessing from Curio's shelf space and comments here I still need to find a special loot item. Any hints about the snails and the lamps lying around? Also I still have the interesting key and haven't found the door for it yet... P.S.: I found another special loot item now and sold it. But nothing special happened. I found six items...

There are two ways to override cvars in a mission: mission.cfg file can set non-archived cvars (starting with 2.12). sys.setcvar in game script can override cvars (starting with 2.13 / dev17044-10746). Of course, there has never been any effort to classify cvars into public and private, no thinking of backwards compatibility of relying on cvars, etc. So overriding cvars should be considered a last resort feature. mission.cfg allows to statically override cvars on FM level. The change takes effect during all missions in a campaign and all briefings/debriefings/menus. However, you cannot adjust cvar value during gameplay, so only one constant literal value can be set. The implementation is simple: mission.cfg file is executed from your mission when TDM engine starts all non-archived cvars are reset to their defaults when TDM engine restarts (due to FM change) sys.setcvar allows to override cvars on gameplay level. These overrides behave like the variables in game scripts, i.e. they are saved/restored to savefile and reset on game start/end. You can adjust the same cvar several times with different values, and savefile will capture the override that is currently active. The minor downside is that these overrides automatically don't carry over between missions in campaign, and they cannot work in briefings/debriefings/menus. Note that sys.setcvar has been available for a long time already, but previously it had different meaning. Previously it set the cvar as if the player set it himself. So the values stuck between restarts, missions, FMs (even saved to darkmod.cfg for archived cvar). Now it always sets the "mission override" for cvar. You can test cvar mission overrides manually using two new console commands: setm {cvarname} {newvalue} --- set mission override for the cvar with given value unsetm {cvarname} --- drop mission override for the cvar It is not perfectly obvious what should happen if mission-overridden cvar is changed by user. Right now the main value of cvar is changed and mission override is broken/erased in this case. So be wary that user can mess with your overrides just like you can mess with his cvars. See also: 5453