Search the Community

Something wrong with the hosts? See following topic for the investigation. https://forums.thedarkmod.com/index.php?/topic/22663-cannot-download-dark-mod/

Maybe something is wrong on the hosts on that time? Others cant download it as well. https://forums.thedarkmod.com/index.php?/topic/22662-error-missing-end-chunk-0-193/

Yea, I'm gonna go with autosave. Saving tiny files like these is quick enough that I think I can do it whenever you make changes, maybe with a couple seconds delay so that it only saves when you stop making changes. I think it should be fine. I can't think of a reason that hotkey wouldn't work either. Ctrl-z is one of Godot's default UI binds and the input is detected internally by the CodeEdit node itself (which is fully implemented by Godot), so it wasn't set up by me. But as far as I can tell I did set up ctrl-s the same way (in the l suffix one). And it works on windows, at least.

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.

In that case, I'm a bit lost. It's the same as mine. I exported two versions of the app with a different setting on the hotkey, just now. If you can try them out to see if they work. I uploaded them temporarily to the releases: https://github.com/Skaruts/tdm_packer_2/releases/tag/alpha_0.3 I would prioritize the one with the l suffix, and if that one still doesn't work try the one with the u suffix. I don't suppose this will fix it. I changed the input mode of the hotkey to unicode (u) and keycode (l, for "latin keycode") instead of the physical location of the key. Since your keyboard is querty, I'm not sure this will make any difference, but if you could try them out, we could know for sure. All the default key bindings that godot ships with are using latin keycodes, and that includes undo/redo which work on your end, so I'm wondering.... (You can copy the data folder from your tdm packer folder into the new ones, so you don't have to set the paths again)

You can press ctrl+s. The hotkey is from the text editor itself, so you must click the text editor for it to gain focus and receive input. I've been on the fence about just having a global save functionality that just saves all mission files at once, whenever you do ctrl+s. Might make it easier on users and also on me, because individual saving is harder to work with. Or... I could add a timer, that counts down a couple seconds and auto-saves, after you make some changes. That could work too.

I'm replaying the original DeusEx (vRSD) and accidentally discovered an useful feature in its input system, which I realized I should suggest for TDM as it can be helpful. DX has a modifier called Strafe: While this key is pressed and held, the mouse no longer turns the view but instead moves the player like the WASD or arrow keys based on the mouse speed. If others find this useful I'll post the idea to the bug tracker. If you go to Settings - Controls - General there is a setting called Free Look; If disabled the camera pitch is forced to 0 and up / down mouse movement is used for walking. I see two issues with this: First it's partial and for one axis, you still use the X axis of the mouse to turn and only the Y axis to walk back and forth, if you want to use the mouse for movement its X axis should be left / right to strafe while the Y axis should be forward / backward walking. The second issue is there's no keybind to toggle this mode on the go, one should exist with a toggle option based on whether you want to hold the key or press it to turn this on and off. As a bonus, while the key is held or toggled, movement keys should control the camera instead so the modifier fully reverses the purpose of the mouse and WASD / arrow keys. I think offering better control over the mouse movement system could be useful for sneaking and peaking behind cover. More than 90% of TDM players likely use keyboard & mouse instead of a controller with thumb sticks: With WASD movement you rely on the Sneak key to move slowly and avoid making noise. When hiding behind an obstacle, you could aim the camera in a desired direction then hold a key to move with the mouse, which would allow a more controlled movement speed based on how much noise you're willing to risk making.

It might be best to simply encourage them to come to the forums

There's a person messaging the Dark Mod twitter account, saying they can do a Catalan translation of the game. I pointed them in the direction of the Wiki and the forums, but they're saying they want to email someone about it. I'm not really involved in the translation side of things, so I don't have any useful input here. Any ideas?

