Search the Community

Hi there I've been playing the dark mod for a while and have been taking notes on a few things that I feel if changed, would make for a slightly better and more enjoyable experience. 1 - Moving sideways when climbing ladders, pipes, nets, vines, etc, is ridiculously slow. Garret does it way faster in Thief 1 and 2... hell, even I can move sideways faster while climbing ladders and I'm no thief! Speeding it up a bit would make for more satisfying maneuvering, and also more fitting given that Corbin is an agile and experienced thief. 2 - There is no falling to your death sound. I was playing The Painter's Wife a while ago, and I fell to my death multiple times, and it always felt so weightless and anticlimactic doing so. In Thief 1 and 2 you could hear your bones being crushed whenever that happened. Having a sound cue like that would make me very very happy, or at least less frustrated from dying, which I do, a lot, because I suck. 3 - On the topic of dying, it would also be nice to add an option to enable a loose camera with physics instead of the Doom 3's standard tilted perspective and pointing 80º or so degrees upwards whenever you die. It looks so jarring to me that I feel even a standard camera animation pointing downwards like in Thief 1 and 2 would look better and more fitting than that abrupt cut. 4 - This is a small nitpick, but the water footsteps sound a bit off. Everything else in the sound department is generally very good, but the water footsteps sound as if someone dipped their fingers on a bathtub and is moving them around. It lacks impact. Thief 1 and 2 sounded better IMHO. 5 (bug) - And lastly, there is a bug that I want to report. For some reason you can't see your compass underwater. You can scroll through and view every item in your inventory (you can even read underwater!), except the compass that for some reason completely disappears. I noticed this when trying to navigate through a maze of underwater tunnels in a FM a while ago. That's all folks.

============== -= 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:

Hrm I wasn't able to type on *after* the spoiler and accidentally already submitted the reply.. (Does this forum somewhere have a raw mode where you type text with tags around them or something instead of this broken WYSIWYG editor?) Anyway, what I was gonna add: This was a great mission and I already played Away1 - I'm really looking forward to Away2, want to see how the story goes on

This post differentiates between "gratis" ("at no monetary cost") and "libre" ("with little or no restriction") per https://en.wikipedia.org/wiki/Gratis_versus_libre * A libre version of TDM could: ** Qualify TDM for an article on the LibreGameWiki *** TDM is currently listed as rejected https://libregamewiki.org/Libregamewiki:Rejected_games_list because "Media is non-commercial (under CC-BY-NC-SA 3.0). The engine is free though (modified Doom 3) (2013-10-19)" ** Qualify for software repositories like Debian *** TDM is currently listed as unsuitable https://wiki.debian.org/Games/Unsuitable#The_Dark_Mod because 1) "The gamedata is very large (2.3 GB)", and 2) "The license of the gamedata (otherwise it must go into non-free with the engine into contrib)" and links to https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk/LICENSE.txt Questions: 1) tdm_installer.linux64 is 4.2 MB (unzipped), which is far from the 2.3 GB which is said to be too large. Yes, the user can use it to download data that is non-libre, but so can any web browser too. If the installer itself is completely libre, does anyone know the reason why it cannot be accepted into the Debian repository? 2) If adding the installer to the repository is not a viable solution, would it be possible to package the engine with a small and beginner friendly mission built only from libre media/gamedata into a "TDM-libre" release, and add user friendly functionality to download the 2.3 GB media/gamedata using "TDM-libre" (similar to mission downloading)? 3) Would such a "TDM-libre" release be acceptable for the Debian repository? 4) Would such a "TDM-libre" release be acceptable for LibreGameWiki? 5) Would the work be worth it? * Pros: Exposure in channels covering libre software (e.g. the LibreGameWiki). Distribution in channels allowing only libre software (e.g. the Debian repository). * Cons: The work required for the modifictions and release of "TDM-libre". Possible maintenance of "TDM-libre". I'm thinking that the wider reach may attract more volunteers to work on TDM, which may eventually make up for this work and hopefully be net positive. 6) Are there any TDM missions that are libre already today? If not, would anyone be willing to work on one to fulfill this? I'll contribute in any way I can. 7) I found the following related topics on the forum: * https://forums.thedarkmod.com/index.php?/topic/16226-graphical-installers-for-tdm/ (installing only the updater) * https://forums.thedarkmod.com/index.php?/topic/16640-problems-i-had-with-tdm-installation-on-linux-w-solutions/ (problems with installation on Linux) * https://forums.thedarkmod.com/index.php?/topic/17743-building-tdm-on-debian-8-steamos-tdm-203/ (Building TDM on Debian 8 / SteamOS) * https://forums.thedarkmod.com/index.php?/topic/18592-debian-packaging/ (Dark Radiant) ... but if there are other related previous discussions, I'd appreciate any links to them. Any thoughts or comments?

