Search the Community

I finished this mission. Great mission. It's interesting to play this after having played Braeden Church first. I made the subtitle files. Unzip it in the folder of the fm. I also tested it in-game. If a couple of people will review it over time, it might be enough to include it at some point. It's actually only 3 sentences (2 inline, 1 srt). Edit: subtitles added to mission.

COPIED FROM "English Language Subtitles for AI Barks". MORE RELEVANT HERE... @datiswous, I imagine the TDM fonts don't support bold, italics, underline, etc. Maybe just different sizes. I don't think color by itself would be helpful for speaker identification, unless there was a color halo or name tag above each vocalizing AI. Might be useful for word emphasis, though. @stgatilov, if there is location data available to the subtitle code, that could be used in various ways, using a different GUI: 1) Let the 3 slots be either left justified, centered, or right justified, depending on relative speaker location (including off screen). This could be implemented by 9 actual windowDefs (all of same size; 3 each for each current slot, overlaid, with each of the 3 justifications.) Alternatively, with a 3x3 grid, all windowDefs the same size, but 1/3 the current width.) 2) Or instead, at the top edge of each slot, show a short horizontal bar, whose left/right position is moved to be under the relevant AI. If off screen, add an arrow head (<-- or -->). Naming is harder, if the subtitle code can't get at that info. Though at the point the sound engine is passed the sound to render, presumably it knows the speaker, and could independently and in parallel visualize the name information (particularly if the sound engine passed back which GUI slot it was going to use for subtitle.) It is true that associating a name (say, using a small tab-like field) with a slot is less useful when the player doesn't know the AI names (i.e., with no floating names above the characters). If the technical issues of naming could be overcome, then there's still the question of when you'd want to give a name (Rupert) versus type (thug #3) versus generic (speaker #2). Also have to handle special cases of (narrator) and (player). Dreaming... Instead of text names, more fun would be to show a thumbnail face of each AI next to their slot. With a question-mark face when they are off-screen?

@datiswous, I imagine the TDM fonts don't support bold, italics, underline, etc. Maybe just different sizes. I don't think color by itself would be helpful for speaker identification, unless there was a color halo or name tag above each vocalizing AI. Might be useful for word emphasis, though. @stgatilov, if there is location data available to the subtitle code, that could be used in various ways, using a different GUI: 1) Let the 3 slots be either left justified, centered, or right justified, depending on relative speaker location (including off screen). This could be implemented by 9 actual windowDefs (all of same size; 3 each for each current slot, overlaid, with each of the 3 justifications.) Alternatively, with a 3x3 grid, all windowDefs the same size, but 1/3 the current width.) 2) Or instead, at the top edge of each slot, show a short horizontal bar, whose left/right position is moved to be under the relevant AI. If off screen, add an arrow head (<-- or -->). Naming is harder, if the subtitle code can't get at that info. Though at the point the sound engine is passed the sound to render, presumably it knows the speaker, and could independently and in parallel visualize the name information (particularly if the sound engine passed back which GUI slot it was going to use for subtitle.) It is true that associating a name (say, using a small tab-like field) with a slot is less useful when the player doesn't know the AI names (i.e., with no floating names above the characters). If the technical issues of naming could be overcome, then there's still the question of when you'd want to give a name (Rupert) versus type (thug #3) versus generic (speaker #2). Also have to handle special cases of (narrator) and (player). Dreaming... Instead of text names, more fun would be to show a thumbnail face of each AI next to their slot. With a question-mark face when they are off-screen?

I agree that the current system would allow any of the TDM-supported languages (English or otherwise) in the subtitle strings. But this would still be a relatively fixed choice of subtitle language (e.g., German instead of English). As you say, a design is needed of how to support making the choice of translation language reflect the settings language. Otherwise, we might end up with "language subtitle packs" for each FM that have to be manually installed/manipulated. I'll revisit that wording tomorrow.

Mostly yes. For those subtitle sets I've released so far, the remaining steps for someone (not me) are - - optionally do a second QA pass. (I've tried to be careful and thorough, of course.) - fold them into the 2.12dev distribution. This mainly involves deciding where the subtitles for each voice should live when distributed and copying the .subs and .srt files there. It may also involve editing the .subs file to change paths accordingly. That edit is just a find/replace-all, so easy. There are additional gui presentation issues, which are (I hope) unlikely to affect the foregoing. About those issues: experimentation and discussion are on-going, and ideally may be resolved before the final 2.12 release. Also, regarding barks emitted by the player and by non-human AI... unclear to me how they should be categorized ("verbosity speech" vs "verbosity effects" vs ignore). In any event, I don't expect to get to them in a 2.12 timeframe. BTW, I'll be traveling this coming week as well as later in the month, so will be periodically unresponsive.