Unfortunately, I don’t think this is possible—at least not with the way the mod is currently implemented. All the models and animations are tied to the “unarmed” weapon entity, not the player entity. In order to have the legs and the rest of the body, we would need to add the models and animations to the player entity and modify the source code to allow the body to be visible, kind of like how it's done here. I did initially try this method but realized that the existing model/animations are a bit of a mess and it would be a LOT of work to make it look good. Also, I chose to do it this way to allow the mod to be compatible with everything, since the script and def files for the "unarmed" entity aren’t modified by any FMs (as far as I know—I haven’t tested them all). I assumed that someone may have tweaked the player files for their FM, as those are far more relevant than the "unarmed" files (which are essentially blank in the vanilla game). If I had overwritten them, I’d risk breaking their mission. There has been some discussion in the forums about having full body awareness and there didn't seem to be a lot of interest in it. Plus, it could end up being immersion-breaking. Imagine standing on a small rope and then looking down, only to see your feet just kind of floating in midair.

BC4 is single channel. It would require another branch in the normal shaders and would probably look awful because the Y slope would need to be reconstructed from the x slope data. Might be useful for grayscale heightmap input data though ( both for POM and Doom 3 formats ). @OrbWeaver @stgatilov ?

You are assuming way too much, and you're creating artificial pressure. Nobody in the public forums knows whether TDM team even considered including this feature in TDM core, regardless of its completion state or quality. Obviously you have right to have a personal opinion on the modification itself (which I think is cool too). Sorry for the offtopic here Jivo, you're doing great, and don't let this little side note distract you from your work

@stgatilov Even better news! The following commit fixed this issue regardless of r_tonemapOnlyGame3d setting. r10930 | stgatilov | 2025-01-25 | 7 lines Clear background during main menu. This fixes the issue e.g. with AT1: Lucy and tonemap disabled. The briefing there does not use any backgrounds, and no-clear policy results in HOM-like effects. Originally reported here: https://forums.thedarkmod.com/index.php?/topic/22635-beta-testing-213/#findComment-499723

