Search the Community

I think the problem here stems from a different source. I don't know if it's correct, but, I read that the Oblivion remaster is basically a raytraced DX12 wrapper running the original source code in Unreal Engine, with remade assets, lighting, and the graphical possibilities UE5 offers. I actually asked myself, how they are able to port the gameplay 1:1 to UE5, and, I guess that's how they did it, if that's correct. I'm pretty sure you can code much more efficiently in terms of performance in Unreal Engine, as usual. But, I guess they did a pretty good job in terms of optimizing anyway, considering all that is going on "behind the curtain". Anyway, the demand modern graphics tech requires from your PC hardware is absolutely insane, when you consider the little value of shiny visuals. As I don't expect this insanity to end anytime soon, I can only be happy that 99,9% of games released these days don't interest me at all anyway.

On the topic of flash bombs I agree it would be an improvement if these could be used to interrupt alert states of guards and open them back up to KO. This gives them a real purpose in the game, and a way out of situations that might otherwise just result in a long wait for ai cool downs, or more likely just a reload. So far I know of a couple of authors who have attempted to address this via scripting, but haven't been able to get it to work. Might require some code to support the option.

I can take a look at this and also at the pop up window, if both are defined in the UI code.

Included in the beta for 2.12 is a new companion to security cameras familiar to Thief players: the automatic turret. It will become active as soon as an enemy is detected by a targeted security camera, firing projectiles to fend off the intruder. Similarly to the security camera and the camgoyle sentry, turrets are highly customisable in their behaviour and appearance. There are two main variants of turrets at the moment: the cannon and the flamethrower. Thanks to Goldwell for digging up custom sound effects and Bikerdude for creating the models. Both were originally written as scripts, and meanwhile the cannon has been converted to C++ and integrated into the core assets for 2.12-beta1. One of the aims of the 2.12 beta is to test the readiness of the turret for release, given that it's a brand new and complex entity. The question of whether it's released with 2.12 or pushed back 2.13 is decided based on feedback by testers, so plentiful testing is of the essence and can be posted here. At the time of the 2.12 beta, the flamethrower is available as a script-based downloadable addon [here]. Its mode of action is to fire a lance of fire at its target, a novelty in TDM. While the scripting engine is powerful, there are some significant potential benefits in a C++ version. The main one is access to array variables to store and process data about all emitted flames, which would allow the flamethrower to spray fire in an arc instead of firing a single stream at x position. For this reason the flamethrower isn't offered as a core asset yet. Another feature of 2.12 is the refurbishment of Doom-era code for guided projectiles, tricky for even the nimblest players to dodge. Switching to guided projectiles only requires changing a projectile's spawnclass from idProjectile to idGuidedProjectile, and more spawnargs can be found in the new entity base class for guided projectiles. A guided version of the cannon turret's projectile is available in 2.12-beta1. Work was also done on introducing Thief-style bouncing projectiles but, as a hybrid between projectiles and moveables, these aren't part of 2.12 because changes to existing code at a deeper level are needed.