The devs didn't title this thread, and @datiswous said they're attempting to mislead people by using Russell's name and a retro style to make it resemble Thief, which is cynical. I grew up on forums like I'm sure anyone who likes a game from '98 did. I actually left the Discord immediately after joining it because it was more off-topic doom-posting than anything relevant to the mod. I thought the forums might be better, but it's mostly just grown men yelling at clouds and telling strangers how mature they are, and a few brave souls actually developing anything. Depressing place, I'll just stick to enjoying new missions every 6 months without an account.

True, but, 1. this thread is called "Western stealth FPS with Stephen Russell", and, 2. nothing you said changes anything for me. The gameplay still doesn't look like something I'd enjoy. And, if you really think this forum is cynical, then you don't visit forums much. Actually, the majority of the users are are pretty mature, unlike in other forums.

New script for mappers: my flavour of a fog density fading script. To add this to your FM, add the line "thread FogIntensityLoop();" to your map's void main() function (see the example in fogfade.script) and set "fog_fade" "1" on each foglight to enable script control of it. Set "fog_intensity_multiplier" on each info_location entity to change how thick the fog is in that location (practically speaking it's a multiplier for visibility distance). Lastly, "fog_fade_speed" on each foglight determines how quickly it will change its density. The speed scales with the current value of shaderParm3, using shaderParm3 = 1000 as a baseline. So i.e. if shaderParm is currently at 1/10th of 1000, then fade speed will be 1/10th as fast. Differences to Obsttorte's script: https://forums.thedarkmod.com/index.php?/topic/14394-apples-and-peaches-obsttortes-mapping-and-scripting-thread/&do=findComment&comment=310436 my script uses fog lights you created, rather than creating one for you. Obsttorte's script will delete the foglight if entering a fogfree zone and recreate it later more than one fog light can be controlled (however, no per-fog-light level of control) adding this to the map requires adding a line to your void main() script, rather than adding an info_locations_settings entity with a custom scriptobject spawnarg in my script, mappers set a multiplier of fog visibility distance (shaderParm3), while in Obsttorte's script a "fog_density" spawnarg is used as an alternative to shaderParm3 smaller and less compactly written script fogfade.scriptfogfade.map

@stgatilov, attached is a screen shot of what I'm calling the "sound source cue" or "sound source oval" directional indicator. Unlike the previous Photoshopped mockup, this is implemented as a prototype in gui script. It shows a cropped screenshot of the 3 stacked subtitle slots, with a red dot indicating the direction, respectively (from the bottom slot) left of player, straight in front of player, and straight behind player. Those locations are simply hard-coded by local float variables dot0_x, dot0_y, dot1_x, dot1_y, dot2_x, dot2_y. I need the engine to supply those as gui globals instead. (You can change the names as you wish). Once I have a 2.12dev update with those variables (and please, the verbosity enumeration too, that we talked about), then I'll do another pass to optimize the art and tweak the dot positioning and size. That's better done when dynamic dot movement is available. For the next go around, it might be sufficient if the engine just provided the direction as a unit vector, in which case the engine-side assert is: square_root(dot_x^^2 + dot_y^^2) = 1.0 Later, we could play around and see about encoding distance too. In which case the "=" in that assertion would be replaced by "<=". Do you think that "sound source cue" should be something the user can turn on or off as an option? If so, that's another gui global to pass, probably a cvar.

In the kdenlive subtitle editor, use the "End" counter to adjust the subtitle phrase end point. Then export to an .srt file, and look within that file. Does the phrase have the same specified endtime, or has it been changed? The latest Cadet release version, 2.0.044 of April 14, incorporates the beta. The main feature added was that, if you go into Tool/Preferences, there's a new line "Show cc reading rate with alarm threshold of [...] in units of [CPS or WPM]". There's also a bit more flexibility in how to advance from one phrase to the next. BTW, I found the Cadet project feature adds no value. I just (re)use an anonymous project, and export the .srt. If later I need to adjust something, I can use "Import" of the .srt to do so. If I strongly needed a tool that had speech-to-text capabilities, I would not use Cadet. Since I've got preexisting text for the vocal sets I'm currently processing, I'm not needing speech-to-text right now.