In order to thank the team (and other mappers) for their relentless efforts in contributing, I hereby give the community.... Ulysses: Genesis A FM By Sotha Story: Read & listen it in game. Link: https://drive.google.com/file/d/0BwR0ORZU5sraTlJ6ZHlYZ1pJRVE/edit?usp=sharing http://www4.zippysha...95436/file.html Other: Spoilers: When discussing, please use spoiler tags, like this: [spoiler] Hidden text. [/spoiler] Mirrors: Could someone put this on TDM ingame downloader? Thanks!

Ulysses 2: Protecting the Flock By Sotha The mission starts some time after the events of Ulysses: Genesis, and continues the story of Ulysses. It is a medium sized mission with a focus on stealthy assassinations and hostage liberation. BUILD TIME: 12/2014 - 05/2015 CREDITS The TDM Community is thanked for steady supply of excellent mapping advice. Thanks goes also to everyone contributing to TDM! Voice Actors: Goldwell (as Goubert and Ulysses), Goldwell's Girlfriend (as Alis) Betatesters: Airship Ballet, Ryan101. Special Thanks to: Springheel and Melan (for proofreading). Story: Read & listen it in game. Link: https://drive.google.com/file/d/0BwR0ORZU5sraRGduUWlVRmtsX3c/view?usp=sharing Other: Spoilers: When discussing, please use spoiler tags, like this: [spoiler] Hidden text. [/spoiler] Mirrors: Could someone put this on TDM ingame downloader? Thanks!

That's correct but many people just use the in-game mission downloader to check for new stuff without even looking at the forums, which is what I did. In the past a lot of missions that required a newer version of the game executable and assets would tell you this when you tried to start them up. I was just reporting on this and that you don't need to reinstall, just update via tdm_updater if you find this issue.

Just to complicate your life, there are 3 additional aspects to consider about the circa-2014 Mason files, and subsequent circa-2017 improvements to the 'english' version perhaps applicable to your work. (These issues are covered in the wiki "Mason Font" article, with a bit more in my "Analysis of 2.12 TDM Fonts", https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/. The 2017 changes can be seen in the *current* 2.13 TDM English Mason files.) 1) Need for custom DAT-scaling on certain Mason characters The source TTF had upper-case and lower-case characters that were early-on considered too similar to size. So (before 2014) in the DAT, selective per-character scaling was used to differentiate them. See https://wiki.thedarkmod.com/index.php?title=Font_Metrics_%26_DAT_File_Format#Per-Character_Font_Scaling for details. As you add new characters, you should do likewise (relatively easy with refont). 2) Creating the "glow" of mason_glow How Tels created the glow (for 'english' carleton & mason) is discussed in reasonable detail here: https://forums.thedarkmod.com/index.php?/topic/12863-translating-the-tdm-gui/page/5/#findComment-262661 That could be done for Russian too, which I recall currently fakes a glow, and possibly would require a minor GUI or engine code change to use. Note: To best accommodate glow and retain GIMP-visualization-alignment between base and glow characters, Tels moved some base characters within their bitmap, to keep their glyphs 2-3 pixels away from any bitmap edge. You should consider this when placing new base glyphs. Note: For the 3 mason bitmaps doubled in size circa-2017 as discussed next, the mason_glow bitmaps were also doubled. 3) Extensive bitmap editing to solve main menu character jaggedness. On Oct. 5, 2017, @Springheel in https://forums.thedarkmod.com/index.php?/topic/19129-menu-update/#findComment-412921 said: "Looking at the Mason fonts, it looks like they were super low res to begin with, and were then just resized [presumably referring to per-character scaling], making them even worse. I'll see what I can do." [Further on, referring to fonts in the TDM menu system:] "It appears that resizing the dds file to make it higher res is possible, so I'll proceed." Later, on Oct 13, 2017, he concluded within a "More detailed list of changes: "Updated the menu fonts, which were surprisingly bad before" Unfortunately, I couldn't find details on how this work was actually done. I assume the bitmap editing was all done in GIMP. It started with doubling the size of certain bitmaps from 256x256 to 512x512. This was done for the first 3 bitmaps (i.e., those with ASCII, some Latin-1). Then characters were made more crisp and smooth-edged. How? Dunno. Also, some odd but harmless artifacts happened within GIMP (noted in https://forums.thedarkmod.com/index.php?/topic/22427-analysis-of-212-tdm-fonts/page/3/#findComment-499660)