Hi folks, and thanks so much to the devs & mappers for such a great game. After playing a bunch over Christmas week after many years gap, I got curious about how it all went together, and decided to learn by picking a challenge - specifically, when I looked at scripting, I wondered how hard it would be to add library calls, for functionality that would never be in core, in a not-completely-hacky-way. Attached is an example of a few rough scripts - one which runs a pluggable webserver, one which logs anything you pick up to a webpage, one which does text-to-speech and has a Phi2 LLM chatbot ("Borland, the angry archery instructor"). The last is gimmicky, and takes 20-90s to generate responses on my i7 CPU while TDM runs, but if you really wanted something like this, you could host it and just do API calls from the process. The Piper text-to-speech is much more potentially useful IMO. Thanks to snatcher whose Forward Lantern and Smart Objects mods helped me pull example scripts together. I had a few other ideas in mind, like custom AI path-finding algorithms that could not be fitted into scripts, math/data algorithms, statistical models, or video generation/processing, etc. but really interested if anyone has ideas for use-cases. TL;DR: the upshot was a proof-of-concept, where PK4s can load new DLLs at runtime, scripts can call them within and across PK4 using "header files", and TDM scripting was patched with some syntax to support discovery and making matching calls, with proper script-compile-time checking. Why? Mostly curiosity, but also because I wanted to see what would happen if scripts could use text-to-speech and dynamically-defined sound shaders. I also could see that simply hard-coding it into a fork would not be very constructive or enlightening, so tried to pick a paradigm that fits (mostly) with what is there. In short, I added a Library idClass (that definitely needs work) that will instantiate a child Library for each PK4-defined external lib, each holding an eventCallbacks function table of callbacks defined in the .so file. This almost follows the idClass::ProcessEventArgsPtr flow normally. As such, the so/DLL extensions mostly behave as sys event calls in scripting. Critically, while I have tried to limit function reference jumps and var copies to almost the same count as the comparable sys event calls, this is not intended for performance critical code - more things like text-to-speech that use third-party libraries and are slow enough to need their own (OS) thread. Why Rust? While I have coded for many years, I am not a gamedev or modder, so I am learning as I go on the subject in general - my assumption was that this is not already a supported approach due to stability and security. It seems clear that you could mod TDM in C++ by loading a DLL alongside and reaching into the vtable, and pulling strings, or do something like https://github.com/dhewm/dhewm3-sdk/ . However, while you can certainly kill a game with a script, it seems harder to compile something that will do bad things with pointers or accidentally shove a gigabyte of data into a string, corrupt disks, run bitcoin miners, etc. and if you want to do this in a modular way to load a bunch of such mods then that doesn't seem so great. So, I thought "what provides a lot of flexibility, but some protection against subtle memory bugs", and decided that a very basic Rust SDK would make it easy to define a library extension as something like: #[therustymod_lib(daemon=true)] mod mod_web_browser { use crate::http::launch; async fn __run() { print!("Launching rocket...\n"); launch().await } fn init_mod_web_browser() -> bool { log::add_to_log("init".to_string(), MODULE_NAME.to_string()).is_ok() } fn register_module(name: *const c_char, author: *const c_char, tags: *const c_char, link: *const c_char, description: *const c_char) -> c_int { ... and then Rust macros can handle mapping return types to ReturnFloat(...) calls, etc. at compile-time rather than having to add layers of function call indirection. Ironically, I did not take it as far as building in the unsafe wrapping/unwrapping of C/C++ types via the macro, so the addon-writer person then has to do write unsafe calls to take *const c_char to string and v.v.. However, once that's done, the events can then call out to methods on a singleton and do actual work in safe Rust. While these functions correspond to dynamically-generated TDM events, I do not let the idClass get explicitly leaked to Rust to avoid overexposing the C++ side, so they are class methods in the vtable only to fool the compiler and not break Callback.cpp. For the examples in Rust, I was moving fast to do a PoC, so they are not idiomatic Rust and there is little error handling, but like a script, when it fails, it fails explicitly, rather than (normally) in subtle user-defined C++ buffer overflow ways. Having an always-running async executor (tokio) lets actual computation get shipped off fast to a real system thread, and the TDM event calls return immediately, with the caller able to poll for results by calling a second Rust TDM event from an idThread. As an example of a (synchronous) Rust call in a script: extern mod_web_browser { void init_mod_web_browser(); boolean do_log_to_web_browser(int module_num, string log_line); int register_module(string name, string author, string tags, string link, string description); void register_page(int module_num, bytes page); void update_status(int module_num, string status_data); } void mod_grab_log_init() { boolean grabbed_check = false; entity grabbed_entity = $null_entity; float web_module_id = mod_web_browser::register_module( "mod_grab_log", "philtweir based on snatcher's work", "Event,Grab", "https://github.com/philtweir/therustymod/", "Logs to web every time the player grabs something." ); On the verifiability point, both as there are transpiled TDM headers and to mandate source code checkability, the SDK is AGPL. What state is it in? The code goes from early-stage but kinda (hopefully) logical - e.g. what's in my TDM fork - through to basic, what's in the SDK - through to rough - what's in the first couple examples - through to hacky - what's in the fun stretch-goal example, with an AI chatbot talking on a dynamically-loaded sound shader. (see below) The important bit is the first, the TDM approach, but I did not see much point in refining it too far without feedback or a proper demonstration of what this could enable. Note that the TDM approach does not assume Rust, I wanted that as a baseline neutral thing - it passes out a short set of allowed callbacks according to a .h file, so language than can produce dynamically-linkable objects should be able to hook in. What functionality would be essential but is missing? support for anything other than Linux x86 (but I use TDM's dlsym wrappers so should not be a huge issue, if the type sizes, etc. match up) ability to conditionally call an external library function (the dependencies can be loaded out of order and used from any script, but now every referenced callback needs to be in place with matching signatures by the time the main load sequence finishes or it will complain) packaging a .so+DLL into the PK4, with verification of source and checksum tidying up the Rust SDK to be less brittle and (optionally) transparently manage pre-Rustified input/output types some way of semantic-versioning the headers and (easily) maintaining backwards compatibility in the external libraries right now, a dedicated .script file has to be written to define the interface for each .so/DLL - this could be dynamic via an autogenerated SDK callback to avoid mistakes maintaining any non-disposable state in the library seems like an inherently bad idea, but perhaps Rust-side Save/Restore hooks any way to pass entities from a script, although I'm skeptical that this is desirable at all One of the most obvious architectural issues is that I added a bytes type (for uncopied char* pointers) in the scripting to be useful - not for the script to interact with directly but so, for instance, a lib can pass back a Decl definition (for example) that can be held in a variable until the script calls a subsequent (sys) event call to parse it straight from memory. That breaks a bunch of assumptions about event arguments, I think, and likely save/restore. Keen for suggestions - making indexed entries in a global event arg pointer lookup table, say, that the script can safely pass about? Adding CreateNewDeclFromMemory to the exposed ABI instead? While I know that there is no network play at the moment, I also saw somebody had experimented and did not want to make that harder, so also conscious that would need thought about. One maybe interesting idea for a two-player stealth mode could be a player-capturable companion to take across the map, like a capture-the-AI-flag, and pluggable libs might help with adding statistical models for logic and behaviour more easily than scripts, so I can see ways dynamic libraries and multiplayer would be complementary if the technical friction could be resolved. Why am I telling anybody? I know this would not remotely be mergeable, and everyone has bigger priorities, but I did wonder if the general direction was sensible. Then I thought, "hey, maybe I can get feedback from the core team if this concept is even desirable and, if so, see how long that journey would be". And here I am. [EDITED: for some reason I said "speech-to-text" instead of "text-to-speech" everywhere the first time, although tbh I thought both would be interesting]