I dom't use it, i found it here with the filter set to OpenSource. the TOS and PP isn't excluding for an OpenSource app, if they use ads mean that they also need to pay an server for this online service. OpenSource is not synonymous with free either, perhaps after the beta phase it is no longer free, so perhaps you can take advantage of the fact that it is still free to create a series of textures that can be used or search another one in Futuretools. AI generated textures and assets, by definition, don't have any copyright, so you can use them as you want. https://www.futuretools.io/?pricing-model=free|open-source&tags-n5zn=gaming

@datiswous, as to where to place linebreaks, I found the "Line Division" section of this webpage to be useful guidance: https://dcmp.org/learn/597-captioning-key---text (For my Style Guide Part 2 - planned for year-end release - I have a very similar section, just with the subtitle examples changed to use typical TDM barks and centered justification.)

hm.. I wonder if that's what I did.. Would be kind of a stupid mistake. But I often make small mistakes while creating subtitle files, which then take a while to figure out.

The subtitle cvars are not for user configuration, they are internal. They would change only if if TDM developer decides that... if player changes that, it would be his problem. Just like very many cvars which are totally not for the user to change. I just committed it in svn rev 10358, so expect it to arrive... I guess I'll publish dev build this weekend. I decided that options always start with minus, while commands always start with letter. That's how parsing can work in well-defined way, regardless of linebreaks. The final syntax is: -durationExtend 0.5 -dx 0.4 Also, for now it only work on inline comments (warning and subtitle removal when applied to SRT).

As for implementation: Let's say the engine generated a sound source location (relative to the listener's axis, and only in the horizontal plane) as a unit vector in Cartesian coordinates. That is, the origin is at 0,0 and straight ahead is 0,1 straight behind is 0,-1 due left is -1,0 due right is 1,0 This would be passed to the gui as floats, e.g., soundDirN_x, soundDirN_y, where N is the subtitle slot number. The gui would take care of translating the origin and scaling the vector. For the oval, the scale factor would be different in the x and y directions. (This is an approximation of actual location on the perspective projection of a tilted circle, but should be good enough. And avoids any trig functions on the gui side)

Mandrasola is a small sized map in which aspiring thief Thomas Porter steals some herbal products from a smuggler. The mission was created by me, Sotha and I wish to thank Bikerdude, BrokenArts and Ocn for playtesting and voice acting. Thanks goes naturally to everyone contributing and making TDM possible. This mission occurs chronologically before the Knighton's Manor, making it the first mission in the Thomas Porter series. Events in chronological order are: Mandrasola, The Knighton's Manor, The Beleaguered Fence, The Glenham Tower and The Transaction. The winter came early and suddenly this year. Weeks of strong blizzards and extremely harsh cold weather hit Bridgeport hard. With the seas completely frozen, a rare occurence indeed, most of the City harbor commerce has stopped completely. Vessels are stuck in the ice and no ship can leave or enter the City, resulting in the availability imported goods declining and their prices skyrocketing. One of these imported items is Mandrasola, a rare herbal product, which is imported overseas from the far southern continents. Mandrasola has its uses in alchemical cures and poisons, but mostly this substance is used for its narcotic qualities by commoners and even the nobility. The problem with Mandrasola is that excessive use is extremely addicting and the withdrawal effects are most grievious. Many are utterly incapable of stopping using Mandrasola and are transformed into quivering human ruins if they do no get their daily dose. And now this expensive and rare substance is running out from the whole City. Me and my fence, Lark Butternose, would love to grab this monopoly to ourselves: selling the last few doses in the City would probably be worth a fortune. According to Lark's sources, there remains only one smuggling lord who still has Mandrasola in stock. The problem is that this individual maintains an exclusive clandestine operation and only supplies a few nobles. Despite our best information gathering efforts we couldn't learn who the smuggler is and where he or she operates. Luckily we have an alternate plan. While searching for Mandrasola related information, we learned that a noblewoman called Lady Ludmilla is addicted to the substance and has paid high prices for small amounts of it. We also know that she has visited frequently someone in the Tanner's Ward waterfront, and since she goes to the area personally we believe she is visiting the smuggler. The plan is simple: I must monitor Ludmilla's most likely entryway to the Waterfront and then follow her to the smugglers hideout. I'd better be very careful around Ludmilla. She must not realise I'm following her or she probably won't lead me to her dealer. Hurting her is also out of the question. After she leads me to the smuggler's hideout, I can take my time to break in carefully and steal all the Mandrasola I can find. While I'm there it wouldn't be a bad idea to grab some loose valuables as well. I've now waited in the blistering cold for a few hours already. Looks like there are a few city watch patrols in the area to complicate matters... I think I heard a womans voice beyond the north gate. That must be lady Ludmilla, I haven't seen many ladies in these parts. I'd better get ready.. Links: Use the ingame downloader to get it. WARNING! Someone always fails to use spoiler tags. I do not recommend reading any further until you've played the mission.