I personally still feel it's now a lost cause without first getting clarification over the licence for the def and script files from the original Doom 3, which is why, until such clarification is officially made I'm not doing anything further towards it. I believe that while currently Microsoft may turn a blind eye to copy and pasted text from these files in TDM due to its' non-commercial nature, the moment it were to become Libre then the ability to use it commercially could lead to problems. However to answer your question (bearing in mind I have a very limited knowledge of Doom 3/TDM modding other than what I learnt attempting to get a compiled cut-down version running). In terms of the game scripts the following are the only non-GPL header game scripts and you can comment them out from being loaded in source code: tdm_grandfather_clock.script tdm_turret.script tdm_audiograph.script tdm_camgoyle.script tdm_safe_lock.script tdm_safe.script Also Grayman put the values as comments in code for these two files so they can be easily created: tdm_soundprop.def tdm_ai_base.def It would be easier to seek out Greebo and Springheel and ask them to GPL their work since that would open up all the base def files without the task of re-creating them. I suspect that it would take a very long time to recreate all the def files, also bear in mind that some functionality is copy/paste from Doom 3 eula protected files (func_static for example). As regards the work done by Grayman, that would always remain NC-BY, however access to the SVN commits would allow you to diff remove his non-GPL edits from the .def files. The UI function calls for TDM are all within the GPL source code, and as the UI is all a text based language it probably wouldn't take more than a couple of days to re-create a basic (though not pretty) UI. There are many comments within the source code relating to the UI string references, so a relatively complete UI string language file can be re-created as well.

Really? Quake 4 used megatexturing?! If that is true, afaik they never talked about it in the game promocional material. I always thought Quake Wars was the first idTech game to ever use them. Despite the feature existing hidden in the engine, since Doom 3. And yes in Doom 3, a single 8k terrain megatexture is a couple of gigabytes (thou today games are reaching 200+ GB already...). Also I wonder why JC didn't supported tga RLE compression feature for the MT, when the engine can already use it for basic textures, it wouldn't be as good as the later compression system they used but would still take out a few megas from the size. Perhaps the tga decompression, just took to long for the MT streaming feature?

