Search the Community

Many forums with an off-topic subforum end up with some political talk in there.

I just added a bugtracker ticket about this work: 0006642: Extend Mason Font to All Cyrillic Characters For the benefit of that post, let me add a summary of the current situation. Current Workplan Originally, TDM's Mason was likely generated from Mason Alternate TTF, which has no Cyrillic coverage. Subsequently, some Cyrillic characters needed for TDM's main menu were presumably hand fabricated. To avoid further tedious hand-work, the strategy is to use just-developed program ExportUnicodeFontToDoom3 (see wiki) to harvest Cyrillic characters into supplemental DDS files and corresponding DAT. Source TTFs that have the required Cyrillic glyphs were reviewed. A distinctive aspect of Mason Alternate's style is that angular lines (like the sides of "A") are terminated by serifs that are stroke-perpendicular instead of horizontal. Other reviewed TTF fonts, including Regular Mason (and clone MasonChronicles) do not feature that. Thus, Mason TTF is an okay but not precise match to the Mason Alternate style. It is good match for some characters, but less for others, where it substitutes curved lines for angular ones. It has unpromising licensing. Of TTF fonts with Cyrillic coverage and open-font licensing, Lora has an adequate (though not precise) stylistic match, with the desired angular lines. Lora coverage and character style were shown in a screenshot earlier in this thread. The current workplan is to have a 3-way merge of existing TDM /english/ Mason (which has crisper ASCII characters), existing /russian/ Mason, and newly generated Lora characters. The existing TDM Mason font has some hand-drawn Cyrillic characters, of variable quality, that may be stylistically preferred over Lora. Lora characters will be scaled and custom-aligned as appropriate. Kalinovka and Geep have a private DM going, including a spreadsheet to manage decisions about individual characters.

Absolutely. In my opinion, Arkane Studios really just figured out balancing in Dishonored 1. Dark Messiah of Might & Magic also has its balancing flaws... play the game on anything but "Normal", and you know what I mean. Anyway, I didn't want to demotivate you. Just saying that there potentially could be difficulty issues later in the game. I think a melee character with some magical affinity would work well. But, yeah, usually, I also tend to a stealthy ranged character. In Skyrim or Fallout, I play that way. In Gothic, ranged characters are completely useless too.

ttlg seems to down again at least for me I tried different forums but got same message that there is a problem connecting to site!

