Search the Community

Introduction I translated The Dark Mod into Turkish. I carefully translated all texts into Turkish without disturbing the atmosphere of the game and following the daily Turkish usage. Now you can experience The Dark Mod in our native language Turkish. In this way, you can more easily connect to the game's story and better adapt to its world. This Turkish patch is a language pack that translates The Dark Mod into Turkish. It contains various translations that allow you to play the game in Turkish. Included -User Interface -(Official Mission) Training Mission (work in progress) -(Official Mission) A New Job (work in progress) -(Official Mission) The Tears of Saint Lucia (work in progress) Credits Outsider One (Text Translation, Playtester) Notepad ++ (Text Editing Software) 7-Zip (File Packaging Software) Download Official Turkish translation file you need to download and use. TDM_v2.14_TurkishTranslation.7z Turkish translation files of 3 official missions not included in the official translation. TDM_v2.14_OM1_TrainingMission.7z TDM_v2.14_OM2_ANewJob.7z TDM_v2.14_OM3_TheTearsofSaintLucia.7z Translated text in case you are interested in changes. TDM_EditedFiles.7z If you want to examine the glossary. TDM_Glossary.7z More Information Version: 2.14 Size: ??.?? MB Start Date: 08/01/2017 Release Date: 14/02/2017 Last Update Date: 02/02/2019 Creator: Outsider One Turkish Steam Guide Thread: Link Outsider One Turkish Patches: Link

