Search the Community

For the FM? For beta 1 it's here: https://drive.proton.me/urls/H1QBB04GA0#oBZTb1CmVFQb I've already done around 100 fixes though, so you might want to wait for beta 2 which should be ready in a couple of days hopefully. All links are in the first post of the beta thread here: https://forums.thedarkmod.com/index.php?/topic/22439-the-lieutenant-3-foreign-affairs-beta-testing/

Just wanted to say thank you for this install script. Made life easier! I'm new to the dark mod (but not to thief) and have just set up my steam deck to try it whilst away for a few days. Looking forward to some portable sneaking!

Arrows are a core part of TDM. They should be moved to C++ and have dedicated Cvars for both players and mission authors. Plan: 1) Implement Arrows in C++ ( evaluate changing some old defaults ) 2) Make associated Cvars "non-archived" 3) Mappers add mission.cfg to enforce their customizations 4) Players can alter mission.cfg to their preference Along the way, reduce some of the performance impact of the weapon script constantly invoking "raise torso" and other nonsense due to using scripts rather than C++ https://bugs.thedarkmod.com/view.php?id=4203

Yep, moved on to greener pastures. BTW, what I quoted above from him will soon be untrue for Stone 24pt due to my upcoming bitmap surgery. Actually, the values in the current stone .dat file are already misaligned with what any archival font patcher script would produce, due to 2.12 tweaks with q3font & refont. I'll add a note to the wiki about this (explaining it better than here).

Hey @stgatilov, sorry for the late reply. In looking at the tdm_weapon_arrow.script in A House of Locked Secrets, there is a comment line that says "Adjusted to stop the raising and lowering animations during a realm transition." From what I remember, when the player was switching between the physical and spiritual realms, if the player was holding a bow the lowering animation would play upon starting the switch and the raising would play after it. And so we modified the script to disable those animations during a realm switch. That was the only adjustment that should be present. I think if you look for the line "if($info_player_realm.getKey("transiting") == "0")" it should be quick to spot where those checks were made. Thanks! -Gelo

Some good news! Tels dug around further in his old computers and found some gold. Namely, a whole fonts directory that includes GIMP .xcf files. Tels says: "The XCF files esp. are what I used to manually draw the new characters (like adding dots to an u to convert it to ü etc.) They contain many layers with different characters, that are layout exactly in the place where they need to be for the patcher script." That is, for english stone 24 pt, one .xcf file contains two independent RGBA bitmap layers, that can be saved separately as two .dds files. A quick glance of that content appears to match the current distributed stone_0_24.dds and stone_1_24.dds. So I won't need to back-convert from DDS to TGA after all. @Amadeus, I think a copy of this should be added to the TDM assets repository. Could you do that? * http://bloodgate.com/mirrors/tdm/pub/scripts/tdm_font_source.7z

Do we have any volunteer to participate in fixing these missions? The first (and perhapsthe most important) step is to download these missions, diff tdm_weapon_arrow.script against stock version, and list all the things that are actually customized.

Is it not possibly to just add a small script to these missions that only does this: #define ARROW_ZOOMDELAY 3 //VOLTA MOD Edit: I haven't installed the newest tdm version yet, so I guess this might be complete nonsense..

I can understand your frustrations, however the main reason why we have had to replace the core files is because we don’t have the ability to make tweaks to the core game without doing this. In particular having the bow speed reduced from 6 seconds to 3 feels a lot better ingame. And it’s something that I personally have in all of my missions since I saw it in Kingsal’s mission the first time. If it’s possible for us to tweak that variable without needing to replace the .script file that would be really handy.

Because the default script doesn’t feel as smooth as Kingsal’s tweaked one. I believe the main advantage is as Amadeus mentioned a 3 second bow draw time vs 6 seconds which feels a lot better. I’m not completely married to the idea of this but if you’re able to integrate the ability for us to customize this without replacing the core files that would be appreciated.

The script changes standard weapon behavior and you think it's not needed to inform the player?

this is how the mapper wants the player to experience the FM. If you want a different experience, the burden is then on the player. Although, there are already several existing notations in the script files and def files about what has been changed. Kingsal has been really good about this with his volta modifications, and I've tried to do this as well

Good question. Maybe because I don't feel myself too guilty breaking these missions? Maybe because I know that fixing them will be a long story. And I feel confident that we (or more likely I ) will be able to fix all of them by 2.13. You might have noticed that I have also enabled two behavior changes in the latest build (1 2). In these cases it is not even mappers' fault that behavior change is needed. I have a script which can update all missions at once so that they work properly both in 2.12 and dev builds. But somehow I feel I should wait for at least some feedback on the new behavior before doing a massive change to dozens of missions.

In By Any Other Name, I needed to deactivate the sword, bow, and blackjack for a while (during the middle part of the mission). I couldn't figure out how to "turn off" the bow, and then later turn it back on again. So I ended up cloning tdm_weapon_arrow.script, and modding it (adding a special variable that got checked when you tried to raise the bow). Pretty kludgy, and obviously can lead to breakage. (I also had to make similar changes to tdm_weapon_blackjack.script and tdm_weapon_shortsword.script.) Maybe all I need to do is remove all of the arrow ammo. That way the bow won't raise. That still leaves the blackjack and sword. I think there was a way of deactivating weapons, but I couldn't activate them back on again (?)