Practically speaking, to get on to Steam you also need to formalize the team as a legal entity, which brings up stuff like tax filings, a board of directors and executives, reporting requirements, etc., that I think nobody was keen to take on or hand over to others to take on. To begin with, it'd change the whole character of the team & the project a lot, I think. I forgot the issues with GOG and Itch now. I think everybody admitted it sounds good in principle at least. It's just herding cats when you get into the details, and half the cats are missing. That's before you even get to the actual mess with all the licenses. --- I noticed in the credits of Blendo Game's Skin Deep, when I played it recently, that there's a credit for the TDM Engine, from which he evidently lifted some things for his game. Brendon has long been making his games with Doom engines, so there's a reason he did that. I'd say he's also a friend of the community. He's visited the forum & is known for his games & thinking on immersive sims. But the point is that there's an example of someone branching off the TDM engine for a commercial project (that's also on Steam BTW). So if you have questions about it, that's someone you can contact to ask about it. I'm sure it matters that probably none of the assets carried over, though, only the game engine, or parts of it.

Oh never knew Doom 3 editor lacked prefab ability, one reason DR got so popular then, prefabs are awesome. I never used inhouse Doom3 editor, besides trying it for a few minutes but DR felt better to me, so I used that. Custom DR prefabs, do work in Doom 3, obviously TDM ones will not. I did used prefabs in Doom 3 for some things, like wall lamps and such, where I connected a model, a light and a particle effect for example. Never looked at the DR source code, but behind the scenes I bet the entities are just being bound to each other and that Doom 3 supports fine. About the topic, I would love to help the person but like i said, I never used inhouse Doom3 editor, so I can't really compare behaviors between the editors. And what you said sounds totally reasonable.

When talking about a possible libre version of TDM (https://forums.thedarkmod.com/index.php?/topic/22346-libre-version-of-tdm/) it seems we believe all media/gamedata included in TDM is licensed CC-BY-NC-SA. I am not familiar with how the process of adding new media/gamedata works today; I have seen files uploaded to the bugtracker which developers then commit to SVN, but I don't know if there are other ways. It may be a good idea to implement a process that when new components (media/gamedata included in TDM) are added, the contributor is asked to be explicit about the license (a choice which may defaults to their previous preference, for usability). It won't fix the past, but it may help in the future. This will make it easy for contributors to add future data under a more permissive license if they choose. Libre media can be added and its license can be tracked, rather than assumed to be CC-BY-NC-SA. I suggest looking at how Wikimedia Commons has implemented this: the contributor state the source and license at the time the data is uploaded. This can be done either by providing urls or by saying "It's my work and I choose this licsense". The first step could be to add a way to keep track of each filepath in SVN, author, license, sources. Start by setting the value for each file's license to "(default/legacy CC-BY-NC-SA)". Possible implementations for a user interface for new additions are: * Use our own wiki, which runs Mediawiki (same as Wikimedia Commons). I see several benefits of this, but we also need a way to accept uploads of batches, not just single files. * Look at how other open source projects have solved this. There may be more appropriate solutions available. ... but I'll leave the implementation open. Suggestions are very welcome! If the author of each file already in SVN can be tracked, then it may be possible that the author is willing to give a blanket permission for all their past files in one statement, and all their files in SVN can be updated in one commit. A productive contributor willing to release some of their work under a more permissive license could make a big change. If Dark Radiant would support letting mappers search media/gamedata by license (does it already?), it would make it easier for mappers to create a completely libre mission, which would help facilitate a TDM-libre release. If I understand things correctly. This post does not address all details and it may contain misunderstandings or assumptions, but it's a start. Also relevant: * Is there a compiled and maintained list of recommended or deprecated resources for mappers to use? * https://forums.thedarkmod.com/index.php?/topic/20311-external-art-assets-licensing/

Might this not be better suited to https://forums.thedarkmod.com/index.php?/forum/58-tdm-tech-support/ or failing that make the text collapsable.

Regarding the existing Russian version of TDM's MasonAlternative font, this had a different origin than those Russian fonts processed by Riff_Keeper. Tels created this in 2012. He started from bitmaps of an ASCII Mason font, then used his Perl patch program to copy selected ASCII glyphs (that resemble in some way Cyrillic) to new font "MasonAlternative". See https://forums.thedarkmod.com/index.php?/topic/12863-translating-the-tdm-gui/page/15/#findComment-274617 In GIMP, he flipped or otherwise hand-edited to make them Cyrillic. He said, "There are still a few dozen missing, but this is enough to render the two headlines we have (New Mission and Setting)" https://forums.thedarkmod.com/index.php?/topic/12863-translating-the-tdm-gui/page/15/#findComment-274623 This accounts for the incomplete coverage. Speculatively, he took this approach because it couldn't find a Mason-style TTF font with both Russian characters and an acceptable license (e.g., public domain, or at the least freely redistributable for non-commercial use). @kalinovka,I wonder what the licensing is for your masonchronicles3.ttf.

Evidently a significant portion of the Cyrillic work was done by Keeper_Riff (in conjunction with Tels) back in 2011. These folks are not active in TDM these days. Keeper_Riff outlined a workflow, starting with FontLab to edit TTF files... https://forums.thedarkmod.com/index.php?/topic/12863-translating-the-tdm-gui/page/12/#findComment-271548 Specifically Carleton: https://forums.thedarkmod.com/index.php?/topic/12863-translating-the-tdm-gui/page/4/#findComment-262135

A Winter's Tale By: Bikerdude "One of the few pleasures I have as a man of the thieving profession is to return to my old home town for the holidays and relax in the company of friends and relatives. But a local lord has been going out of his way to making the lives of the locals a miserable." Notes: - TDM 2.12 or later is REQUIRED to play this mission. - This is my entry for the speedbuilding jam. - This FM should play on the vast majority of systems. I have perf tweaked this map with low end players in-mind. And have moved the globale fog/moon lights to the ‘ better’ LOD level. - min recommended spec (as per beta testing) Intel Core i7(3rd gen), nvidia 1030 4gb (GDDR5), will get you 60fps inside and 45fps outside. - Various areas will look better with shadow maps enabled (SoftShadows set to medium/high, Shadows Softness set to zero and LOD set to 'better'), at the possible expense of performance depending on your system specs. - this mission continues the imperial theme, with this being a border town slightly further out from the main imperial lands than Brouften. - build time roughly 130hrs. Download Link: - (v1.4) - https://discord.com/channels/679083115519410186/1310012992867405855/1310022631415746632 v1.4 changes: I have been tweaking the LOD levels through-out the map - - Snow fall has been moved to LOD low/normal. - world fog moved to LOD better. - fireplace grills to LOD better. - world moonlight moved to LOD high. Other tweaks - - reduced light counts in all the fireplaces. - reduced the length of the looping menu video background. - Some new assets Gameplay: - added more ways for the player to get around. - tweaked existing routes to make some easier or more of a challenge. - and added an additional option objective. Credits: Special thanks go to - - Nbhor1more, flashing out the briefing and creation of readables. - Amadeus, Help w/custom objectives, script work, proof reading, mission design & testing. - Dragofer, for custom scripts and script work for the main objective. - Baal, for additional tweaking of the main objective and script work,. - Beta testers: Amadeus, Nbhor1more, Mat99, DavyJones, S1lverwolf, Baal & Dragofer. - Freesound.org, for ambient tracks, further details in sndshd file. Speed Jam Thread: - https://www.ttlg.com/forums/showthread.php?t=152747

Double topic. See also topic: https://forums.thedarkmod.com/index.php?/topic/22754-thief-vr-legacy-of-shadow-announcement/

i am having a hard time searching for specific keyword in bug tracker so i decided to wade into google search and found similar thread with similar issue : https://forums.thedarkmod.com/index.php?/topic/13723-key-drop-melee-animation-glitch/

Websites prove their identity via certificates, which are valid for a set time period. The certificate for forums.thedarkmod.com expired on 10/18/2024. Error code: SEC_ERROR_EXPIRED_CERTIFICATE

Or, just get in contact with the owners of the IP and ask them since just because an IP lawyer in one jurisdiction says it would be okay, doesn't mean it would be okay globally. There are several packs out there of scripts/definition files which are licenced under free licences (CC0 and WTFPL mostly) and claim their freedom by recreating them using "clean-room way". In fact, I used them in getting TDM running with mostly free licenced files by selectively choosing which had clearly been written from scratch albeit with reference to the originals, and which were just direct copy and paste with claimed free licences (I didn't use them). Then it was a case of finding/replacing the core engine textures, sounds, etc. the engine required to launch with free alternatives (again checking the packs since some were just copied direct from the game files and claiming to be free). In the end, the only non-free licenced files that were still required were those from TDM itself. The result of this TDM version is the screenshot I posted some posts ago here: https://forums.thedarkmod.com/index.php?/topic/22346-libre-version-of-tdm/page/3/#findComment-500642 However, you will notice the giant cursor on the screen in the screenshot, why? because the only reference to hiding the cursor is within the UI files which come under the game eula, so I didn't add in the command to hide it in game. In the case of the script/def files, this "clean-room" approach has stood up in a court of law when I looked online, however you wouldn't really want to end up being in the position of ending up in court defending yourself in the first place. The flaw in the def/scripts that were recreated are that they all wrote their files using the originals as reference. So if the originals are under the game eula, and if the information contained is in some way protected, then all these "clean-room" files revert to the original game eula, as the authors didn't have the right to change the licence. I believe (with a pinch of salt )that if the core scripts/files were made GPL by idSoftware/Microsoft then as files based off of or using them as parents (basically all TDM scripts/defs as far as I can make out) then all of the TDM scripts and def files would automatically become GPL as their authors could also not claim their work was NC-BY since it was then based on GPL work.

I know this is The Dark Mod but I thought it might be worth asking in case there might be those with the requisite knowledge here - I downloading 6th Venom's main manu mod for Doom 3 ROE and apparently, in ROE, the difficulty is locked to Recruit regardless of what you choose for some reason. It can't even be changed in-game using set g_skill. I noticed a user talking about this bug in the comments and just tested it, myself. Is there anyone here who could possibly take a look at this? I really love this mod but this is kind of a glaring issue; it would be so great if it could be fixed. And I can't afford much, but I'd be willing to buy a pizza for anyone who can fix this! Luke

Oh, I'm maybe confused - if I understand correctly, __declspec is MSVC specific, so I was unfamiliar -- I thought you were talking about syntax for function declarations in the DLL's Doom script header, rather than the actual DLL C++. On the DLL side, I had just expected they be exported with an `extern "C"` block, so any compiled language (or non-MSVC C++ compiler) can produce a valid DLL (since extern is ANSI standard), and it is up to the addon SDK or addon-writer manually to make the exposed functions TDM-compatible ("event-like" using ReturnFloat, etc.). E.g. my Rust SDK parses the "normal" Rust functions at compile-time with macros and twists them to be TDM-event-like, but simple C/C++ macros could do this for C++ addons too (or do it in TDM engine, but that adds code). To avoid discovery logic, DLL_GetProcAddress expects to find tdm_initialize(returnCallbacks_t cbs) in the DLL. This gets called by TDM (Library.cpp), passing a struct of any permitted TDM C++ callbacks, and everything is gtg. It means exactly one addon is possible per DLL, but that seems like a reasonable constraint. Going the other way, the DLL-specific function declarations are read by TDM from the Doom script header (a file starting #library and having only declarations), and loaded by name with DLL_GetProcAddress. That (mostly) works great with idClass, but instead of #library, we could call a const char* tdm_get_header() in the DLL to get autogenerated declarations. I am not 100% sure I understood this part, so apologies if I get this wrong - I think the benefit of DLLs is that they make chunky features optional and skip recompiling or changing the original TDM C++ core every time someone invents a compiled addon. Also, you wouldn't want (I think) a DLL to be able to override an existing internal event definition. So there isn't a very useful way that TDM C++ could take advantage of the DLL directly (well, maybe). However, as you say, Doom scripts are already a system for defining dynamic logic, with lots of checks and guardrails, so making DLL functions "Just An Event Call" that Doom scripts can use means (a) all the script-compile-time checking adds error-handling and stability, and (b) fewer TDM changes are required. Admittedly, yes, to make this useful means exposing a little more from TDM to scripts (mostly) as sys events - CreateNewDeclFromMemory for example: sys.createNewDeclFromMemory("subtitles", soundName, subLength, subBuffer); Right now, that's not useful as scripts can't have strings of >120chars, but if you can generate subBuffer with a DLL as a memory location, that changes everything. So even exposing just one sys event gives lots of flexibility - dynamic sound, subtitles, etc. etc. - and then there are existing sys events that the scripts can use to manipulate the new decl. No need to expose them to the DLL directly. Basically, it means the DLL only does what it needs to (probably something quite generic, like text-to-speech or generating materials or something), and the maximum possible logic is left to Doom scripts as it's stable, safe, dynamically-definable, highly-customizable, has plenty of sys events to call, has access to the entities, etc., etc. Yes, I think this is what I've got - I'd just added the #library directive to distinguish the "public header" Doom script that TDM treats as a definition for the DLL, vs distributed "Doom script headers" which script writers #include within their pk4 to tell the script compiler that script X believes a separate DLL will (already/eventually) be loaded with these function signatures, and to error/pass accordingly. Although I think no C++ headers are needed, as it would be read at runtime, and TDM can already parse the Doom script headers. I'm not familiar with import libs, but from a quick read, this generates a DLL "manifest" for MSVC, but I think it isn't strictly necessary, assuming there is a TDM-readable header, as TDM provides a cross-platform Sys_DLL_GetProcAddress wrapper that takes string names for loading functions? But if it is, then yes. Yep - bearing in mind that a DLL addon might be loaded after a pk4 Doom script pk4 that uses it, the need for the libraryfunction type is: firstly, to make sure the compiler remembers that this is func Y from addon X after it is declared, until it gets called in a script (this info is stored as a pair: an int representing the library, and an int representing the function) - and then remembers again from compiler to interpreter - i.e. emitting OP_LIBCALL with a libraryfunction argument. secondly, it is to reassure the compiler that in this specific case it is OK to have something that looks like a function but has no definition in that pk4 (as opposed to declaration, which must be present/#included), and, thirdly, to make sure that the DLL addon function call is looked up or registered in the right DLL addon, so any missing/incompatible definitions can be flagged when game_local finishes loading all the pk4s (i.e. when all the definitions are known and the matching call is definitely missing) Right now, each DLL gets a fresh "Library" instance that holds its callbacks, any debug information, and a DLL-specific event function table. It is an instance of idClass, so it inherits all the event logic, which is handy. Having an instance of Library per-DLL seems to me to be neater, as it is easier to debug/backtrace a buggy function to the exact DLL, and to keep its events grouped/ring-fenced from other DLLs. The interpreter needs to know which Library instance to pass an event call to, so the libraryNumber (an runtime index representing the DLL) has to be in the OP_LIBCALL opcode. As such, while (for example) a virtualfunction in Doom script is a single index in an event list, a libraryfunction is a pair of the library index and the index of the function in the Library's event list. --- But, suppose we try to remove libraryfunction as a type. The first issue (above) could be avoided by either: (A) adding DLL events directly to the main sys event list, but since event lists are static (C++ macro generated) then different "core" code would have to change; (B) passing the libraryNumber via a second parameter to OP_LIBCALL and (ab)using virtualfunction (or even int) for the function number, or, (C) making the Library a Doom script object, not namespace, so that the method call can be handled using a virtualfunction The second issue and third issue could be avoided by doing two compiler passes - a primary pass that loads all DLL addons from pk4s, so that the compiler treats any loaded DLL functions as happily-defined normal functions in every pk4 during a secondary pass for compiling Doom scripts, as it is guaranteed to have any valid DLL function definitions before it starts. Sorry, that got quite confusing to describe, but I wasn't sure how to improve on my explanation However, in conclusion, I'm not sure that those other approaches are less invasive than just having a new type, but open to thoughts and other options! Yep! That's nice, sounds practical - maybe even this could eventually evolve to semver, to allow some range flexibility?