Search the Community

I'd like to better understand what you want. The design of dragging bodies is to hold frob (key down) to drag and release frob (key up) to let go. That way it's impossible to walk away while unintentionally dragging a body. Plus, it's quick to grab and move several body limbs in rapid succession. This is thought to provide a better experience, especially for new players. Towards the beginning of this thread, I created a "tdm_frobhold_drag_body_behavior" cvar. https://forums.thedarkmod.com/index.php?/topic/22198-feature-proposal-frob-to-use-world-item/&do=findComment&comment=487580 "tdm_frobhold_drag_body_behavior", default:"1" Which drag body behavior? 1 --- on frob key up, drop body (limb). 0 --- on second frob, drop body (limb), TDM v2.11 (and prior) behavior. That cvar was removed shortly afterwards, because it was said that it wasn't needed. With that cvar set to 0, a second frob would be required to let go of the body. Is that the behavior that you want? If so, I can add that cvar back. Also, I saw elsewhere that you want the ability to revert back to the old way. If you mean that all of the controls match TDM 2.11, that can be done with "tdm_frobhold_delay 0" and there will be a menu setting to disable it as well.

I noticed that there was a pre-existing "carleton_condensed" font, and was wondering how it compares with the other versions I've floated as subtitle font options. So here's an eyeball comparison, all with the same gui scale factor of 0.25. In this shot, from top to bottom are: "carleton_condensed" "carleton" "carleton@aspect=16:9" So "carleton_condensed" is intermediary between the two. If "carleton" is considered width=1 (designed for 4:3 screens), and carleton@aspect=16:9 is width=0.75, then "carleton_condensed" is maybe width=0.875 So, since it's pre-existing, it could be another reasonable subtitle font choice... maybe called in Settings "Carleton, Medium Wide"?

It would be nice if, from the main menu (presumably under Settings/Audio, where "Subtitles" currently lives), one could have an additional option, "Subtitle Font", with choices: Carleton Carleton, Wide Stone Stone, Wide where "Carleton, Wide" and "Stone, Wide" are the uncompressed fonts, and "Carleton" and "Stone" are the width-compressed fonts. All with the 0.25 scale factor, so in effect 12 pt. (This avoids the concern raised earlier than allowing an arbitrary scale factor to be user-set would result in raggedy-ass text characters.) Further, change the default from "Carleton, Wide" to "Carleton". This choice would be appropriately passed to gui's through a global string. EDIT: This relates to bugtracker 6283

Not to be a nag, but I was thinking about the columns problem. If you go to the view source tab in the wiki article: https://wiki.thedarkmod.com/index.php?title=Fan_Missions_for_The_Dark_Mod&action=edit The raw table data is accessible directly: |- !align=left|{{TDM-FM|written|Written in Stone}} |Bikerdude, Amadeus, Dragofer |{{Forumlink|https://forums.thedarkmod.com/index.php?/topic/21265-written-in-stone-beta-210-only-20220128/}} |2022-01-28 |338 |Yes |Yes |CCC 22, Elixir |City Missions |Undead, Horror Themes |- Each pipe character represents one of the columns.

My idea is that the game engine chooses box size automatically. It means that someone (e.g. me) will have to see where to take width calculate from in the C++ code, and add corresponding logic to subtitle integration code. It's not like we run some script once and then live with hardcoded settings in .subs files forever.

Here it is: calcStringWidth.exe - Oct. 11, 2023 Release. Calculates the display width of a input string, for 4 candidate subtitle fonts Carleton and Stone, uncompressed and compressed.

Utility program "calcStringWidth" calculates the display width of a single-line input string, in TDM logical pixels, when shown (e.g., as a subtitle) with TDM fonts Carleton and Stone with a 0.25 scale factor, and either uncompressed (as designed for a 4:3 screen) or width-compressed by 0.75 (for a 16:9 screen) calcStringWidth.exe - Windows executable calcStringWidth.cpp - C++ Source code Invoked in the console with: calcStringWidth -s <quoted input string> -o <output file> [default is stdout]

I don't like variable-sized subtitles in general, especially if people can set width at will. If we know speech subtitles are not going to be large, then we can make them always less wide. Although I'm not certain we can know it in advance. Maybe we'd better implement some automatic size adjustment for subtitles in the future? If the subtitle fits one line, then show it on one line. After that, check 3 tiers of width and show the minimum one that is OK. Of course, top-middle point of the subtitle box is always at the same location, even if the box is smaller.

