Geep

In looking at the animation, it struck me as odd that some characters become clipped while others apparently do not. The characters being clipped are those with a horizontal stroke at the bottom (G,S,O; exception: A). Maybe that indicates the sharpening algorithm is overly aggressive for those cases. EDIT: Further thoughts about this...

With the help of @nbohr1more and @stgatilov, my 2024 font changes were released as a cumulative package Jan. 10 and added to SVN for incorporation into TDM 2.13. Here's a MS Word docx with tables that describes those changes: 2025_Jan_Font_Changes_for TDM_2_13.docx That docx is also being released as part of a Jan. 16 supplement font file package. For more about that, see this post or 2025_Jan_Cumulative_2024_Font_Source_&_Supplementals.zip

I believe DXT5 compression is what is traditionally recommended. This differs from DXT3 is how alpha is quantized. Full white is generally true. There seem to be some cases with Mason and Carleton family fonts where there is also black or gray involved. I'm thinking at the moment is it's on purpose with Carleton, accidental with Mason. For Carleton, to put a black border around a white character, without having to call on the engine to do so.

Added a wiki page about the complicated Carleton fonts, based on notes I've been accumulating. https://wiki.thedarkmod.com/index.php?title=Carleton_Fonts

That's my hope. I should also figure out how to review the main menu translations to make sure the 2 codepoint substitutions are properly accommodated.

The revised Carleton and Mason REF files, generated by updated refont v2.5, are now available. See the included Summary .docx file for details, which itemizes what is superseded from previous releases, and what is not.

For 2.13, this is mainly a march through the fonts, improving my tools and auto-correcting minor problems. Complexities of some fonts has made this harder than anticipated (of course). If a font already has European accented characters, I'm changing 2 codepoints to ideally introduce 2 new accented characters, or at least park the DAT codepoint entry to the most-correct unaccented character. For 2.13, I plan on wrapping the DAT revisions by end of January, with final work on the Mason and Carleton families. I need to upgrade datBounds to handle within-DAT scaling, but that could be completed in an early 2.14 timeframe. For 2.14 and beyond, there is no end to work that could be done to improve font bitmaps. But I plan to think more about possible overhauls of how translation works, which might be more worthwhile.

The handling of fonts with 512x512 bitmaps, instituted in Refont v 2.4, was found to be inadequate for Mason font. So Refont v 2.5 just released changes that, and the Refont wiki entry is updated. REF files posted earlier for Carleton with v2.4 are deprecated. Still to do: Post updated Carelton and Mason REF files Revise datBounds to use the new REF format

I've found that the complexities of Mason font have caused problems for refont and datBounds. To get a handle on this, I did a deep dive into the twists and turns of this font. Results are written up now in the wiki as "Mason Font".

Most path nodes, including path_corner, can have multiple target spawnargs, e.g., "target0", "target1". Or the trigger_once_entityname could I think specify an AI name. I'd probably arrange a script to fire rather than start_alarm, but that's just me.

I never tried an elevator with inner & outer doors. But I wonder if you could find a way to delay opening the outer door, and open the inner first, if that would impact your problem.

Maybe this is the problem? From the wiki... Pathfinding will not be created for areas unless AI can also reach them by non-elevator means. Therefore it is important to include aas flood entities in such areas to force pathfinding to be created. These are listed under AI > AAS_flood. There are different types for different AI but aas32_flood is the one to use for humanoid AI (I doubt any other types can use elevators.) Just to clarify: the aas32_flood entity is only needed on floors where there are no other AI and which are only reachable by elevators.

RE the previous post, a problem was discovered due to a few fonts in the Carleton family using a larger bitmap than usual. This was determined to not affect the .dat files, but does impact the .ref files. Corrected .ref files may be found here: https://drive.google.com/file/d/1pYY23uqeyTguBVgR_vJNjDupxu1RhEUc/view?usp=sharing To fix this, Refont 2.4, just released, was given a new option, allowing the corrected files to be generated. The problem and solution are more fully described in a new section of the Refont wiki page: "Special-Case Carleton and Carleton_bold Fonts with 512x512 Bitmaps". And the program download links there updated. EDIT: Be warned about any REF files, e.g., some of the Carleton, in the above post that contain a header line "# bitmapSize=512"... That inadequate format is obsolete as of Refont 2.5, released below. I will be posting updated REF files Real Soon Now.