Moved this topic from development forums, since it covers a potentially important behavior change in 2.13. Luckily, its important is countered by the rarity of such complicated materials. I hope that this change has not broken existing materials. And even if it had broken any, we will be able to fix them manually...

And for some pointers, read the following topic: https://forums.thedarkmod.com/index.php?/topic/22533-tdm-for-diii4a-support-topic/

All is working and has a basic directory and save system, with automatic scaling to the recommended dimenstions (upper left) and can be used just to make the maps for input images (to the right from the directory and name, the red lines indicate how the reference image stays as it is), or have the inputted image as a reference for the AI to work from. I tried to make it as simple as possible where things can be bypassed (like maps and saves) and a lot of nodes are hidden under other nodes, and nodes are pinned so you can't drag them around without unpinning them. Next step: getting it all ready and packed for download and install so ppl can use it .. and some sort of manual I guess : P @nbohr1more I see the texture guidlines were updated! But now I wonder about the recommended dimension or the heightmap?

@Epifire@nbohr1more@datiswous Thanx guys. I have been experimenting with nodes for comfyUI that generate normalmaps. Metric3D normalmap and DSINE Normal Map (more detail) do quite a good job. The only thing is that the normalmaps for TDM are different then what these nodes put out. I tried rotating the generated image 180 degrees, then have the normalmap generated and then rotating that again 180 degrees. Metric3D produces the right normalmap with that method, it seems, but DSINE doesn't. Then I tried all sorts of things with splitting the generated normalmap in RGB colors, inverting the green channel and then blending/mixing the RGB chanels back to one image, but with no success. The color/invert function in blender works different then anything I could do with the nodes I tried. Is there an other name for what blender calls invert, or an other method that might be accomplished using nodes? Ultimately I would like to make a workflow for comfyUI that produces all needed maps at once, for generated- and input images, in a way that it doesn't need editing in other software anymore ... if possible. Exept maybe from converting the files to .dds at the end.