Additional thoughts: - Allowing width overrides would mean the width of a subtitle field could not be used as a reliable clue for story vs speech verbosity. - Another alternative system would be for the engine to look at the subtitle (which might have an embedded \n), and calculate what the width the backing field should be, to be tight but not cause additional wordwrap. That value would be passed to the gui to implement. There would be minimum and maximum width values. The engine would calculate string pixel length based on the specified font. (I've built utility programs with C# code for that, with carleton and stone fonts). This would results in variable-width subtitle fields... too raggedy? It could be further extended to calculate field height as well, if desired

Suppose we had a system like this: "verbosity story" are small width=0 by default "verbosity speech" are small width=1 by default The default of either can be overridden on a per-subtitle basis by using new option "-smallWidth" or "-sw", e.g.: with verbosity story inline "something.ogg" "I've hid the gem in m'lady's knickers." -sw 1 srt "something.ogg" "something.srt" -sw 1 // sw affects all messages of this srt the same with verbosity speech (as an alternative to breaking into individual messages and using srt) inline "yetmore.ogg" "I need to cast that spell tonight after midnight,\nbut once again, my supply of eye-of-newt is sadly depleted." -sw 0 #define FIELD_MARGIN is not anywhere official yet, just in my prototype tdm_subtitles_common.gui, hidden in yesterday's post. The values I show are from my analysis and testing, earlier reported in this thread and/or AI Barks.

Terrific! The beta test thread is up: https://forums.thedarkmod.com/index.php?/topic/22238-beta-testing-the-spider-and-the-finch/

Hazard Pay has subtitles for in-game conversations. The briefing is a video with text, although its not using the subtitle system.

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.

Welcome to the Dark Mod forums MarsManon! Thank you very much for the kind words about SLL, it's always nice to hear We all worked real hard on bringing Grayman's map to life and I'm glad you enjoyed it

I was so enchanted by this FM, I had to sign up to the forums the same day I finished it to come thank the authors Genuinely, truly incredible work! I was so overwhelmed in places that I resorted to just shouting joy at my monitor two, three, maybe four entirely separate times while playing. Exploring, puzzling, finding something new, trying to use it, and finding it does a whole new, separate, wonderful thing! There aren't enough words inside me to describe the feeling. It was breathtaking. I don't have any specific feedback that hasn't come through this thread before Thanks so much for making this, for all the inspiration and ingenuity and effort it took. If I never play another level this good, in any other game, in my life, I'd be fine with that.

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.

There's a group of players who have meticulously tested and adjusted ghosting rules for The Dark Mod. Please see: Official Ghosting Rules: https://www.ttlg.com/forums/showthread.php?t=148523 Ghost Rules Discussion: https://www.ttlg.com/forums/showthread.php?t=148487 Why alienate an established group of dedicated players?

OK I think I've got to the bottom of this. I've created this forum thread (with bug report): https://forums.thedarkmod.com/index.php?/topic/22221-bug-drowning-ai-in-shallow-water/ I can apply a workaround, although it won't be perfect and the bug itself needs fixing in the engine. There are a few other things that need fixing so will put an update together soonish.

If any mappers have encountered weirdness with kill objectives not working with drowning AI, I think I've found out why. I don't think it would be a particularly difficult one to fix either. I've raised this bug report: https://bugs.thedarkmod.com/view.php?id=6323 Some context here: https://forums.thedarkmod.com/index.php?/topic/21837-fan-mission-the-lieutenant-2-high-expectations-by-frost_salamander-20230424/&do=findComment&comment=487316 I think this is a bug, but just raising here in case some people think otherwise.

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

@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.

@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.

Hello TDM-ers. I am encountering an issue where textures seem to partially disappear. I tried searching the forums, but, I don't know what to search for. The missing textures are a worldspawn brush acting as a roof with {for now} flat iron texture. There are other worldspawn brushes right below to create an attic ceiling with roof framework board texture. These gaps appeared a few edits ago. I can't "undo" to get back before whatever edit did this. The gaps are only visible during play and are not visible during editing. Closing and reopening DR and TDM do not fix anything. Some of the brushes overlap in areas behind the play area but I have never seen an issue doing that. The attached image has the effect I am now seeing. Ideas on where to start debugging this? Very much appreciated. Clint

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)