Why the sad face? Also, Kingsal would be better able to explain the changes, and he actually modified the script so that it is more TDM-friendly. This modified script is in Eye on the Prize and Moongate Ruckus

So this revised script is part of Kingsal's arrow mod, and the script tweaks a few values such as the ARROW_zoomdelay from "6" seconds to "3" and a few other things. I also thought this was the script that increases bow draw speed, but I guess that is done in the associated .def files instead. These tweaks were made so that gameplay would feel a bit more fluid when drawing and firing arrows.

As a matter of fact, I implemented passing info from briefing to game and from game to debriefing: https://bugs.thedarkmod.com/view.php?id=6509#c16671 At some moment I think I should put this info to wiki... This will be available in the future dev build. P.S. By the way, you can also override which .map file to start, although I'm very skeptical that this feature is worth the trouble you'll get in maintainability. Small variations of the same map should be better implemented by writing the "main" game script.

As you probably know, overriding core files which are not specifically designed for that is fragile and unsupported. Indeed, it usually works... until it does not Here is the list of missions which completely override tdm_weapon_arrow.script: ahouseoflockedsecrets @Moonbo byanyothername @joebarnin cauldron_v2_2 @kingsal good @Amadeus hazard @kingsal northdale1 @Goldwell northdale2 @Goldwell seeking @Amadeus@Dragofer@Wellingtoncrab snowed_inn @Goldwell @kingsal written @Amadeus @Dragofer I have just got rid of creating cvars dynamically (5600), and shooting the bow stopped working in these missions. Because they distribute an old version of the script which runs in "debug mode" that relies on dynamic cvars. Core version was updated some time ago and this debug mode was removed. I'd like to ask authors: why did you decide to override this script? Perhaps we can add some customization points and delete overrides?

Also, related to font improvement, I've just released "ExportFontToDoom3All256", a reconstruction of an earlier but now lost tool variant. This is described and available in the wiki article ExportFontToDoom3 I tested that tool using one of the TDM FM fonts, Andrew Script, for which a TTF file is available. I generated a fresh set of bitmaps (newly including any available Latin-1 characters). I also mucked about with FontForge, to reconfigure that TTF to be ordered like the TDM custom codepage. However, Andrew Script is missing a fair number of Latin-1 glyphs, so it would take some work to make it good (whether by editing in FontForge or post-export as bitmaps). I'm putting that aside for now, since the jury is out on whether Western language support in FMs and their fonts will become viable (see Western language support in 2024?). Instead, I plan to turn my font-improvement-for-2.13 attention to Stone 24pt, which (because its used in HUD captions) is more clearly worthwhile to work on. Looks like I'll have to convert the Stone DDS to TGA as a prerequisite to bitmap editing.

I think you need to do things at the exact moment in DR that the user changes a field, so you can capture both the old value and the new value. Would be way better if DR just handled everything natively, but could be done through a hook to an external script too, I suppose. Or some complicated logging.

Maybe have a lang file check script with suggested fixes. Or even a console command for checking translation file compatibility.

I mentioned this elsewhere, but just a historical note: the existing i18n.pl conversion script expects only a numeric value after #str_ in its pattern matching regex (and possibly method of hashing). I do think @datiswous's idea to have key/value pairs with values like: "#str_Nobody crosses me! Must get back Frothley's scepter Creep stole off me." is a good way forward. Maybe with this version, DR could actually choose over time to provide some .lang support. And probably the engine would have to create hash tables to avoid slow string matching with these long non-numeric strings. (Oh, one other thing, since we're talking about The Outpost. When I played it earlier the month under 2.12, my screen would periodically go black for a second or two, every minute or two. I wonder if anyone else sees this, or just my odd Intel graphics chip?)

That is my recollection too. The i18n system was basically Tels' personal pet project (hence the Perl script which is unmaintained because nobody in the world except Tels and Larry Wall have any interest in writing code in Perl). Because of the various implementation problems and general user-unfriendliness, Greebo didn't approve of merging it into the main mod, so it became a sort of optional extra that individual mappers could use by accessing various resources on Tels' personal server.

BTW, the Perl script I18N.pl expects only an integer value after "#str_". Could be modified (or deprecated).

That is one reason. That is 2 more reasons. You'd like a script that, if you had to run it again, would "do the right thing". Unfortunately, that right thing is very hard to program, and needs IMHO to be both bidirectional and with a better method of string version control, to support both the FM author's updates and potentially multiple translators. Yes, another reason. Currently, it is my understanding that updating an FM (from the non-converted copy) and running the conversion script again causes mis-alignment of newly-generated #str values and previous .lang #str values. Another important cause of "nobody is making these language packs" is that Dark Radiant at best tolerates converted FMs. It offers no special translation support, as expressed in this code comment: "...we don't have any support for parsing the mod-specific translation data...." [from DR's DifficultySettingsManager.cpp]. That's where we are now. So officially give up on FM Western translations? Or improve the #str system to make it work for everyone? Or invent a new system? A new system. What would that look like to the FM author? To a non-author translator