The Problem Readables are available in a wide range of TDM bitmap fonts. Unfortunately, the majority of these fonts lack non-ASCII glyphs for European languages, and it would be a prohibitively lengthy task to craft them. This is one of several translation hurdles. (Another is soliciting, organizing, and distributing the work of human translators; see “AI for Translations: An Exploration” for work on an alternative. This also promotes the use of meaningful alphanumeric #str_ IDs - possibly automatically generated – instead of traditional numeric.) A Proposed Solution Suppose that when a particular page of readable is shown, it is shown first is English, with the mapper-specified font (e.g., Camberic), and then, after a number of seconds, shown in the current user-selected language, with a different font (e.g., Stone), one that offers the needed diacritics? And with the translated font size scaled down to accommodate potentially more-lengthy translated strings? Both the English and translated text can be viewed in sequence. That opens the door to “quick and dirty” default translations, e.g., machine translation. In particular, the reader may sometimes be able to work-around any layout problems and sub-optimal translation by consulting the English text. (Nevertheless, default translations may sometimes miss subtle nuanced hints, so the ability to improve them with tweaked text is a necessity.) The Proposed Mechanics Recall that the game engine currently passes these values to a readable’s gui: gui::title gui::body With a multipage readables, the content of these parameters changes as pages are flipped. For clarity, it is proposed to replace them with: gui::titleEnglish gui::bodyEnglish gui::titleTranslated gui::bodyTranslated The latter 2 would be just like gui::title and gui::body, except that they would serve empty strings when the current language is English or there is no translation available in the current language (and so be used for gui code program logic, to suppress a transition). Observe that this behavior does not substitute an English string for a missing non-English string. Skip the remainder of this section if details are not of interest. Each stock readable .gui would need a one-time conversion to use them. Instead of the traditional 2 winDef overlays for text, there would be 4, corresponding to the 4 text-passing parameters just mentioned. This allows the translated text to fade in while the English text fades out, when an onTime event starts the transition (at 2 seconds in this example). Here is the fragment of .gui code that has been altered: Aspects of this Design – Transition from English The transition is timed, so no extra “Translate” button is shown, nor a hard-to-come-by hot key required. If you want to see the English again, you would briefly navigate away from the page to another, then return; or, if a single-page, close and re-open it. A simple implementation (as the code above and example below) uses a fixed, hard-coded time. Alternative Mechanism. At some cost to code clarity, it is probably possible to get by with just the 2 normal text-passing parameters (gui::title and gui::body) and their traditional 2 overlays, though additional variable(s) would be needed for tight time-synchronization between engine and gui; and overlapping fade-in/fade-out between English and translation would not be possible. Advanced Version. In the longer term, timing could be made more flexible, by passing it as parameter from the engine, e.g.: “gui::transitionTime” Where does this value come from? While it could somehow encoded into the .xd file by the mapper, I prefer a different approach. Have the engine calculate it from character or word count of the body, with user-specified globals for reading rate and min and max bounds, e.g.: sys_readablesWordsPerSecTransTime sys_readablesMinTransTime sys_readablesMaxTransTime A drawback of a timed transition is that additional reading time is needed to get to the translations, which may, with immobile readables, increase risk of discovery by guards. So having these additional user controls would let a user get to the translations faster, even skip the English entirely by setting bounds to zero. A Simulated Example – FM “readableTranslationFadeIn” In the absence of engine support for the 4 text-passing parameters, it is still possible to make an approximately-functional mockup using some hard coding. However, this prototype DOES NOT suppress the transition when the current language is English. That is, it shows (rather than prevents) an English-to-English transition with change of font & font-scale. TDM with the languages set to “Francais” (French). The first screen shot shows page 1 of a 3-page scroll, momentarily displayed in English with Camberic title and body. After a few seconds, it transitions to the second screen shot, in French in Stone font. With accents. While shown here as a scroll, this approach should be easily adaptable to books and sheets. About the Example’s Implementation The screen shots are from a prototype FM: readableTranslationFadeIn Notable files are: guis/readables/scrolls/scroll_calig_camberic.gui, a custom override of the standard Camberic scroll readable, with the translation transition mechanism from above, plus additional simulation fakery described below. strings/all.lang, a UTF-8 file containing 6 #str_ (2 per scroll page – title & body) in each language section. Only the [English] and [French] sections were implemented. The English example content was loosely derived from the St. Lucia FM. The English text (without #str_ structuring) was manually converted to UTF-8 French using Google Translate (website, not API). strings/english.lang & french.lang. These were generated from all.lang using my gen_lang_plus program to create the 8-bit “ANSI” versions as required, e.g., ISO-8859-15 encoding for French. xdata/readableTranslationFadeIn.xd, that contains the #str_IDs for the 3 scroll pages. Within scroll_calig_camberic, this simulation had this fakery: “gui::title” and “gui::body” were stand-ins for hypothetical parameters “gui::titleTranslated” and “gui::bodyTranslated”; The English text was hard-coded, and the appropriate content selected by actual parameter “gui::curPage”, to make up for missing hypothetical parameters “gui::titleEnglish” and “gui::bodyEnglish”. The READABLE_FADE_TIME is currently set to 2 seconds for testing. Probably 5-6 seconds would be better during game play. Aspects of the Design – Font Scaling As mentioned earlier, the translated font is scaled to make the text smaller than the original, to accommodate languages that need more room. A simple implementation (like in the example code) uses fixed values with “textscale”. So the textscale for the two Translated winDef overlays is smaller than for the 2 English winDef overlays. Specifically, in the example GUI code, the text scaling factors from the original Camberic readable were retained: textscale 0.4 // titleEnglish textscale 0.31 // bodyEnglish and supplemented by (with a different font, namely Stone): textscale 0.33 // titleTranslated textscale 0.24 // bodyTranslated The goal is to keep the rendered text smaller than the original English rendering for languages with more characters per sentence. These values, while hard-coded, will differ across readables (due to different starting fonts), and would need to be experimentally determined. But this treatment, with just a fixed scaling value that is independent of both text content and current language, is unlikely to be very satisfactory. Better ideas, needing additional engine modifications, will be considered in a follow-on post. Additional Considerations When Authoring the XD File. Recall that TDM is relatively inflexible when using #str_ within an .xd file. So this form will not work: "page1_body" : { "" "" "#str_fm_scroll_camberic_pg1_body_parish_inspection_excerpts" } Instead use "page1_body" : "#str_fm_scroll_camberic_pg1_body_parish_inspection_excerpts" With the 2 leading linebreaks moved into the #str content as leading \n\n. When Testing. If there is a mismatch between the TDM Language setting and the PC’s language setting (e.g., under Windows), then some characters may turn out wrong or indicated as missing (e.g., as boxes). The degree will vary by language, and is unlikely to be seen in the initial English render (because that’s almost all in ASCII, common to all the ISO encodings.) Even with such mismatches, the translation can be reviewed as to overall length and where linebreaks occur. Be aware that direct editing of *.lang files is not recommended, and could risk converting from a particular “ANSI” raw 8-bit encoding into “UTF-8”. Applying this Technique More Broadly. A few fonts have oddball glyphs for certain characters, e.g., a skull and crossbones in Treasure Map. This would require special handling during translation. For Briefings, Objectives, and Messages, similar approaches can be conceived. However, for each of these (and different from readables), only one particular font is routinely offered. And there are alternative designs to be considered. For instance, the English and Translated text could be shown simultaneously side-by-side in various ways, instead of sequentially. The Objectives have the additional complication that the font size is already user-adjustable.

Hello! Tracking down information on software and plug-ins that work with D3 / TDM can be a tough. So I have created a thread here where people can post what software/ plug-ins/ tutorials or other references they've had success or failure with in TDM. 3DS MAX 2013 64bit .ase - Default .ASE model exporter works. However you have to open the .ase file in text edit and manual change the *BITMAP line on each material to read something like: "//base/textures/common/collision" which allows the engine to read the correct material path. md5.mesh / animation - Beserker's md5 exporter/importers for 3dsmax. http://www.katsbits.com/tools, Importing and exporting works. The model must be textured, UV'd, with a skin modifier attached to the bones to export. PM me (Kingsal) for help with this. Imported models using the script will not be weighted appropriately, so this is not recommended if you are simply trying to edit existing tdm content. (Use blender instead) MAYA 2011 32bit md5.mesh - So far I've not had any luck with Maya 2011. I am using Greebo's MayaImportx86 for Maya 2011. I've got the importer working however I get a "Unexpected Internal Failure(kFailure)" and the import fails. This could be due to something finicky in Maya that I am not doing correctly. Will keep trying.. Blender 2.7 about - Blender is commonly used and pretty well supported on the forums/ wiki. Various versions may work as well - https://www.blender.org/download/ md5.mesh / animation Blender MD5 importer/exporter (io_scene_md5.zip): https://sourceforge.net/projects/blenderbitsbobs/files/ Sotha's guide Blender Male/ Female rigs by Arcturus - Here Edit by Dragofer: more links found in this post.

Boy, oh boy, these stories really take the fun out of playing. By four hours of playtime, I actually meant about four hours of game progress; in reality, it took me somewhere between 10 and 15 hours (had to look into walkthroughs as well as I had no clue what to do), but I hoped things would get easier with a higher character level. If you obviously can't do it with stealth and a bow and arrow, then that's a major design flaw. It's a shame, I was really looking forward to it, but I don't think I'll continue playing now, because it sounds brutal, what's still to come in terms of difficult stuff. So I'm not surprised that the game didn't become that well known back then, if it's so unbalanced. Unfortunately, I can't play the demo because I can't get it to run on Linux. Thus, this sounds completely crazy, hard to believe for me. If there really will be all these changes/additions/improvements, this would be the biggest sensation since the circus games of the ancient Romans.

I definitely think some of the spells are pretty powerful, almost essential later in the game. Whether or not you can also beat the game with a stealthy ranged character, I don't know. I only can say that I had issues later in the game, but, maybe I'm just too bad at playing it, or distributed my skill points unwisely. I'd just go on and see how you do with your character. Frankly, casting the spells is a bit fiddly in the game anyway, so, maybe you will want to avoid that completely. Some more food for thought: Sounds exactly like the problems I ran into, haha.

Wonderful game (Arx Fatalis), even though it has slight balancing issues, and punishes you when you're not playing as a character excercising magic, IMO. At some point, I had to quit my playthrough, because some enemies became too much for my sneaky ranged attack character. Cralon looks interesting (I've watched it for some time now, although I have some concerns about the overall quality, because it's a 2 person project, with a lot of licensed assets, and some things the developers made themselves, but they're rather semi-pro at it (like the soundtrack). We will see.

testLora Released (Aug 30 version - run4) testLora.pk4 This shows an experimental FM, run 4 of testLora. It's certainly not the final product. The idea is to generate the Cyrillic characters for /russian/mason/ from a TTF font that has them (unlike MasonAlternate, the traditional TDM "mason" font), but is not too unlike MasonAlternate in style. And has a license we can live with. During generation, scaling was done (by using ExportUnicdoeToDoom3 with 45pt as a stand-in for "48pt"). As the screenshot shows, this makes the Lora lower case characters the same height as MasonAlternate lower case. However, the Lora upper-case characters, unlike MasonAlternate are not yet scaled up by 120% nor top-aligned. (Nor will they be at this point in the experiments.) The final product will likely have complex 3-way character sourcing, from MasonAlternative ASCII, some MasonAlternative Cyrillic, some Lora Cyrillic. Restating the briefing: Here's a mockup TDM character set, within-world, for a mixture of Mason and Lora fonts for Russian characters. This version of the FM has - - at codepoints 0x00-0x7f, the TDM 2.13 Mason ENGLISH characters. Most of these are crisp due to enlarged bitmaps. - at codepoints0x80-0xff, there's freshly generated Lora 45pt (passing as Mason 48pt) for Russian character set. Make sure TDM's language is set to Russian. On a room's floor, all cp1251-defined (and thus DAT-defined) printable glyphs are laid out, to quickly reveal missing & bad characters. They are shown twice, to evaluate 'stray marks' (due to bounding box overlap of neighbor glyphs) & vertical/horizontal 'spacing' [shown in screenshot]. View it all from the ledge (or noclip), or walk the floor for close inspection. No special top-alignment or per-character scaling yet. If used in an FM (as here), this font will not include 'glow' enhancements.

============== -= IRIS =- ============== WELLINGTONCRAB TDM v 2.11 REQ Ver. 1.3 *For Maureen* -=- "Carry the light of the Builder, Brother. Unto its end." -Valediction of the Devoted "What year is this? Am I dreaming?" -Plea of the Thief Dear Iris, I am old and broken. When we were young it felt like the words came easily. Now I find the ink has long dried on the pen and I'm as wanting for words as coin in my purse. I can tell we are nearing the end of the tale; time enough for one more job before the curtain call... ============== -Installation- Requires minimum version of TDM 2.11 **Dev build dev17056-10800 (2.13) fixes several visual effects which have been broken in the mission since the release of 2.11. For that reason playing with that version or later is currently recommended** -Iris does not support mods or the Unofficial Patch- Download and place the following .pk4 into you FMs directory: Iris Download ============== *Thank you for playing. Iris is a large mission which can either take as quickly or as long as you are compelled to play. I hope someone out there enjoys it and this initial release is not completely busted - I tried the best I could!* *Iris both is and isn't what it seems. If commenting please use spoiler tags where appropriate. If you are not certain if it would be appropriate a good assumption would be to use a spoiler tag* *Support TDM by rating missions on Thief Guild: https://www.thiefguild.com/* ============== WITH LASTING GRATITUDE: OBSTORTTE - Whose gameplay scripts from his thread laid the foundation which made the mission seem like something I could even pull off at all. Also fantastic tutorial videos! DRAGOFER - Who built upon that foundation and made it shine even brighter! And whom also provided immeasurable quantities of help and encouragement the past couple years on the TDM discord. ORBWEAVER & GIGAGOOGA - For generously offering their ambient music up for use. EPIFIRE - Who lent me his fine trash and trash receptacle models. AMADEUS - Who was the first person who wasn't me to play the damn thing and provided his excellent editorial services to improving the readers experience playing TESTERS AND TROUBLESHOOTERS: AMADEUS * DATISWOUS * SPOOKS * ALUMINUMHASTE * JAXA * JACKFARMER * WESP5 * ATE0ATE * MADTAFFER * STGATILOV * DRAGOFER * KINGSAL * KLATREMUS - What can I possibly say? Playing this thing over and over again could not have been easy. Deepest thanks and all apologies. -=THANKS TO ALL ON THE TDM DISCORD AND FORUM=- ==SEE README.TXT FOR ADDITIONAL ATTRIBUTIONS & INFORMATION== HONORABLE MENTION: GOLDWELL - If I hadn't by chance stumbled into Northdale back in 2018/2019 I would probably still be trying to get this thing to work in TDS, which means it probably would not exist - though more details on that in readme. ============== Boring Technical Information: *Iris is a performance intensive mission and I recommend a GTX 1060 or equivalent. I find the performance similar to other demanding TDM missions on my machine, but mileage may vary and my apologies if this prevents anyone from enjoying the mission.* *Iris heavily modifies the behavior of AI in the game, how they relate/respond to each other and the player. So they may act even stranger than they do typically in TDM. Feedback on this is useful - as it can potentially be improved and expanded upon in future patches.* -=- This is my first release and it has been a long time coming! If I forgot anything please let me know! God Speed. 2.10 Features Used:

Hidden Hands: Blood & Metal Available via TDM Mission Downloader ============================================================== Title: Hidden Hands: Blood & Metal Filename : hhbam.pk4 Author: Jack Farmer Date of release: 01.09.2024 (Version 1) - 14.09.2024 (Version 2) - 28.09.2024 (Version 3) - 28.11.2024 (Version 4) - 25.07.2025 (Version 5) EFX: Yes Subtitles: Yes ============================================================== Hidden Hands series: I - Initiation II - Vitalic Fever III - The Lost Citadel IV - The Anomaly V - Blood & Metal ============================================================== Jack Farmer: mapping & drafts, briefing videos Amadeus: revision/editing of all texts for readables, narration and dialogues Joebarnin: custom scripts & prefabs and trouble shooting Datiswous: subtitles for all conversations, broadcasts, recordings and thief comments Dragofer: consultation for scripts, models and trouble shooting =============================================================== Beta testers: Cambridge Spy Mat99 Bergante Joebarnin wesp5 grodenglaive TheUnbeholden Acolytesix CrisiusXIII Release testers: Mat99 AluminumHaste =============================================================== Voice actors: AndrosTheOxen (all missions) Bikerdude (mission 1 and 2) Boylag (mission 1) Goldchocobo (mission 2, 3 and 5) Malasdair (all missions) Mary-Anne Stanke (mission 4) Narrator (mission 1 and 4) Purgator (mission 1 and 3) scodysk (mission 4) the double dutch king (mission 3 and 5) Xander Grant (mission 4) Yandros (mission 2 and 4) ================================================================ Pilfered items: - roulette wheel and alien model with thanks to Goldwell (taken from "AC II: New in Town") - pagan woman character and a select building facade with thanks to Fidcal (taken from "Heart of Lone Salvation") - skybox in mission 4 taken from Sotha's "TP: The Transaction" - mission 3 ("Down we go.") previously known as "The Cloister" - taken from the abandoned "Crucible of Omens" campaign, mainly created by the Dudes (JDude and BikerDude) and some other legacy missions makers ================================================================ New assets: - radio model and skin by Epifire, prefab produced by Bikerdude - several technical drawings provided by wellingtoncrab - keypad designed & coded by MirceaKitsune - flying bats designed & coded by STRUNK ================================================================ New sound fx / music: - factory and machine noises by inspectorj - machine sounds by lupalenzuela - rocks_falling_in_cave by unidentified contributor from freesound.org - vinyl_record_pop by joedeshon - ambient_battle_noise by pfranzen - distorted-wolf-howl by hail_pinson - roaring_sea by allthingssound - slideshow_projector by andreaskg - whistling-in-cave by retroguy23 - scary-ghost-wolf-howling by brainclaim - "Rivercare" by Adrian Wilaert - "Leave Her Johnny" by Roger McGuinn used under https://creativecommons.org/licenses/by-nc-nd/3.0/us/ All other new ambient tracks & sound fx created by Jack Farmer, occ. with gigagooga sound samples ================================================================ Special thanks go to: @joebarnin, who completely altruistically analyzed many game bugs, provided several clever scripts and even played through the initially very buggy game twice. It was an ordeal not even described in the first Builders book! Jeff, thank you very much! @datiswous, who, despite the enormous scope of the game, did not let himself be deterred from creating suitable subtitles for all dialog, comments, briefings and recordings. A truly monumental task! @Mat99 & @Bergante, who tried out things I would never have thought of and showed me once again that I absolutely have to take part in the next brain function enhancement surgery! ...and finally our friend, the incredible @AluminumHaste, who dared to do another detailed run-through at the end of the beta testing, which allowed for several more improvements and polishings. ================================================================ Thank you everyone at Fractured Glass for consultation and help in general! ================================================================

Right, so some somewhat more comfortable variables for me have turned out to be: pm_walkbob 0.185 pm_crouchbob 0.14 pm_runbob 0.43 Can't guarantee they will feel right to anyone else. They don't entirely feel right to me either but we're getting into the ballpark. While we're at it, let's discuss some more controversial territory. Player speed, which has gameplay implications. It wouldn't be very nice to force anyone to make their guards run faster, for instance, but to me, the player speeds feel neither particularly stealthy nor particularly hurried when you want to be in a hurry. I have pm_walkspeed at 75. Feels like you mean business when you walk to things, like its important that you get to that thing today. pm_runmod is 2.25, which is much less sluggish than the current player character, but also careful enough that he conceivably could be making sure to step carefully down staircases. It doesn't really feel like the player is truly hurrying until up at around 2.5 or so, though. pm_creepmod is 0.65, which has our character in somewhat more of a hurry while sneaking, while still being audibly careful. pm_crouchmod is also at 0.65, making crouched walking somewhat more athletic than the default, while crouch-creeping is still painstakingly stealthy although the character sounds like they are skilled enough to still do it faster than a beginner. In my subjective opinion, it sounds more natural with these values, from the perspective of a player just using their imagination. Which is the perspective that mostly matters in a game. Not to knock anyone with professional experience who's here to tell me there's no way this could be stealthy. The other thing is, I don't think any of these updated values seem casual or blend in like someone who's "supposed to be walking around here". But unless you're on a guard's route, you'll sound out of place at any speed anyway. Its certainly better to minimize contact rather than try to blend in. And with limited windows to move, I think players might prefer a more hurried pace from the player character like this. The lower bob values for walking and crouching, and higher values for running help to make it sound more natural, speed mods or not. Better not to let the tail wag the dog on this one.

I tried to post on TTLG Forums first, but despite registering i am still unable to make new posts so i asked elsewhere. Meanwhile I figured the problem by simply scaling down cutscenes resolution. My native screen resolution is 1280x800 and cutscenes in that format work well. Sorry for any double posting or using wrong forums for posting my question. Thank you for all the replies and help so far.

testMason FM Released (Aug 24 Version) testMason.pk4 This FM shows the complete character set of the Mason font on a floor in-game. It is mainly to support our on-going /russian/ work (but can be used with /english/ as well). The screenshots show the Cyrillic font, when the user selects the Russian font setting. One shot shows the TDM 2.13 situation. Note in particular the clobbered ASCII characters around "D". The other shot shows some 2 dozen "phase1b" DAT corrections I've done, to improve existing characters. There's plenty more work to be done by me & kalinovka from 0x80 on, to replace missing or non-compliant glyphs with new stuff. The FM displays the characters set twice, as a "Stray Marks" test seen fully in the screenshots, and an adjacent "Spacing" test. The two tests show the same character subsets in each aligned row. The row headers are in hex for "Stray Marks", in decimal for "Spacing". See the FM briefing for more details.

Greetings everyone! I recently got into TDM and am already having a lot of fun playing through and ghosting missions. However, coming from Thief, I am mostly relying on the rules and my experience with that game, while there are clearly differences in how TDM works. Right now, there is talk in the ghosting discussion thread on TTLG to amend the ruleset and include clarifications pertaining to TDM. So I wanted to drop by and ask: is there an active TDM ghosting community already and have any rules for this playstyle been developed? I would also like to ask someone to take a look at the draft of this addendum to see whether everything looks correct: https://www.ttlg.com/forums/showthread.php?t=148487&page=16&p=2473352&viewfull=1#post2473352 Thanks!

Main post updated with the new version and changelog. I intended to avoid modifying sound files to increase their loudness, but idTech4 doesn't seem to care about ReplayGain tags...

BoilerDunce Setting B: pm_walkspeed 75 pm_runmod 2.45 pm_creepmod 0.5 pm_crouchmod 0.45 pm_walkbob 0.22 pm_runbob 0.4 pm_crouchbob 0.11 walkspeed: same as type A runmod: True sprint, much faster than even Taffingtaffer's. Get yourself hurt kind of running, but not the fastest possible sprint, since without any kind of player momentum, it would feel mechanical and floaty to go any faster in my opinion. Might also be a good future core TDM feature- player inertia / temporary speed loss while making sharp turns. We're not a shinobi after all. creepmod: Sneakier than Type A crouchmod: Sneakier and much less athletic than Type A walkbob: Shorter steps, not as sneaky, just a brisk travelling pace. runbob: Longer steps, so as to be less Shinobi-like and accommodate less athletic mission protagonists. Also probably sounds like more like the length of stride the playermodel has. crouchbob: Slower. The only problem is, with the run modifier being so strong, you can crouchwalk comically fast compared to how few steps you take. Which sucks, because running while low is supposed to feel very cool. I have a feeling there's no squaring that circle. A system that forces compromises, very dastardly of TDM. I like this setting too much to not voice it though. Alternative: Type C Same as type B, but: pm_crouchbob 0.17 pm_crouchmod 0.7 pm_creepmod 0.4 This makes crouch-sprinting into more of a jog that looks way too low but is at least within the realm of possibility and only slightly goofy compared to totally goofy. I get the feeling the player character jogging low like this is probably a bit worn down by the years. This also makes normal crouchwalking about as fast as a very unathletic person can crouchwalk with moderate stealth- its a bit faster than Type B and is more suitable for travel like Type A, but splits the difference, I think. It's not FULL stealth normal crouchwalking like Type B. Creep-crouchwalking is now also slightly less gut-wrenchingly stealthy than Type B. But still full-stealth like the creep modifier's use should imply. It also clocks out at about the fastest a very unathletic player character would be able to move at full stealth. Maybe Type C will win the contest for feeling with Type A and B. I will await the answers from the Taffer and Snatcher, since they are in the best position to test them back to back. I'm not the one who can hotswap these. Including them all is not my intended suggestion. I leave that to your discretion. Type B's crouchsprint really is atrocious. Be on the lookout for a similar problem in your own settings.

This deserves attention, so I'd like to contribute to its footprint by mentioning something else I've thought about the footstep system. Personally, it seems like the character takes too many steps relative to how fast they're moving. I don't know how tall the player character is, but it just feels like their stride sounds shorter than it should. I wish I knew a way the way to mess with the relative rate of footstep sounds to playerspeed. I'm sure you or snatcher could find out though.

And I thought you fixed your problem: https://www.thiefguild.com/topics/95063/thief-the-black-parade-cutscenes-problem By the way, I can only recommend to patch your clean Thief Gold installation with TFix Lite instead of TFix. That way, you will avoid any potential issue with the mods you may or may not have enabled in the full TFix. Best for a fan mission install to use TFix Lite. And, another by the way: You will have much better luck to find help with your problem on forums which are dedicated to Thief Gold. This forum is for the Dark Mod. Try https://www.ttlg.com/ , for example.

Further thoughts on what i've read so far: The game is balanced for wood to be pretty sneakable but if all wood was squeaky as in Toni's mod sneaking on wood would be worse than tile. Making squeaky boards an intentional separate element to be included by choice seems both very prescient and realistic to me on the part of TDM. Thiefier Sounds seems like its good in the ways that matter to you, but to me, I have a different ideal for the sound design, I'm just no good at making mods. My ideal, not that you're interested, is that sounds would be of a quieter quality- it should sound like the player is wearing appropriately soft shoes for the job and stepping gingerly instead of (what sounds to me) almost marching as in both vanilla and the mods I know of. I think a sudden tap only makes sense if the player is moving at a brisk pace like in my speed values or running. It's not enough to just play footstep sounds at a different speed- different speeds (Run, walk, creep) reflect different intentions, different ways the player character would want to be stepping. If only their sounds were more distinct. Another thing: At least in the version the demos of these footstep mods take place in, footsteps appear to be playing on a single channel, muting the previous step sound file when a new one begins. This kind of ruins the built in reverb of the sounds we have so far heard and is not a natural sound. Even if a sound contained a subtle squeak or something shortly after a step, it could be silenced by other step sounds if the two steps happen close enough together.

Variable Scaling, based on Specific Translated Language and/or Text Content With fixed textscale values discussed previously, a translated multipage readable that ideally would have the appearance of smooth text flow across pages will often have per-page underflow (ugly) or overflow (data loss), requiring lots of per-language #str editing (that is, word moving) to correct. An alternative approach is to vary the textscale on each page, to nicely-approximate smooth text flow (at of course the expense of consistent font size among the pages). There are 3 approaches: Fully automatic. It is true that at some point, the engine has all the information it needs about how each English string is laid out, e.g., where – after text wrapping - the last rendered row is within the readable's margin, and the last character within that row. It could similarly do trial layouts for the current non-English language, iteratively adjusting the textscale until the layout matches. I don't really know, but this strikes me as hard. I'll concentrate on alternatives. Semi automatic. The engine is still involved, but just does a simple ratio calculation based on the string (English versus current language) alone, ignoring layout. The very simplest form would just look at character counts. It would not iterate, but provide a "good first guess", and rely on manual verification and, if needed, tweaking by per-language scaling adjustment and/or #str editing. Manual. The engine does not itself calculate variability, but you can do your own per-language scaling adjustments, which the engine will pass on to the GUI. Such adjustments may be faster for you than #str editing alone. (Arguably, with the fixed-scaling system, you can override a given .gui with a custom version, and tweak it's scaling at you wish. The proposed manual-variable implementation will avoid custom .gui overrides.) I'll consider how the semi-automatic and manual systems could be implemented. Aside: Scaling with "@aspect"? Besides dynamic horizontal and vertical scaling by changing "textscale", the GUI system offers an alternative. You can append a horizontal scaling factor, to the "font" gui parameter, e.g.: font "fonts/stone@aspect=16:9" If you were to specify "@aspect=4:3", that would be a scaling of 1.0, i.e., no scaling. In the engine code (DeviceContext.cpp), the scaling is calculated (for @aspect=X:Y) as params.scale.x = float(4 * Y) / (3 * X); X and Y are decimal numbers, so don't have to be integers. Can the "font" GUI parameter string value (particularly, aspect value) be changed dynamically? No example of that was found. Since "font" is a non-register, probably not. As a workaround, you could have a set of overlapping winDefs with different @aspects, that you would select among, hiding all but one. Sounds like a nightmare. (Also, the Carleton font has a Carleton Condensed relative, which pre-dates the @aspect system and can be considered deprecated by @aspect.) Recap: Scaling with "textscale" As we have seen, this factor, which takes a decimal number, scales the font proportionately in both vertical and horizontal directions. Importantly, it can be changed dynamically. This can be observed with the Objectives GUI, based on a global user value setting. In tdm_objectives_core.gui: // overall multiplier which scales: // * box sizes // * text height and font #define OBJ_SIZE_MULT "gui::objectiveTextSize" I will pursue a similar approach to passing a scaling factor from the engine to the .gui as a "gui::" float. A Division of Responsibilities between GUI and Engine Code The readables .gui does not know what the current language is, and even if you passed it in as string from the existing global CVAR, its values (e.g., "english") could not be used in .gui logic because the .gui code cannot really do string comparisons. Nor can it count the number of characters in a string. While there may be workarounds (e.g., represent language choice as an integer enumeration; maybe associate an object script with the readable to perform calculations), a more straightforward approach is to have the GUI and engine collaborate. Recall in our readableTranslationFadeIn example FM with the Camberic scroll, we used these fixed values for translated text in Stone font that would be of equivalent layout length (when no translation expansion is present): textscale 0.33 // for titleTranslated textscale 0.24 // for bodyTranslated Let's give them #def names In the .gui: #define EQUIVALENT_SIZE_STONE_FONT_TITLE 0.33 #define EQUIVALENT_SIZE_STONE_FONT_BODY 0.24 Further, let's create two new values passed from the engine, and give them #def names too: #define TITLE_TEXT_RATIO "gui::readableTitleTextRatio" #define BODY_TEXT_RATIO "gui::readableBodyTextRatio" Let's interpret the ratio as (speaking loosely) "English text length"/"Translated text length". So that an expanded translation text causes a value less than 1.0, and a corresponding scale-down of the Stone font. Then the translated part of the gui would have: textscale EQUIVALENT_SIZE_STONE_FONT_TITLE * TITLE_TEXT_RATIO textscale EQUIVALENT_SIZE_STONE_FONT_BODY * BODY_TEXT_RATIO What the "Text Ratios" Mean with a "Manual" Approach Simply put, the definition of every applicable non-English #str_ value could take an optional tab-separated third parameter, the text ratio. If not stated, 1.0 is the default. Thus, in all.lang, you might have... [English] "#str_fm_scroll_camberic_pg1_title_dear_reverend_bernard" "Dear Reverend Bernard -" ... [French] "#str_fm_scroll_camberic_pg1_title_dear_reverend_bernard" "Cher Révérend Bernard," 0.95 ... So, the creation process of files like french.lang would have to propagate this new third parameter. (Hand-editing can take care of this in the short term.) Then the engine, when parsing files like french.lang and applying them to the readable's .xd entry, would have to pick up the specified ratio values and then deliver them, consistent with the current TDM language. What the "Text Ratios" Mean with a "Semi-Automatic" Approach This would be similar to the "manual" approach, except the ratio delivered to the .gui is a composite of the manual value specified in the *.lang file, and a calculation performed by the engine. The simplest calculation would be: gui::readable...TextRatio = (Count of English characters / count of Translated characters) * manual .lang file ratio As before, 1.0 is the default value for the optional third #str parameter. The difference here is that, because of the engine making a "good first guess", there will be far less need for the user to specify that third parameter. Possible Improvements. Since the penalty for underflow (ugliness) is much less than overflow (words not seen), perhaps there should be an engine-applied fudge factor that would bias away from overflow: gui::readable...TextRatio = FUDGE_FACTOR * (Count of English characters / count of Translated characters) * manual .lang file ratio where FUDGE_FACTOR could be, oh, 0.98 for body and 0.90 for title. Beyond that, one could imagine more sophisticated variants of this calculation. For instance, it might use font character-pixel-widths instead of character counts. Or employ heuristics with average-word-length or space-char-frequency to guess at word-wraps and number of lines. At the extreme, this heads toward the "fully automatic" approach.

Thomas Porter is back in a TDM FM called... LQD is a medium sized FM, made for the TDM unusual contest 2013, where Thomas Porter sets out to get rid of the Lich Queen once and for all! Will he succeed, or will the evil Lich Queen get her sinister revenge on Thomas? The mission was created by me, Sotha. Betatesters: Bikerdude, nbohr1more and Obsttorte are thanked for their efforts on improving this work. Big thanks to TylerVocal for excellent voice acting. Thanks to freesound audio artists: Amliebsh (39222), Steveygos93 (80401), Jackie4ever (83095) and Klankbeeld (133100). Immense thanks for the developer team and everyone contributing to the mod. Release notes: *This mission has player character narration. There is no way to control the volume of the player lines in TDM 1.08 and they are at 100% volume at all times. For optimal experience, be sure to set SFX and ambient close to 100% volume in the in-game audio settings and fine tune the volume to nice levels from you operating system's mixer. That way the world sounds match the player voice in volume and your gameplay experience is not reduced by very loud player narrative. *This mission involves using objects with other objects. Normally objects are used like this: push R to drop the item into your hands, move the item where you want to place or use it. *This mission has a video briefing, so you have the habit of skipping the TDM logo which is visible before the briefing, do not skip it or you will miss the briefing. Download link: Use the ingame downloader to get it. As always, it is not recommended to read the thread further before you have completed the mission. Someone will fail to use spoiler tags. [spoiler] This will be hidden [/spoiler] Enjoy! Please remember to give comments and vote! -Sotha.

This guy.

Yet More #str_ Added – Shouldered Names The I18N.pl script does not automatically localize characters’ “name”, “shouldered_name” and “shouldered_name_dead”. And that’s generally the right call. You don’t necessarily want to translate character names. For instance, I prefer my character “Emily” be left that way, i.e., not rendered as for instance “Émilie” in French. (And I’m unclear whether the “name” spawnarg should ever get the #str treatment. So really just looking at “shouldered_name” and “shouldered_name_dead”.) But I do have 3 characters that have not just name, but also title/rank, and it might be worthwhile to translate the title/rank, along the lines: "#str_fm_map_shouldered_name_capt_riggs" "Capt Riggs" "#str_fm_map_shouldered_name_first_mate_logah" "First Mate Logah" "#str_fm_map_shouldered_name_second_mate_chaf" "Second Mate Chaf" By story design, only Logah is actually shoulderable, but for completeness I’ll do all three. I’m using the same #str_ for both “shouldered_name” and “shouldered_name_dead”. BTW, an argument could be made that the character #str_ renames should include the class, e.g., ..._atdm_ai_townsfolk_wench_..., ..._atdm_env_ragdoll_guard_thug_, etc. However, a class name, while explaining the visual appearance, can be somewhat remote from the precise role that the AI plays in the FM. Prompt to ChatGPT With Air Pocket specifics in italics. You are an expert translator between English and other European languages, including Russian. You wish to translate a list of crew members on a small historic sailing ship, from English to these other languages. Each line of the list begins with a tab, then a word beginning with #str_ within double quotes, then another tab, then a phrase within double quotes. When you translate a line, in the output keep the tabs and the #str_ word unchanged, and only change the phrase to the other target language in UTF-8, keeping it in double quotes. Make the translated phrase reasonably short while preserving the formal meaning. Avoid modern slang. Old-fashioned wording is fine. At the end of each line, add another tab, the fixed text "//bt: ", and then a back-translation of the previously translated phrase into English again. When back-translating, ignore the original English phrase. The crew members names are Riggs, Logah, and Chaf, all males. Keep the name-portion unchanged, but translate the title-portion. Some centuries ago, they were on a small coastal sailing ship, trading in goods along the coast. In that time frame, take account of different countries having different merchant marine titles aka ranks. "Capt" here is an informal title for "Captain". These titles may be less formal than those of military officers aboard navy ships. Following the input list of crew members, append output lists in these target languages: 1. German 2. French 3. Polish 4. Italian 5. Spanish 6. Portuguese 7. Russian 8. Czech 9. Hungarian 10. Dutch 11. Slovak 12. Danish 13. Swedish 14. Romanian 15. Turkish 16. Catalan. List of crew members: "#str_fm_map_shouldered_name_capt_riggs" "Capt Riggs" "#str_fm_map_shouldered_name_first_mate_logah" "First Mate Logah" "#str_fm_map_shouldered_name_second_mate_chaf" "Second Mate Chaf" Results This time, ChatGPT did not place results in separate frames by language; because of fewer input strings? Also, between the title and name in every case was some odd “hollow box” character (possibly null character 0x00); I did a replace-all of those with <space>. What follows is the start of ChatGPT’s response (with my hollow-box correction). Here are the translations for each language. I’ve preserved tabs and identifiers exactly, translated the title portion into the historical/formal equivalent, and added brief back-translations (“//bt: …”) into English. 1. German "#str_fm_map_shouldered_name_capt_riggs" "Kpt Riggs" //bt: Capt Riggs "#str_fm_map_shouldered_name_first_mate_logah" "Erster Maat Logah" //bt: First Mate Logah "#str_fm_map_shouldered_name_second_mate_chaf" "Zweiter Maat Chaf" //bt: Second Mate Chaf 2. French "#str_fm_map_shouldered_name_capt_riggs" "Capt Riggs" //bt: Capt Riggs "#str_fm_map_shouldered_name_first_mate_logah" "Second Capitaine Logah" //bt: First Mate Logah "#str_fm_map_shouldered_name_second_mate_chaf" "Tiers Capitaine Chaf" //bt: Second Mate Chaf 3. Polish "#str_fm_map_shouldered_name_capt_riggs" "Kapn Riggs" //bt: Capt Riggs "#str_fm_map_shouldered_name_first_mate_logah" "Pierwszy oficer Logah" //bt: First Mate Logah "#str_fm_map_shouldered_name_second_mate_chaf" "Drugi oficer Chaf" //bt: Second Mate Chaf 4. Italian "#str_fm_map_shouldered_name_capt_riggs" "Capitano Riggs" //bt: Capt Riggs "#str_fm_map_shouldered_name_first_mate_logah" "Primo ufficiale Logah" //bt: First Mate Logah "#str_fm_map_shouldered_name_second_mate_chaf" "Secondo ufficiale Chaf" //bt: Second Mate Chaf ... etc. Other Observations As you can see above, ChatGPT neglected to provide a leading <tab> to each line, so I had to. I had forgotten to think about asking for “title case” in the prompt. Maybe just as well, since the 2 meanings of “title” (rank and capitalization) might have confused the AI. In the results, the person’s name was always left capitalized, and the first word. In a few languages, the second word was also capitalized; in most, it was not. I wasn’t sure if that’s how ranks are usually treated in various countries. I decided (unlike the inventory case) not to adjust the AI-provided casing. Finally, ChatGPT back-translated “Capt” always to “Capt”, never to “Captain”, even if the foreign language gave the full word, e.g., Capitaine. Probably evidence of its cheating here. I’m getting less confident in back-translation as a way to insure quality... at least when done by the same AI that does forward translation, and at the same time. Or maybe it’s just a ChatGPT shortcoming, and other AIs would do better.