@stgatilov, I was originally thinking I could take your 5 values and, in the gui, do the inverse math to get back what you called in the engine code the "spatializedDirection" (normalized x,y vector from the listener to the source, relative to the listener's axis). But I realize that's impractical... math would need C++ Instead, let me show the end goal I was thinking about, through a mockup. The idea is to have a non-moving oval (representing a disc laid flat on the floor, in perspective), with a small colored square constrained to move smoothly along it, representing the direction of the sound source. In the mockup (attached cropped image), the oval is blue, the square is red, and the direction being indicated is front right. (Or maybe the ring should be dark red and the square light blue... or disk could be solid, etc.) The translucent field is 240 (out of 640) pixels wide, so the oval shown is roughly 30 pixels wide. The perspective could also be made more prominent, if instead of a uniform stroke width on the ring, the lower ("nearer") edge was thicker than the upper ("farther") edge. If implemented, the gui spacing between the 3 subtitle slots (not shown here) might have to be tweaked a bit to avoid overlaps.

FONT NOTE: Starting with this test FM, to improve readability, the Carleton subtitle is compressed in width to 75% of its size in previous test FMs. The backing field is similarly reduced in width. These are implemented in the FM's custom-override guis/tdm_subtitles_common.gui. If desired, you may copy that file to previous test FMs to propagate the change. The subtitles for The Lady (aka Noblewoman) vocal set are now available: testSubtitlesLady.pk4 The wiki's "Vocal script: Lady" suggests these traits: As usual, the testing FM serves as the vehicle to provide these subtitles for eventual incorporation into TDM. Statistics In file fm_root.subs there are 243 "inline" subtitles, including: 37 with an explicit linebreak, intending 2 lines 206 without 17 of the inlines have explicit duration extensions, as follows: 11 from 0.25 to 0.49, for 17 cps presentation rate 6 capped at 0.50 seconds, for 17-20 cps none with more than 0.50 seconds There are 2 SRTs, each with 2 messages that respectively indicate start and end of singing/humming. No duration extension was needed, and none of the 4 messages contained a linebreak. In all, in this vocal set captioning, there are 245 voice clips with subtitles, showing 247 messages. Corresponding Excel File LadySubtitles.xlsx This is based on Version 5 of the Excel Template for TDM bark subtitles, which was also featured in the preceding work for Average Jack, The Pro, The Maiden, The Grumbler, and The Mature Builder.

For the record, there is much about these examples I dislike: The subtitles here are way too lengthy and should be broken up into individual sentences. Subtitle sentences should be always terminated, e.g., with periods. No terminator means the sentence continues in the next subtitle. And I continue to make the case that these default panel fieldwidths are too large. As you know, I'd like half-screen, but could I suppose, live with up to 2/3rds. Having a less-wide default means that the player could then make it wider with a new future Setting that scales up (or down) fontsize too. So if enlarged, better support for low-vision users, and if shrunken, less obstrusive for eagle-eye'd English-as-second-language users.

@stgatilov, both the compressed Carleton and Stone fonts look better than the original uncompressed IMHO. We could give the user a choice of either, while keeping the gui scale factor fixed at 0.25 (e.g., 12 pt). If Stone's artifacting you mentioned was not too problematic. I did a statistical analysis of those two fonts, and Stone strings seemed to be slightly less wide than Carleton by about 7% (however, Stone 24pt requires scaling down to get to 12pt, and the analysis may not be treating the resulting "half-pixel" widths right.) But if true, background field widths based on Carleton should still be excellent for Stone. Another topic. I'd like to play around a bit with the 5 sound-source-location variables you were using to position the white bars. In file tdm_subtitles_message.gui, these were of form: "gui::subtitle0_oriBackLeft" // where 0 if subtitle was shown in vertical "slot 0"; could be 1 or 2 and name suffixes were _oriFront, _oriFrontLeft, _oriFrontRight, _oriBackLeft, and _oriBackRight Could you briefly explain what values these could take on, how they would work or differ, how often they get updated? Thanks

If the "mission fails as soon as stealth score turns non-zero," that would not be good for ghost players. They might need to find out "how" they failed and experiment to avoid alerting guards. They might need to take those score points as a "bust". They might need to take those score points to complete an objective. Then, mission authors would need to encode exceptions into their missions, which would be a lot of work (if they decide to do it at all). However, part of what makes ghosting challenging and fun is when mission authors do not create their missions with ghosting in mind. Please see: Official Ghosting Rules: https://www.ttlg.com/forums/showthread.php?t=148523 Writing code for these rules would be a huge undertaking. Ghost Rules Discussion: https://www.ttlg.com/forums/showthread.php?t=148487 Creating an official mode could alienate these dedicated ghost players, because it would clash with what is considered ghosting in the community. Including the Stealth Stat Tool mod in the official release would be more useful. Or, making the audible alert states of guards quick and easy to recognize could help as well. For these reasons, I don't agree with an official "Ghost" mode. If the dev team were to do it, we should consult with @Klatremus so we get it 100% correct or not pursue it at all. (This ghosting bit should probably be in its own thread.)

A "Style Guide" for how I have been doing the bark captioning has been percolating on my desktop for some time. In order to move it along, I have split it into 2 parts, and the first part is now available as a Word doc here: Subtitle Style Guide - Part 1 Part 2, the remainder, with more supplementary material, hopefully will be available around year's end.

@stgatilov, would it be correct to say that the latest public 2.12dev contains the original 4:3 fonts, and does not distribute the narrowed 16:9 fonts (e.g., for Carleton and possibly Stone)? Also, I'd greatly appreciate it if you could expose a numeric variable whose value is set to indicate whether the current subtitle is of type "verbosity story", "verbosity speech", or "verbosity effect", that can be read (but not set) in tdm_subtitles_common.gui

FYI, as I work on The Wench, I'm adopting the following style to using parentheses. This differs in my earlier treatment for The Thug and The Lord, where square brackets were more frequent, with a different meaning. (I plan to revisit those subtitles for this and other reasons, after The Wench). [Fragment from my eventual style guide:] TO BE DETERMINED: Some styles of including a speaker ID in a subtitle use parentheses or square brackets. This is not important for subtitling barks, but may be for “verbosity story” subtitles. Parentheses. These are used to refer to what the AI is saying/vocalizing. The most common purpose is: Descriptors for non-word vocalizations that are not otherwise represented, e.g., (coughing) (sneezes) Other purposes, used sparingly, are: Descriptors for vocal style or sound quality, e.g., (sing-song) (hoarsely) Indicating the speaker’s physical or emotional state, e.g. (surprised) (sleepily) (drowning) Providing stage directions or context, e.g., talking (to buddy) Indicating the speaker is actually talking in a foreign language, though shown in English. As the examples indicate, the text within parentheses should be all-lower-case and relatively short (for CPS/WPM considerations). If it refers to the entire phrase, put it at the beginning, and, if using a verb, favor the “...ing” form, e.g. (humming). If it refers to a particular location within the sound file, if using a verb, favor the active-form, e.g., (hums). For a long sound, consider indicating its conclusion: (humming done) or (/humming). Do NOT use parentheses (or square brackets) to enclose speech to indicate: whispering or sotto-voce. Instead, add a prefix word (whispers), (whispering), (confidentially), etc. asides by the speaker. Dashes can be helpful to set off such speech, or an embedded “(aside)”. Be modest in indicating the loudness of a bark; while the voice tone can be evident, the actual volume that a bark is emitted is not under the subtitler’s control. Square Brackets. These are: Mainly reserved for future “verbosity effects” sounds. Can be used for non-vocal sound included with a bark clip, whether associated with the AI or not, but important enough to warrant a subtitle mention. This will be rare. Example: [claps]. Curly Braces. TDM fonts do not support these.