Very nice additions. I particularly admire the throwing animations. The drinking ones are fun. I'd love to see the bottles come a bit closer/lower towards the mouth, and maybe a few drops splash upwards. The lock-picking is more problematic, and I'd probably like to see an option to enable/disable it. (This could be command-line, given that you're trying to get by with one GUI setting.) If the player only has 1 lock pick, does the animation still show both? If so, that's not good. But you could substitute a 3rd tool that is clearly different, e.g., a flat file or knife with a different color handle. The bigger problem is, as others have mentioned, even if the lock hole is clearly seen, the picks are off somewhere else. A thought. Suppose for a moment that your code knew where on the screen the hole was [a hard but usually plausible thing to determine, at least for standard assets]. Then maybe, rather than moving the player, your hands animation could be dynamically shifted left/right/up/down to hit it when it's in range. (More of the forearms/upper arms would have to be included in the animation, and the offscreen parts clipped, never screen-wrapped.) In any event, I'm looking forward to see how you animate the upcoming items you mentioned.

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.

im a bit ambivalent on the jupiter source code as it is pretty messy and relied on some old ass f... compilers. the unmodified source is buildable with msvc 6.0 and msvc .net 2003/2008 but newer compiler versions requires a massive rewrite of the build system and an even massiver rewrite of the source code to adhere to newer cxx standards. bibendovsky has made a ton of changes to make this happen and replaced some troublesome parts that wreak havoc on newer windows. he added a compatibility layer as a library that gets comiled in (spul) which also handles some of the cross libraries such as openal and ffmpeg. you can still build it with the old dsound / dinput but it might not work to well on say win10 and up. compared to the mess you needed with msvc 6.0 which needed stlport to even build, his version does build on even the latest msvc compilers. only downside is that the tools source code still needs porting. msvc .net 2003 still works even on win11 with some compatibilitiy settings applied (fullscreen optimization disabled admin and ignoring high dpi) and it's free to download. it supports upto XP and as low as win.311 directx support is a bit more shaky but you can actually use directx9 with it with some dummy headers or get this https://archive.org/details/dx90_vs2003_full.

Hello, my name is Wolfmond, I am 41 years old and I come from Northern Germany. I am your new member. In my youth I played Thief: The Dark Project with great enthusiasm. Recently I discovered and started playing The Dark Mod and I am very happy that there is still an active community around this beautiful game. I am especially interested in level design and creating my own campaigns. In my spare time I like to walk around, record sounds (field recording), make dark ambient and experimental music, and code. My dark ambient music is available for free at https://wolfmond.bandcamp.com I'm currently working through the Youtube Tutorial from @Springheel and I'm really enjoying learning level design. I look forward to getting in touch with you and contributing my skills to the community. Best regards, Wolfmond ___________________________________ Hallo Ich heiße Wolfmond, bin 41 Jahre alt und komme aus Norddeutschland. Ich bin euer Neuzugang. In meiner Jugend habe ich mit großer Begeisterung Thief: The Dark Project gespielt. Vor kurzem habe ich The Dark Mod entdeckt und begonnen zu spielen und bin beigestert, dass es immer noch eine aktive Community um dieses schöne Spiel gibt. Mich interessiert vor allem das Leveldesign und die Erstellung eigener Kampagnen. In meiner Freizeit gehe ich gerne durch die Gegend, nehme Geräusche auf (Field Recording), mache Dark Ambient und und Experimentelle Musik, und programmiere gerne. Meine Dark Ambient Musik gibt es kostenlos auf https://wolfmond.bandcamp.com Aktuell arbeite ich das Tutorial von @Springheel durch und habe große Freude daran, Leveldesign zu lernen. Ich freue mich darauf, mit euch in Kontakt zu sein und meine Fähigkeiten in die Community mit einfließen zu lassen. Viele Grüße, Wolfmond

Complaint From Players The player must pick up candles before extinguishing them, and then the player must remember to drop the candle. The player must drag a body before shouldering it (picking it up), and the player must remember to frob again to stop dragging the body. The player finds this annoying or easy to make mistakes. For players who ghost, some of them have the goal of returning objects back to their original positions. With the current "pick up, use item, and drop" system, the item might not return easily or at all to its original position. For example, a candlestick might bounce off its holder. (See player quotes at the bottom.) Bug Tracker https://bugs.thedarkmod.com/view.php?id=6316 Problems to Solve How can the "pick up" step be eliminated so that the player can directly use or interact with the item where it is in the game world? How can so much key pressing and mouse clicking be eliminated when the player wants to directly use an item? How can candles be extinguished and lanterns toggled off/on without first picking them up? How can bodies be shouldered without first dragging them? Solution Design Goals Make TDM easier for new players while also improving it for longtime players. Reduce tedious steps for common frob interactions. Make it intuitive so that menu settings are unnecessary. Do not introduce bugs or break the game. Terms frob -- the frob button action happens instantly. hold frob -- the frob button is held for 200ms before the action happens. (This can be changed via cvar: 200ms by default.) Proposed Solution Note: Some issues have been struckthrough to show changes since the patch has been updated. Change how frobbing works for bodies, candles, and lanterns. For bodies: Frob to shoulder (pick up) a body. Second frob to drop shouldered body, while allowing frob on doors, switches, etc. Hold frob (key down) to start drag, continue to hold frob (key down) to drag body, and then release frob (key up) to stop dragging body. Also, a body can be dragged immediately by holding frob and moving the mouse. For candles/lanterns: Frob to extinguish candles and toggle off/on lanterns. Hold frob to pick it up, and then frob again to drop. Frob to pick it up, and then frob again to drop. Hold frob to extinguish candles and toggle off/on lanterns. For food: Frob to pick it up, and then frob again to drop. Hold frob to eat food. For other items: No change. New cvar "tdm_frobhold_delay", default:"200" The frob hold delay (in ms) before drag or extinguish. Set to 0 for TDM v2.11 (and prior) behavior. Solution Benefits Bodies: New players will have less to learn to get started moving knocked out guards. With TDM v2.11 and earlier, some players have played several missions before realizing that they could shoulder a body instead of dragging it long distances. Frob to shoulder body matches Thief, so longtime Thief players will find it familiar. Second frob drops a shouldered body. Players still have the ability to both shoulder and drag bodies. Compatible with the new auto-search bodies feature. Dragging feels more natural -- just grab, hold, and drop with a single button press. There is no longer the need to press the button twice. Also, it's no longer possible to walk away from a body while unintentionally dragging it. Set "tdm_frobhold_delay" cvar to delay of 0 to restore TDM v2.11 (and prior) behavior. Candles: New players will have less to learn to get started extinguishing candles. With TDM v2.11 and earlier, some players didn't know they could extinguish candles by picking them up and using them. Instead, they resorted to throwing them to extinguish them or hiding them. Hold frob to extinguish a candle feels like "pinching" it out. Once a candle is picked up, players still have the ability to manipulate and use them the same way they are used to in TDM v2.11 and earlier. For players who ghost and have the goal of putting objects back to their original positions, they'll have an easier time and not have to deal with candles popping off their holders when trying to place them back carefully. Set "tdm_frobhold_delay" cvar to delay of 0 to restore TDM v2.11 (and prior) behavior. Solution Issues Bodies: Frob does not drop a shouldered body, so that might be unexpected for new players. This is also different than Thief where a second frob will drop a body. "Use Inv. Item" or "Drop Inv. Item" drops the body. This is the same as TDM v2.11 and earlier. This is the price to pay for being able to frob (open/close) doors while shouldering a body. Patch was updated to drop body on second frob, while allowing frob on doors, switches, etc. Candles: Picking up a candle or lantern requires a slight delay, because the player must hold the frob button. The player might unintentionally extinguish a candle while moving it if they hold down frob. The player will need to learn that holding frob will extinguish the candle. The player can change the delay period via the "tdm_frobhold_delay" cvar. Also, when the cvar is set to a delay of 0, the behavior matches TDM v2.11 and earlier, meaning the player would have to first "Frob/Interact" to pick up the candle and then press "Use Inv. Item" to extinguish it. Some players might unintentionally extinguish a candle when they are trying to move it or pick it up. They need to make sure to hold frob to initiate moving the candle. When a candle is unlit, it will highlight but do nothing on frob. That might confuse players. However, the player will likely learn after extinguishing several candles that an unlit candle still highlights. It makes sense that an already-extinguished candle cannot be extinguished on frob. The official "Training Mission" might need to have its instructions updated to correctly guide the player through candle manipulation training. Updating the training mission to include the hold frob to extinguish would probably be helpful. Similar Solutions In Fallout 4, frob uses an item and long-press frob picks it up. Goldwell's mission, "Accountant 2: New In Town", has candles that extinguish on frob without the need of picking them up first. Snatcher's TDM Modpack includes a "Blow / Ignite" item that allows the player to blow out candles Wesp5's Unofficial Patch provides a way to directly extinguish movable candles by frobbing. Demonstration Videos Note: The last two videos don't quite demonstrate the latest patch anymore. But the gist is the same. This feature proposal is best experienced in game, but some demonstration videos are better than nothing. The following videos show either a clear improvement or that the player is not slowed down with the change in controls. For example, "long-press" sounds long, but it really isn't. Video: Body Shouldering and Dragging The purpose of this video is to show that frob to shoulder a body is fast and long-press frob to drag a body is fast enough and accurate. Video: Long-Press Frob to Pick Up Candle The purpose of this video is to show how the long-press frob to pick up a candle isn't really much slower than regular frob. Video: Frob to Extinguish The purpose of this video -- if a bit contrived -- is to show the efficiency and precision of this proposed feature. The task in the video was for the player to as quickly and accurately as possible extinguish candles and put them back in their original positions. On the left, TDM v2.11 is shown. The player has to highlight each candle, press "Frob/Interact" to pick up, press "Use Inv. Item" to extinguish, make sure the candle is back in place, and finally press "Frob/Interact" to drop the candle. The result shows mistakes and candles getting misplaced. On the right, the proposed feature is shown. The player frobs to extinguish the candles. The result shows no mistakes and candles are kept in their original positions. Special Thanks @Wellingtoncrab was instrumental in improving this feature during its early stages. We had many discussions covering varying scenarios, pros, and cons, and how it would affect the gameplay and player experience. Originally, I had a completely different solution that added a special "use modifier" keybinding. He suggested the frob to use and long-press frob to pick up mechanics. I coded it up, gave it a try, and found it to be too good. Without his feedback and patience, this feature wouldn't be as good as it is. Thank you, @Wellingtoncrab! And, of note, @Wellingtoncrab hasn't been able to try it in game yet, because I'm using Linux and can't compile a Windows build for him. So, if this feature isn't good, that's my fault. Code Patch I'll post the code patch in another post below this one so that folks who compile TDM themselves can give this proposal a try in game. And, if you do, I look forward to your feedback! Player Complaints TTLG (2023-01-10) Player 1: TDM Forums (2021-03-13) Player 2: Player 3: TDM Forums (2023-06-17) Player 4: TDM Discord (2021-05-18) Player 5: TDM Discord (2023-02-14) Player 6: Player 7: Player 8:

And some info can be found on this forum topics and wiki. Wiki article: https://wiki.thedarkmod.com/index.php?title=Parallax_mapping Topic: https://forums.thedarkmod.com/index.php?/topic/22574-experimental-support-of-parallax-mapping-in-213/

I don't. It already is "memory-safe" because a group of highly skilled developers have been doing that for over a decade. Quotes from my posts above: Note the bold, which was in the original text. To be again absolutely clear - the reason I picked Rust is not that I (or anyone else) has a reservation about the quality of the C++ code the team is writing, it is (a) a curiosity project and (b) because my assumption - right or wrong - is that people, especially the core team who are responsible for making sure [supported addon workflows and] new code does not break TDM, would not want to support DLLs because it is impossible to trust that the code of third-parties does not corrupt memory (accidentally, malicious code being a separate problem). The idea is that giving people a starter pack that auto-checks things the team are unlikely to trust is not a bad thing. I also put a list of limitations directly after that, very explicitly stating "Rust is safe" is a bad assumption. Rust is not a solution, it may not be sufficient, but I'm more than happy to do a C++ version, if that is not an issue in the first place - those changes work just as well for C++, Rust or Fortran for that very reason, and nobody wants TDM to start using Rust in core, that would be nonsensical when there is an solid, stable, well-known codebase in C++ and skilled C++ devs working on it. That aside, the OOP paradigm for C++ is probably (I suspect) better for game engine programming, but I'm not going to fight any Rust gamedevs over that. The point of this is that perhaps not all features are things that could or should be in the core, and that modularity could allow more experimentation without the related risks and workload adding them to the central codebase - happy to be corrected, but I doubt bringing new core engine features is just about developing them, it's also deciding when it's worth baking all new code, and functionality, right into the main repo to be maintained for ever more for every release and every user. Similarly, but I would appreciate if you responded to the points, and the caveats, I made, rather than stating something clearly unreasonable to suggest is a bad idea. It misleads others too. For the record, I have no issue about doing a C++ SDK instead, but I'm not sure that's the issue - we could just "script" in C++ if that wasn't a concern at all.

I don't think idDebris will work in TDM. Its mentioned a couple times in the source code related to projectiles and there is a defunct def of it in d3_junk.def. AFAIK - we need to use the flinder objects which I know grayman did some work on back in probable 2.7 or 2.8 to make them usable. Unfortunately I couldn't get them to ignore their own collision, maybe there is a spawn arg I'm missing. Another issue is if you break a crate by an elevator or by a door, the flinder objects could potentially stop the elevator or door from moving. So I could either have them disappear after a time OR make them grabbable so the player can move them out of the way. I opted for the later because it made more sense.

Hello taffers, the people over at TTLG forums have started a speedbuild game jam. 1st Thief Speedbuild Jam It's not a contest, and you have a tentative submission date of Dec 1, to get a mission built for T1-3 or TDM. Looks fun, and I'm going to participate too.

I've created a GitHub repository and added the link to the original post if you wish to see the modifications I made to the source code. Just check the latest commit. Note: The code on GitHub is NOT compatible with the current version of the mod that's uploaded on ModDB (v2.0), since I've been fixing some bugs to make the animation timings more consistent and less prone to overlapping/breaking, and that involved updating the source code a bit. If you compile it and then use the executable with the current pk4 file, something will probably break. I'll update the mod soon to version 2.1, with all the changes and fixes I'm working on, but I thought I might as well share the updated code now.

Most of the shader stuff is about surfaces. For lights, it's only glprogs/tdm_lightproject.glsl, I think. And yes, now this chunk of code is duplicated in C++ code.

Oohhhh, the day has come! This old lurker releases another creation of his deranged mind...! What has he in store? Does it involve sunlight and pollen and hayfever? Will it involve strange towers and priests with bad breath? Naah, just some mediocre airship type of mission, aimed at the Anniversary mapping contest! I have a lengthy/humourly rant/lore for some of the building process for anyone interrested, in spoiler tags. According to DarkRadiant I have worked 570 hours on this, and that doesn't take into account all hours of coding and scripting. This feels like an insanely huge amount of mapping time for this small mission but I try not to judge myself. DarkRadiant says 570 so...I say thanks to all calm hours at the night shift at work where I could sit and script and write readables. And I also humbly bow myself to the scripting genuses that are on the forums. A special thanks to my girlfriend who (almost) always lets me talk about my projects. She has also written some of the readables and voiced some recordings in the mission. Thanks to Dragofer, Mirceakitsune and Melchior for much needed scripting help. Thanks to YouTube channels BGM President and Sound Effects where I've borrowed some music and sound effects. Thanks to my betatesters; nbohr1more, Bergante, datiswous, Wesp5, nightmare, Jaxa and Cambridge Spy. And a big thank you to the mod in general for still being alive and supportive! ########################################## MISSION RELATED STUFF ########################################## On an airship, heading for Flowerdale a lot of strange things can happen. As some people guzzle down liquor in the bar, some others skulk around in the shadows. Certain people cannot be trusted and there are even those that kill for a living. Somebody may or may not work for foreign powers. But everyone yearns for those shiny pennies. There are some strange things in the cargo, huge coffers that can hold bodies, alive and dead. This story may unfold in several different ways; Three characters can be chosen; Zacharias the thief, Oliver Mortimer, the assassin or Rupert Peabody, youngling of the Wizlas woodfolk. DOWNLOAD LINK https://drive.google.com/file/d/10w_SJSBAxxVFYTwPjJhIo48fEzvuTo1M/view?usp=sharing

I would like the development team to consider applying the GPL3 licence to the following Text file which was created by @Tels, @Greebo and @Dragofer. tdm_internal_engine.mtr (darkmod>materials) The reason for this request is that it is a critical core file and without it the engine (when built from source) cannot launch at all. I would also like to query whether the following script files created by @Obsttorte and @Dragofer: tdm_audiograph.script tdm_camgoyle.script tdm_grandfather_clock.script tdm_safe_lock.script tdm_safe.script tdm_turret.script were intentionally released under the CC-BY_NC_SA_3 licence or if this was an oversight? I ask since all other .script files included with TDM (and which are all called by the engine source) all contain GPL3 headers while these files have no licence information at all so naturally fall under the CC-BY_NC_SA_3 licence. Additionally in investigating which text files are required by the engine depending on scenario (and while I understand that the number of developers who are no longer on the development team may affect how many of these files can be licenced) I wondered if these too may be open for consideration as to their licence? tdm_base.def tdm_soundprop.def cursor.gui mainmenu_background_custom.gui mainmenu_background.gui mainmenu_briefing_video.gui mainmenu_briefing.gui mainmenu_credits_background.gui mainmenu_credits.gui mainmenu_custom_defaults.gui mainmenu_custom_defs.gui mainmenu_debriefing_video.gui mainmenu_defs.gui mainmenu_download.gui mainmenu_failure.gui mainmenu_loadsave.gui mainmenu_main_ingame.gui mainmenu_main.gui mainmenu_message.gui mainmenu_music.gui mainmenu_newgame.gui mainmenu_objectives.gui mainmenu_quit.gui mainmenu_settings_audio.gui mainmenu_settings_controls.gui mainmenu_settings_gameplay.gui mainmenu_settings_gamma.gui mainmenu_settings_guisize.gui mainmenu_settings_language.gui mainmenu_settings_video.gui mainmenu_settings.gui mainmenu_shop.gui mainmenu_success.gui mainmenu_utils.gui mainmenu.gui msg.gui tdm_objectives_core.gui tdm_subtitles_common.gui tdm_subtitles_message.gui tdm_gui.mtr tdm_tables.mtr tdm_guis.sndshd all.lang english.lang These provide the foundation of a working base main menu. TDM's main menu also includes several undocumented commands (that neither show in listcmds nor listcvars) which are useful to know for anyone wishing to use the base source code. I have listed the .lang files solely because of the #StringNum associations, I appreciate that they are not truly required for the above to be a foundation. While looking into how far I could break TDM in removal of files, I came across this thread by @Fiver suggesting a Libre version of TDM: https://forums.thedarkmod.com/index.php?/topic/22346-libre-version-of-tdm/ I believe that in that instance all text based files would need to be GPL3 licenced, leaving only videos, sounds, textures, models and the like as still being under the CC_BY_NC_SA_3 licence since remaking the files would likely result in most cases with near-identical looking files to the original. Thankyou for your consideration.

Inn Business It's business, at an inn, over three nights. Development screenshots: Download: https://drive.google...dit?usp=sharing Update 1.48 uploaded March 8th, 2014, one change: patches key rarely not being frobable in one of its possible spots Big thanks to my beta testers: Airship Ballet, Kyyrma and AluminumHaste! Development supporters of note: Sotha, Springheel and Obsttorte. Also thanks Sotha, for urinating in my mission. ;-) And thanks Kyyrma for the title screen! My appreciation to all forum/wiki contributors, without whom, this wouldn't exist. Thanks to positive commenters on my previous mission too, extra motivation helps! :-) Note this uses campaign features, what you use the first night, impacts subsequent nights. And to quote a tester, "...the level is maybe best experienced in more than one sitting". If you do pause between nights, please be sure to save, you can't begin partway through effectively. (If you accidentally start a night you already completed, just fail the kill objective to switch to another night.) If your frame rates are too low facing the cemetery, please reduce your "Object Details LOD" setting. It was designed with "AI Vision" set to "Forgiving", to be able to sneak through with minimal reactions, if you want more/less, adjust your settings accordingly. There are several random, conditional aspects, and ways of going about things, so others might have slightly different experiences. Post here if you discover hidden objectives for extra points! My condolences to loot completionists, I made a bit on the third night hard, you've got your challenge cut out for you! Speaking of which, there's a TDM bug that mission complete totals too high, here are the real amounts per night: 2026/970/202. Oh, there is something that in the U.S. would be rated PG, in case you play with kids in earshot. I hope you enjoy playing it, feel free to let me know you did, and I'm glad to respond to inquiries (like how stuff was done, nothing was scripted). (Note which night you are referring to if it's something specific.) (Please remember spoiler tags to not expose things meant to be discovered by playing.) Like so: [spoiler]secrets[/spoiler] Developed for TDM 2.01. PS: Thiefette, good news, no spiders! Springheel, if you find an optional objective you can skip...you might find it immersion breaking. Others, no undead! There are a couple other interactive critters though. :-) Edit note: Some posts below were from users of an unreleased version of TDM 2.02 which broke several things, they do not reflect regular game-play.

Agreed, but arbitrary native extensions are, by definition, insecure. However, wasm would enable text-to-speech, say, and I double-checked that Piper can run as a wasm implementation before responding (and even Phi2-wasm exists), so generating assets on-the-fly or doing computation is still achievable. They are a good bit slower, but that's the trade-off. Btw, I did say speech-to-text above a couple times, while I meant the reverse, although both interesting (that might seem pointless in a stealth game but the idea of having to "con" a chatbot receptionist, say, seems maybe kinda cool). That sounds cool! Strictly, this is essentially the way the experiment works, plus-or-minus some guardrails. Would that function annotation syntax involve copy-pasting plugin(X) per definition though? And maybe "extern myplugina { ... }" namespace could be less ambiguous, as there's never a "is this the add event from myplugina or mypluginb?" when you have to write myplugina::add (and it fits the familiar "namespace" semantics/syntax that already exists in DoomScripts). But either work! The other way, which I did consider, was an object like sys (i.e. "myplugina.add"), but I thought that was a bigger change to the compiler and implied the addon should have state, which seemed an antipattern (state, aside from for caching/threading, seems like something TDM should control and well-written DLLs should assume that their internal state could disappear at any second). Also, I think we are aligned on this, but to be sure, in case we are talking cross-purposes - I think scripts would not normally want to have a packaged DLL when the functionality they want is already supplied by a widely-used DLL addon for a range of reasons - therefore scripts would need to shadow-declare external functions from a completely separately supplied DLL addon and expect TDM to confirm they match on load (e.g. my grab log demo is a tiny DoomScript-only pk4 that exports a logs to mod_web_browser based on @snatcher's naming logic, so it would seem brittle to copy-paste a duplicate libtherustmod_web.so into the pk4, and to trust signatures matched without checking, until TDM crashed mid-game). Since namespaces are there already, I guess you mean adding extern as a not-quite-namespace? I was thinking that's a smaller change than the other options above, but happy for feedback! In my mind, the bigger changes were: #library - a directive to create a header file, equivalent of (e.g.) a SWIG interface file - this could be replaced by mandating a DLL callback to return the interface declaration. A C++/C#/Rust SDK could even write that call into the DLL automatically by inspecting the exposed function definitions (in retrospect, this seems better than adding a directive) libraryfunction as an implicit type - this was to stick to the paradigm of function, virtualfunction and sys events, as implemented in TDM at the moment, which catches signature issues during initialization in the same TDM code that checks every event call right now. But this type also lets TDM capture which library was being called (and allow for the fact a definition might not yet be loaded) - this could be simulated by function/virtualfunction but it might mean more code changes to handle cases, rather than fewer, and I suspect the final check of "have the DLLs supplied all the callbacks with the signatures the scripts wanted?" would become messier bytes type - this seems the most controversial to me. I did think that this could be forced to not be variable-assignable (and so never appear explicitly in a script), ensuring any bytes return value is only every passed immediately into another event call. However, in terms of having it at all, the type itself seems essential unless DLLs would get direct C++ access to many TDM methods (which, as discussed, seems inherently undesirable for both backwards compatibility and runtime stability) int type - necessary for a DLL callback signature to ensure it only gets an int to an int parameter - could be worked around by writing a way for DLLs to declare callbacks with event args directly (as CallLibraryEvent doesn't care about float vs int), but that seems like more code to enable two ways of declaring callbacks, and seems more confusing for a script-writer when an extern/plugin declaration can't explicitly state the argument type a DLL callback will cast to (anyway, within a script, float/int remain interchangeable) [Ed] That said, if the lesser of two evils would be fewer/no interface/stability checks to minimize compiler/interpreter code-changes, at least to begin with, that would certainly change my logic above.

I can say for sure that this is a marvelous technical achievement A geek inside me cries about how cool it is But I don't see much point in having Rust scripts in TDM, and here are some reasons for this. Note: my experience in Rust is just a few days writing basic data structures + some reading. 1) Generally speaking, high-performance scripts are not needed. Some time ago there was an idea that we can probably JIT-compile doom scripts. While I would happily work on it just because it sounds so cool, the serious response was "Let's discuss it after someone shows doom scripts which are too slow". And the examples never followed. If one wants to write some complicated code, he'd better do it in the engine. 2) If we wanted to have native scripts, it should better be C/C++ and not Rust. And the reason is of course: staying in the same ecosystem as much as possible. It seems to me that fast builds and debugging are very important to gamedev, and that's where Visual Studio really shines (while it is definitely an awful Windows-specific monster in many other regards). I bet C/C++ modules are much easier to hook into the same debugger than Rust. And I've heard rumors that scripts in C++ is what e.g. Doom 2016 does. The engine will not go anywhere, and it's in C++, so adding C++ modules will not increase knowledge requirements, while adding Rust modules will. Rust even looks completely different from C++, while e.g. Doom script looks like C++. And writing code in Rust is often much harder. And another build system + package manager (yeah, Rust ones are certainly much simpler and better, but it is still adding more, since C++ will remain). Everyone knows that C++ today is very complicated... but luckily Doom 3 engine is written in not-very-modern C++. As the result, we have at least several people who does not seem to be C++ programmers but still managed to commit hefty pieces of C++ code to the engine. Doing that in Rust would certainly be harder. 3) If we simply need safe scripts in powerful language, better compile C++ to wasm and run in wasm interpreter. Seriously, today WebAssembly allows us to compile any C++ using clang into bytecode, which can be interpreted with pretty minimalistic interpreter! And this approach is perfecly safe, unlike running native C++ or Rust. And if we are eager to do it faster, we can find interpreter with JIT-compiler as well. Perhaps we can invent some automatic translation of script events interface into wasm, and it will run pretty well... maybe even some remote debugger will work (at least Lua debuggers do work with embedded Lua, so I expect some wasm interpreter can do the same). However, after looking though the code, it seems to me that this is not about scripts in Rust, it is about addons in Rust. So it is supposed to do something like what gamex86.dll did in the original Doom 3 but on a more compact and isolated scale. You can write a DLL module which will be loaded dynamically and you can then call its functions from Doom script. Is it correct? Because if this is true, then it is most likely not something we can support in terms of backwards compatibility. It seems that it allows hooks into most C++ virtual functions, which are definitely not something that will not break.

Had some buggers with SDL's cpu detection code changing the denormals are zero detection code to TDM's fixed it strangely huh ?. i also added TDM's detection code for SSE3 AVX and AVX2 in case someone wants to build it using the old SDL1.2 since it only has detection code upto SSE2. The old 3DNow code was still in there as well but is unsupported in the upcomming SDL3 (also disabled by Daniel). ALTIVEC... groan but SDL does support it. sikkmod and sikkmodd3xp was ported to dhewm3 so that's a plus sikkmodd3xp has a bug though which makes monsters nearly unkillable if firering a weapon head on (only splash damage seems to work). It also uses a somewhat older codebase than sikkmod for the base game (i actually updated the code to the later sikkmod version some years back but not for dhewm3, gonna have to try and get it ported).

@nbohr1more, I just recently noticed that back in Oct you reported in https://www.ttlg.com/forums/showthread.php?t=152771 I didn't see anything about this in the current "What's New in 2.13". Will this new functionality actually happen for 2.13, and if so what FMs can now be re-downloaded to get the enhanced translation packs? Particularly "early TDM missions [that] also have German, Italian, French, etc translations". Pointer to any new bugtracker/forum/wiki info about this appreciated.

I think it's good to make sure it's only happening in 2.13 and not also in 2.12. If it also happens in 2.12 it's probably just an (lod related) mission bug that the missionmaker (bikerdude) has to fix. I already send your post info to him (he's not on the forums)

I would like to download the source code and play around with it. The source code compilation procedures shows in a pic that the source code must be next to the installed game. I was wondering if we can only play around with the source code with the game installed as well or can we directly run the game from the source code? Thank you