@nbohr1more@duzenko@cabalistic ------------- Warnings --------------- during The Dark Mod initialization... WARNING:Compiling shader file interactionMultiLight.fs failed: Fragment shader failed to compile with the following errors: ERROR: 0:15: error(#106) Version number not supported by GL2 ERROR: 0:85: error(#202) No matching overloaded function found textureGather WARNING: 0:85: warning(#402) Implicit truncation of vector from size 1 to size 4. ERROR: error(#273) 2 compilation errors. No code generated File indexes: 0 - interactionMultiLight.fs 1 - tdm_shadowmaps.glsl 2 - tdm_utils.glsl 3 - tdm_poissondisk.glsl WARNING:Failed to attach shader interactionMultiLight.fs to program interactionMultiLight. Might be the reason, have to wait for dev to take a look

Just did the update to 2.13. The update process went smoothly. But when I try to load the program I get: "Error: file script/tdm_slowfall_potion.script, line 4: 'playertools_slowfallpotion' : redefinition; different basic types" Any suggestions? Thanks

+++ Announcing the Heart of Lone Salvation +++ Enjoy your extended weekend with this monster easter egg! Heart is a full-size Dark Mod FM, the third in the Thief's Den series in which you play Farrell. Story: Not heard from Sam since I turned down the Edridge job as too risky. Now I'm low on funds and have no choice. A gem called the Heart of Lone Salvation which they say brings good luck - but only once. Sounds foolish but who cares? Worth a fortune on the thieves' market if I can get inside Edridge Hall - and Lord Edridge is very wealthy. Sam knew him from the old days as a common lifter who made good when he found the Heart. It's a beautiful night - dank, cold; fog's rolling in; maybe Edridge's luck is about to run out. Must read: The Heart must NOT be destroyed until you have finished all your other objectives. If you have then sorry, it may be that you will have to noclip to finish the mission. Nobody, including myself, ever did it that way before. I'll have to find a solution and do an update in the future. SIZE: ALLOW 5 TO 6 HOURS PLAY FIRST TIME AROUNDPERFORMANCE: Players with low end machines should play this with low settings on Hard-LoPC [difficulty level] with fewer guards. You won't miss anything. I've played it on a 2GB machine with an old Geforce FX5900 card. Lag in some areas but tolerable.SECRETS: There are many 'secrets' in this FM. If you don't like secrets, [then to] turn off 'Found Secret' messages, create/add to autoexec.cfg in doom3/base a line:seta mvr_show_secrets 0In-Game FOG: Game characters may see through fog better than you. Take extra care.Player tools Slow Match: You have a slow match (smouldering splint) and a spare [match] important to this mission so don't lose them. Practice on any candle or torch that is not lit or just as a convenient light in a dark area. Ghosters can use it to relight extinguished flames. Use the drop control to put the match in your hands and move the match so the glowing end is close to the wick, etc. Press the 'Use' control to put the match back in your inventory bag.BODIES: You need space to shoulder a body as well as drop one so you may need to drag into an open area before trying to shoulder again with the 'use' control.NEW OBJECTIVES: New objectives go to the top of the list to make them easier to find. Sometimes more than one at once.BRIEFING: Do not use Esc during the briefing or the cursor becomes invisible. (You can still select blind though looking for highlights.) You can skip the briefing with the left mouse button. If you miss anything you can use the back button to show it again.Info: This mission was optimized and updated to version 2 by Bikerdude, a klot of bugs were quashed and performance improved through out the mission.

I'm good at causing uncommon errors. I found this thread about it (there was nothing in the wikki): and this in the idtech4 modwikki: Error: i >= MAX_REACH_PER_AREA Severe : An error issued by the AAS compiler. An Area that has been created has more than 256 adjoining Areas . You should simplify the map’s brush geometry (which the aas compiler uses as input) using monster clip to block off areas that the AI won’t/shouldn’t go. This error may also be caused by surrounding the map with a large caulk hull with leaks between the map and hull.

Ah, OK. I only can say that I don't note any issue in both Metro in the default settings. Maybe it was also meanwhile patched. The only game where I noted fp dropdowns in higher settings was Sicaria, the free stealth game. Currently I play also Call of Juarez - Gunslinger, which also appears sometimes in the Giveaways, normally for few money (€2-3) in Steam, A very nice FPS well optimized with very good graphics. Somewhat hardcore gameplay. Old but gold

I can confirm both issues (without using my patch of course). With my patch I get this error in By Any Other Name instead: line 2895: Type mismatch on redeclaration of max. I have no idea what causes this problem, but at least... ... I took a quick look at my patch and it seems the endTime error is connected to the holywater script, which I had changed and thus avoided the issue. Renaming endTime in the base game to holywater_endTime should fix this!

Done, and I still have the same problem. But I could narrow it down a bit! Before I moved my fms folder over everything worked fine, but once I did the error occurred when switching e.g. between the two official missions. Copying only my missions.tdminfo didn't cause it. So one of the other missions must have introduced the problem, but I wasn't aware that TDM does even look at other missions besides the one you have selected. Or does it?

Author Note: This is a brand new mission and a new entry into the accountant series. There are some different than usual puzzles in this FM, so if you find yourself stuck try to think about your pathway forward in a logical manner. And if you're still having troubles then pop by this thread and ask (preferably with spoiler tags). This FM is brand new and serves as the first installment in The Accountant series, a few years back there was a small prologue style mission released however I felt that it did not represent The Accountant series so I decided to go back to the drawing board and do a whole new mission that's larger, has a better level design and has a story that lines up closer to what I plan to do with the accountant series. The mission is medium sized and you can expect between 30-90 minutes to complete it depending on your playstyle. Beta Testers Captain Cleveland Crowind Kingsal PukeyBee Skacky SquadaFroinx Voice Actors AndrosTheOxen Epifire Goldwell Stevenpfortune Yandros Custom assets Airship Ballet Bentraxx Bob Necro Dragofer DrKubiac Epifire Kingsal MalachiAD Sotha Springheel SquadaFroinx Available via in-game downloader File Size: 233 MB - Updated to v 1.1 (01.06.2018)

Do we have one of these? I know we kind of have one for upcoming TDM projects, but not a general game thread. I'll start. Elden Ring:

Announcing the Release of 'Requiem' for The Dark Mod! Download Download the latest version of the Dark Mod here: http://www.thedarkmo...wnload-the-mod/ Download the mission here: Mediafire: http://www.mediafire...u89/requiem.pk4 Southquarter: http://www.southquar...ons/requiem.pk4 Fidcal.com: http://www.fidcal.co...ons/requiem.pk4 Create a folder in your Dark Mod install with the path "darkmod/fms/requiem" and place the downloaded .pk4 file inside. When you load up The Dark Mod, the mission will appear on the "New Mission" page. Requiem can also be found directly using the in-game loader. Gameplay Notes While this mission is playable in TDM 1.8, for an optimal experience please download and play in TDM 2.0 (or higher). Most inventory items in the game can be dropped, so no need to carry them around after they are no longer of any use. Note that If you use noclip or other console commands while playing, there is a good chance that you will break the intended flow of gameplay. Credits Mapping and Readables: Gelo R. Fleisher Voice Acting: Goldwell Additional scripting: Obsttorte Additional textures and assets: Flanders, Sotha, Grayman, Springheel, Bikerdude, Obsttorte Additional map optimizations: Bikerdude Testers: Bikerdude, Obsttorte, Gnartsch, AluminumHaste, Baal, nbohr1more, PPoe Custom Soundtrack: Leonardo Badinella - http://leonardobadinella.com/ Additional Music: Lee Rosevere - http://freemusicarch...c/Lee_Rosevere/ Marianne Lihannah - http://www.funeralsinger.net/ Vox Vulgaris - http://www.last.fm/music/Vox+Vulgaris/ A note from the author Hi all. While I've been involved in indie game development for a while now, I'm first and foremost a writer. My most recent project has been a novella that tries to capture the visual feel and tone of the Thief series (you can find the link below). As I was writing, I found myself playing a lot of Thief and Dark Mod fan missions, and got to thinking that maybe I wanted to make one myself, as a companion piece to the book. When I finished up writing, I had a bit of down time and decided to take the plunge. Having never done any serious mapping before, my plan was to make a small mission that I could bang out in a month or two and call it a day. Well, as sometimes happens, the project got a little bit bigger than I had planned. Ten months, and lots of elbow grease later, Requiem is finally ready for you to play. I'd like to thank everyone who helped pitch in to help make Requiem come alive, from those who took the time to answer my many questions on the forums to those who actively contributed to the FM. I especially want to thank Bikerdude who served as my mapping mentor, and Obsttorte whose clever scripts really turned what was in my head into the game that you are playing. Above all, I want to thank you for downloading and playing Requiem; I hope you enjoy it. Links of Interest Author's Blog: http://gfleisher.blogspot.com/ Companion Novella (Amazon): http://www.amazon.co...k/dp/B00BYEW02M Companion Novella (Smashwords): http://www.smashword...oks/view/298956

I thought this could happen when you have not specified your mod folder correctly and you use custom models inside your fm instead what exists in the core game. I mean it sounds like this situation from the description.

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?

I have recently installed Dhewm3 (with the Doom 3 demo) and DarkRadiant. I know my way around GTK Radiant and Preditor, so I assumed DarkRadiant would be a walk in the park. However, I'm getting these two problems I never got with the other editors. 1) I have installed DarkRadiant from the package darkradiant-3.7.0-x64.portable.7z. I launched it, configured it to use the Doom 3 demo (Game Type: Doom 3 Demo), selected the folder where the Dhewm3.exe file is located, but it cannot find any textures. 2) If I try to make a test map (a square room with no textures, a player start) and save it, I get an error message that says: "Failed to locate map format module". Subsequently, nothing gets saved. I have pasted the DarkRadiant log at https://pastebin.com/YAGv2u5h . You can see a screenshot showing the problems (error, no textures) at https://imgur.com/a/qVhx4dv. How do I solve these problems?

hey stgatilov, I'm trying to compile TDM source, but it seems the source compilation guide here is out of date, it still recommends VS2017 when the source now requires VS 2022 and after installing the latest VS, I get a bunch of unresolved external symbol errors for OpenAL mostly, I assume I need to update OpenAL soft? I'm still a little green about this type of errors, when they happen, they are the ones that stump me the most. Severity Code Description Project File Line Suppression State Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(helpers.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(alfstream.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(ambdec.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(chorus.cpp.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(fshifter.cpp.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(modulator.cpp.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(vmorpher.cpp.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(threads.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(alconfig.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(cpu_caps.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(convolution.cpp.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(winmm.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(wave.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(hrtf.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(panning.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(event.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(null.cpp.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(wasapi.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(dsound.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(alc.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(logging.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(voice.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(auxeffectslot.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\pugixml.lib(pugixml.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(buffer.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(source.obj) 1 Error LNK2001 unresolved external symbol __GSHandlerCheck_EH4 DarkModTools L:\darkmod_src\OpenAL32.lib(state.obj) 1 Error LNK2019 unresolved external symbol __imp___std_init_once_begin_initialize referenced in function alcOpenDevice DarkModTools L:\darkmod_src\OpenAL32.lib(alc.obj) 1 Error LNK2019 unresolved external symbol __imp___std_init_once_complete referenced in function alcOpenDevice DarkModTools L:\darkmod_src\OpenAL32.lib(alc.obj) 1 Error LNK2001 unresolved external symbol __std_reverse_copy_trivially_copyable_1 DarkModTools L:\darkmod_src\OpenAL32.lib(hrtf.obj) 1 Error LNK2019 unresolved external symbol __std_reverse_copy_trivially_copyable_8 referenced in function "class std::unique_ptr<struct HrtfStore,struct std::default_delete<struct HrtfStore> > __cdecl `anonymous namespace'::LoadHrtf02(class std::basic_istream<char,struct std::char_traits<char> > &,char const *)" (?LoadHrtf02@?A0xe8b25d95@@YA?AV?$unique_ptr@UHrtfStore@@U?$default_delete@UHrtfStore@@@std@@@std@@AEAV?$basic_istream@DU?$char_traits@D@std@@@3@PEBD@Z) DarkModTools L:\darkmod_src\OpenAL32.lib(hrtf.obj) 1 Error LNK2019 unresolved external symbol __std_reverse_copy_trivially_copyable_4 referenced in function "void __cdecl MixDirectHrtfBase<&void __cdecl `anonymous namespace'::ApplyCoeffs(class std::array<float,2> * __restrict,unsigned __int64,class std::array<class std::array<float,2>,128> const &,float,float)>(class std::array<float,1024> &,class std::array<float,1024> &,class al::span<class std::array<float,1024> const ,-1>,class std::array<float,2> * __restrict,float *,struct HrtfChannelState *,unsigned __int64,unsigned __int64)" (??$MixDirectHrtfBase@$1?ApplyCoeffs@?A0xd07b7227@@YAXPEIAV?$array@M$01@std@@_KAEBV?$array@V?$array@M$01@std@@$0IA@@4@MM@Z@@YAXAEAV?$array@M$0EAA@@std@@0V?$span@$$CBV?$array@M$0EAA@@std@@$0?0@al@@PEIAV?$array@M$01@1@PEAMPEAUHrtfChannelState@@_K5@Z) DarkModTools L:\darkmod_src\OpenAL32.lib(mixer_c.obj) 1 Error LNK2001 unresolved external symbol __std_reverse_copy_trivially_copyable_4 DarkModTools L:\darkmod_src\OpenAL32.lib(mixer_sse.obj) 1 Error LNK1120 6 unresolved externals DarkModTools L:\darkmod\TheDarkModx64.exe 1

I'd not written that very well, mb - the idea is that Rust is a compiled language which provides a lot of flexibility, but its main motivating benefit is the decreased risk of accidental subtle memory bugs, aka being "memory-safe" -- essentially, by having a syntax that ensures traceability of lifetimes of all the variables and making sure you can't accidentally refer to a freed var or access unallocated memory (or it won't compile), a large class of hard-to-pinpoint fails that would break TDM in awful ways are avoided. As a result, I find that most of my debugging is in getting it to compile - once it compiles, then bugs are more likely logic bugs than coding issues or typos. This is sometimes mis-sold as "Rust is safe" - but (a) interacting with C++ voids those guarantees (at least at the boundary); (b) you can explicitly break the safety rails if you want; (c) if you don't handle an error, the code will still crash, (although it's more likely to do it where the error actually is, or somewhere obviously related, and give a useful backtrace, similar to scripting); (d) if third-party libraries explicitly do unsafe things internally (which is sometimes necessary), and there are bugs there, those can still bite you. So it's not a panacea, but while opinions vary on it as a language, it sidesteps the biggest footguns of most compiled languages. Fair points. In terms of the platform-agnostic issue, that is maybe the (slightly) more straightforward one - a big use-case for Rust is for Python extension modules. Obviously, the same issue exists there - when you install a library from PyPI or Conda, it should not matter what machine you run on, it should Just Work. The most common (free) approach is to airdrop a standard Github Action that, on push, fires up a matrix of architectures to build and test, and can create a Github Release with each of them suffixed by arch automatically. This can be set up without config, just with a file in the repo, so the simplest approach would be to add it to the template project. I noticed that idFileSystemLocal::FindDLL already implements this approach, so we could just piggyback. Tbh, I expect that encouraging cross-compatibility this way, in general, is why Apple lets Github spin up free OSX build runners. OTOH, that (a) doesn't help anyone not wanting to use Github (e.g. Gitlab requires Gitlab Premium for Mac builds, at least), and (b) won't cover rarer architectures like PPC or SPARC, which would require a self-hosted runner. The security point is tougher - I had been thinking about an approach but wasn't sure if this was overkill. If there was an allow-list (like the downloadable missions) and the TDM devs insisted on the use of the template repo and Action for any build, then you could auto-confirm checksums against the allow-list at runtime, so you knew for sure that binary X was built from code at github.com/blah/Y because the same SHA is in the automated release, (and you can see the CI log for the build, so you can see it's the visible source that made it). The other route is Reproducible Builds, but then you would need re-builds to verify, rather than just being able to map library+arch to DLL checksum. This still isn't perfect as (a) like the missions, someone on the core team would need to greenlight new library releases by adding the checksum (or a generated JSON array for the archs) to let TDM load them (by default), which is work, (b) people are unlikely to go through the code in detail when signing off a new release from a known contributor, so an xz style attack is possible (although that's true of any TDM dep too), and (c) if somebody's Github account is compromised and they can convince the team that they are the real person, they could get a checksum for a malicious release greenlit, at least for a while. The main mitigation for the hassle is that, after two weeks, I can only think of a few genuinely useful usecases for libraries - I'm sure others can think of more, but given that how ever many scripts can then hook in to a few libraries to apply the functionality in different ways, it's hard to see how there would be a growing workload from dozens of new libraries churning out. For instance, how many speech-to-text libraries would there be? Given every use-case can be a new script that uses the same STT engine... I'm guessing that doesn't really address those points for you fully, but I would imagine that such functionality would necessarily be opt-in or otherwise gated (and, hence, the point about syntax for being able to conditionally use libraries, so many scripts can fallback to standard behaviour without them).

Sure but good luck with the math. There's little room for error in this case.

The Wizard's Treasure Greetings taffers, I'm delighted to release my latest mission, just in time for the 15th Anniversary deadline. The Wizard's Treasure is a beginner-friendly mission suitable for thieving taffers ages 6-99. A powerful wizard is in possession of a huge and valuable emerald. Find it and steal it! The mission should take about twenty minutes to complete for a first-time player, so it will hopefully be a lot of fun if you're in the mood for a casual heist. Credits: Huge thanks to my beta-testers and sanity-checkers Bikerdude, JackFarmer, and nightmare. Available through the in-game downloader. Enjoy!

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

Yes that is an issue - for the game to draw any material it must defined in a .def file. It is the material def which points at the texture maps, and then the model is pointed at the material def via the names of it's material. For yours it could be quite simple for the time being: textures/gobmdl/ksword_rusty { metal diffusemap textures/gobmdl/ksword_rusty }

hmm yeah a new more powerfull chip would be better if they intend it to compete with the top shelf cards from nvidia. the new chip does well for its intended price segment (which we havent seen any sign of here in denmark though, the card is still listed at 1000$ for the cheapest model sigh). some of the price is tax etc which here in denmark is and has allways been 25% of the real price. so 750$ for real which is still well above the promised msrp. it is actually the fastest card for alan wake 2 beating even the 5090 which is kinda weird as this is the only game it actually beats nvidias top card in (might be better optimized for mesh shaders else im blank ???). perfomance wise it is a good deal faster than the 3090 ti but that card is also two generations old so not really ground shaking performance wise but still ok.

The votings for the game awards 2020 are starting. So, what's your game of the year? Mine is clearly Doom Eternal. On highest difficulty, this game gives you the same feeling of acomplishment as Dark Souls and the likes. This FPS-game just rocks and rolls, both due to gameplay and soundtrack (obiously I also voted for Doom Eternal in the best soundtrack category)! Regarding the other nominees: Yes, TLOU 2 was an interesting experience, but game of the year? NO! Hades: The game would've been better had it been a true rogue-like. The way it is currently implemented, to much grind is involved, so that it fails to motivate me on the long-term. FF VII: Haven't played it, yet, as I am waiting for the PC release, but I have a feeling it might be a strong Game of the Year contender, too. Ghost of Tsushima and Animal Crossing: Don't understand why these would deserve the spot. Scrolling further down, I see that "Star Wars: Jedi Fallen Order" (technically a 2019 game) is nominated for best action-adventure. That's a definitive yes from me, as I really loved that game, although I think its chances to win are rather slim next to the other nominees.

Lord Edgars Bathhouse By Goldwell Credits Briefing video - Crowind Briefing script revision - Moonbo Beta testers - 161803398874989, AluminumHaste, Bikerdude Splash screen - Dominus (created), MalachiAD (edited) Special thanks to Bikerdude for creating the weapon shop & blinging up the outside starting city area Voice Actors: Bikerdude, Goldwell Sound effects from Freesound.org: Headphaze (234516), unfa (157133), JimiMod (252762) sonsdebarcelona (71149), simplen00b (182331) Erokia (183881), kyles (51806), Dpoggioli (213605) rdneubauer (93783), ninebilly (173014), crcavol (154655) sangtao (189664), stereodivo (101847) Other sfx/music credits Bluedark - Invisible Figures Michael J Schumacher - E Flat Drone Speedenza - Big space drone 3 Blue Sizzle" Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 3.0 http://creativecommons.org/licenses/by/3.0/ Available via the in-game downloader Filesize: 67.73 MB

I'm returning to continue my work, and this silly problem eludes me. Thanks for your help!

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)