For the project "Change TDM codemap to add 2 new characters" described in bugtracker 6543, there has been a third font-file update covering (in a limited fashion) the remaining four font families... Stone Treasure Map Mason Carleton See my Nov. 10th post under the 6543 entry for more.

Refont v 2.3 is released. This brings more font-set-analysis capabilities that I needed to the "-stats" function. For details & download, see https://wiki.thedarkmod.com/index.php?title=Refont

That precursor code snippet by the late great grayman might suggest that one of his FMs uses it. Or once did, but "lingers". Not conclusive though.

Looks like it waits for something (a wheel?) probably wall-mounted to rotate 360 degrees in the x plane before opening the associated door. Since it hard-codes that rotating object as func_static_1858, this script is intended for 1 particular FM. (Lots of FMs have a func_static_1858... of ones I have on my hard drive, I didn't see a likely "wheel" candidate.)

Probably someone who has actually successfully deployed it in an FM needs to help here. (My last FM had a video ending, but it did a fake debrief - while the game was still running - with a lot of scripting.)

I guess look at comments in tdm_gui01.pk4/guis/mainmenu_custom_defs.gui

I think what's of most interest here is Stone font, the default for subtitles, and its calculated width-compressed value. The TDM scaling factor for subtitles is no longer 0.25, instead 0.24. So any actual displayed string length is now shorter than what this utility calculates, by about (24.0/25.0). "About" because calculated results is rounded to int. Beyond that, when I updated Stone 24pt for 2.11, I tried really hard to not have to change the underlying xskip values of any character. But to be absolutely correct, it would be good to review the xskip spacing array embedded in this program, against the current DAT/REF file xskip values. Probably the scale factor should be an optional parameter for this utility. I'll put an update of this program on my list of things to look at in 2025. For now, just do the 24/25 recalc.

I wonder if renaming the inventory name so it contains no space would make a difference.

To https://wiki.thedarkmod.com/index.php?title=Teleporting_entities , under the topic "Making an AI Start a Path after Teleporting", at the end I've added a description of this new method, as: Technique 3: "Kicking a Single Path Target Down the Road" Plus a link to the wizard discussion above about Visual and Sound Effects During Teleport

Added to https://wiki.thedarkmod.com/index.php?title=Pathfinding as new section "Viewing AI Current Path Goals and Obstacles"

I don't recall that idea being implemented, whether based on distance or volume. I think - to an approximation - if you can hear the sound when it starts playing, however faintly, then you get the subtitle. Otherwise, there's a problem. Suppose you have a distant guard running towards you... you want to trigger the subtitle even when faint, rather than lose it entirely. Perhaps there's some way to make it work OK. Dunno. Otherwise, for now, if you aren't suppose to hear the sound, maybe in some cases you can set its shader's max distance to be smaller.

stgatilov I presume the speaker sources have overlapping max distance spheres, and all are triggered to start at the same moment. If the player is in an overlap location when triggering happens (and so can hear the same monologue start from multiple sources, although probably without realizing it), then multiple subtitles appear. If the player is in a non-overlap location when triggering happens, but moves into an overlap location while the monologue continues, I'm guessing the extra subtitle would not appear. (Could be wrong about this.) In any event, this is a common speaker setup (although most often with looping sounds). @stgatilov would know better, but I think a reasonable restriction would be to enforce a prohibition on multiple subtitle slots starting the same subtitle (i.e., sharing a subtitle path/name) "at the same time" (e.g., a frame or 2), irrespective of source. Probably that would be enough. Don't want to have to calculate whether sources are part of an overlap. Or look at whether sources are distinct and/or static (see next pp). In my subtitle test FMs, I have a single static sound source, but if desired can trigger multiple recurrences of the same monologue with multiple button presses. The button presses and so monologue instances are offset in time. I see that as a feature, not a bug. So the prohibition on duplicate subtitles "at the same time" would be appropriately constrained. If you had two nearby instances of the same guard model, and they emitted the same bark at *exactly* the same moment, you'd only see one subtitle. Probably rare and not a problem. We'd have to rethink that if there was choral singing.