Those hand animations are very nice to see, especially the compass animation. Can you make animation for holding / showing the map, like in sea of thieves? (Also asked for in https://forums.thedarkmod.com/index.php?/topic/21038-lets-talk-about-minimap-support/#findComment-463678

Okidoki, I finally bit the bullet & went with a Recoil 17 from PC Specialist Specs I went for are Chassis & Display: Recoil Series: 17" Matte QHD+ 240Hz sRGB 100% LED Widescreen (2560x1600) Processor (CPU): Intel® Core™ i9 24 Core Processor 14900HX (5.8GHz Turbo) Memory (RAM): 32GB PCS PRO SODIMM DDR5 4800MHz (1 x 32GB) Graphics Card: NVIDIA® GeForce® RTX 4080 - 12.0GB GDDR6 Video RAM - DirectX® 12.1 External DVD/BLU-RAY Drive 1TB PCS PCIe M.2 SSD (3500 MB/R, 3200 MB/W) Operating System: NO OPERATING SYSTEM REQUIRED The case seems to be made of metal not plastic & there's an optional water cooling unit, which I didn't get For the OS I disabled fast boot & secure boot, loaded Zorin 17.2, used the entire disk, without any installation issues Zorin is a Ubuntu fork so Ubuntu & it's other forks shouldn't have an issue if anyone else gets one of these The only minor issue is the keyboard backlight isn't recognized by default, but the forums are full of info on sorting that out, not that I'm too bothered I've installed TDM & it runs beautifully I also copied my thief 1 & 2 installations from my desktop, I had to uncomment "d3d_disp_sw_cc" in cam_ext.cfg to get the gamma processing working but they run happily too The fans switch on when booting & switch off again after a few seconds, the machine isn't stressed enough to turn them on running TDM so far - this is not a challenge btw On the whole, I'm extremely pleased So thanks for all the advice

I think we should first decide what do we want TOS for: To protect TDM from legal issues? To protect TDM team from angry mappers in case of conflicts? To guide mission authors in their work? In my opinion TOS should only cover legal issues, and wiki articles about making/releasing missions should cover author guidance. The chance of getting malware in a mission only increases after we write this publicly. Better don't even mention it, we are completely unprotected against this case. By the way, isn't it covered by "illegal" clause? I'm not sure this is worth mentioning, but I guess @demagogue knows better. By the way, which jurisdiction defines what is legal and what is not? Isn't it enough to mention that we will remove a mission from the database if legal issues are discovered? I think this is worth mentioning simply because mappers can easily do it without any malicious intent. We already had cases of problematic assets, so better include a point on license compatibility. It is a good idea to remind every mapper that this is a serious issue. I also recall some rule like "a mission of too low quality might be rejected". In my opinion, it is enough. You will never be able to pinpoint all possible cases why you might consider a mission too bad in terms of quality. And even the specifics mentioned here already raise questions. Having such a rule is already politics. I feel it does not save us from political issues but entangles us into them. If there is a mission which contains something really nasty, it will cause outrage among the community (I believe our most of active forum members are good people). If people are angry, they will tell the mission author all they think about it. And if the author won't change his mind, he will eventually leave TDM community. Then the mission can be removed from the database, perhaps with a poll about the removal. But it sounds like an exceptional case, it is hard to predict exceptional cases in advance. This is not even terms of service, but a technical detail about submissions. The mission should be accompanied by 800 x 600 screenshots. Or we can make them ourselves if you are OK with it. This is again purely technical, and I'm not even sure why it is needed. Isn't it how TDM works? If mapper does not override loading gui file, then default one is taken from core? Is it even worth mentioning? I think we should discuss mission updates by other people in general. This is worth mentioning so that mappers don't feel deceived. The generic rule is that we don't change missions without author's consent. But it is unclear how exactly we should try to reach the author if we need his consent. PM on TDM forums? Some email address? However, sometimes I do technical changes to ensure compatibility of missions with new versions of TDM. Especially since the new missions database has made it rather easy to do. Luckily, I'm not a mapper/artist, so I never fell an urge to replace model/texture or remap something. But still, it is gray zone. On the other hand, I think the truth is: we can remove a mission from database without anyone's consent. I hope it has never happened and will not happen, but I think this is the ultimate truth, and mentioning this sad fact might cover a lot of the other points automatically.

Yeah I'm aware of the use cases - I mainly used it for particles and preventing models from showing up through walls. The point of the thread was to reveal why it was even created, as the thread I linked contains advice from @stgatilov to NOT use it at all: https://forums.thedarkmod.com/index.php?/topic/21822-beta-testing-high-expectations/page/10/#findComment-490707 If that's the advice, an explanation is needed and the Wiki updated.

The rendering color buffer is already expanded. It is our monitors which only have 8-bit output precision normally. Unless you have some HDR monitor, which can display more with proper program support. In the reality I think there are several approaches for tonemapping: Based on modelling something Just arbitrary math or 0-1 monotonous curves which look good to you AgX belongs to p.1, it expects proper physical quantities as input in order to work properly. TDM does not belong to the world of p.1 / PBR, so we can just as well tweak some curves without any regard for physics.

Ah, in that case i wrongly assumed linear space as the input. I updated the tonemap.frag.glsl accordingly, now it converts srgb space to linear before applying AgX and i fixed the gamma conversion afterwards. It's probably not ideal going from srgb space to linear, but it seems to work well with 64bit enabled. 32bit though shows a significant loss in detail. Yeah, looks more correct that way. Not as dull and the menu doesn't appear overly soft anymore. Screenshots: tonemap.frag.glsl