Search the Community

I noted this in the other thread, but let me quote myself here as well: I've updated the "displayed text" section of the wiki's Subtitles to include this and other stuff.

Thank you for a great puzzle fm! I'm having real trouble with the TDM v 2.10-64bit on Linux Mint 21.1 Link to the guide supplied by V-Man339 https://forums.thedarkmod.com/index.php?/topic/15844-fan-mission-the-gatehouse-by-bikerdude-goldchocobo-updated-02112014/page/7/#comment-429405

In the long run, figuring out a way to add font attributes (e.g., color, bold, underline, italics) would be great for subtitles and throughout TDM. Hard, tho. I guess fontsize markup is an attribute that might be most easily conceived at the moment. But I don't know if TDM has any underlying support for interleaved mixed-size characters. Turning to a potentially easier issue, on the "Barks" thread, @datiswous noted... I responded: datiswous: Geep: I agree.... Related: I'll probably do some more experiments with the current TDM font & size, to understand max char count versus field width.

I agree. I'm copying this idea over to the https://forums.thedarkmod.com/index.php?/topic/21741-subtitles-possibilities-beyond-211/ thread. Related: I'll probably do some more experiments with the current TDM font & size, to understand max char count versus field width.

Why is map_of_icon replaced with map_of in core? This breaks it in many missions I think. If mappers can't trust core files to stay the same then they will keep overriding them. Edit: Sorry maybe I should have posted in the original thread.

An easy way to fix this should be providing the tga under both names. Right now I can't even find it, because it's not in the gui archive where it should be, or is this not really part of the core game? In that case maybe it should be added...

Some years ago i succesfully downloaded the wiki with wget, for TDM dvd. I dont know if this method wikl work now. https://forums.thedarkmod.com/index.php?/topic/19998-tdm-collection-dvd/#comment-437887

Appears all the links in that thread are dead and gone. I don't think Tels is around anymore either.

Some of the loot is in secrets, but not all of it. In the first post of this thread I gave hints for the secrets. Also, a good chunk of the loot is related to one of the mission objectives, which should lead to solving your other problem. Hint:

1.5 GHz just isn't enough to get any good single-thread performance and games still need that even when they sortof are multithreaded today. But still kudos to them building their own CPU and it probably more than good enough for powering the offices needed to keep critical infrastructure working. Thanks for sharing.

@datiswous, made that correction fm_test.subs --> fm_conversations.subs @stgatilov, about srt naming and file location, would you be OK with the following edit? New/changed stuff in italics: srt command is followed by paths to a sound sample and its .srt file, typically with matching filenames. An .srt file is usually placed either with its sound file or in a "subtitles" folder. The .srt file format is described e.g. [1]. The file must be in engine-native encoding (internationalization is not supported yet anyway) and have no BOM mark. It contains a sequence of text messages to show during the sound sample, each with start and end timestamps within the sample's timeline. It is recommended to use common software to create .srt files for sound samples, instead of writing them manually. This way is more flexible but more complicated, and it is only necessary for long sounds, for instance sound sample of a briefing video. It's a simple enough standard that it can be shown as an short example, demonstrating that subtitle segments can have time gaps between them. And the example can show correct TDM usage, without requiring a trip off-site and picking through features that TDM doesn't support. Specifically, the example shows how to define two lines by direct entry, rather than using unsupported message location tags (X1, Y1, etc.). And skips other unavailable SRT font markups like italics, mentioned in the wikipedia description. The example would also show the TDM-specific path treatment. The example could be inserted before the sentence "It is recommended to use common software...."

Hmm.... then I must have misunderstood it. Thought the only change is the animation/indication. Still seems pretty finicky though. Edit: After reading a few pages of the linked thread, I must admit that I still don't fully understand what the changes are. Sounds like Obsttorte wanted to change the way the blackjack works directionally (i.e. that blackjacking from the front doesn't work anymore), but, it seems like some other members intervened and argued that the rules should not be changed, so, I'm puzzled about what has actually changed, apart from the indicator animation. From playing, I would say that the changes, if any, are very subtle.

I guess the best image-to-normal conversions I've seen here in the forums are via njob. I am curious about this AI thing though: https://github.com/HugoTini/DeepBump has to be installed into Blender as a plugin?

Still a bit curious, I wonder if the texture is somehow inheriting from another material in one or more of the stages ( all it would take is one of our other core materials defining a mirror or cubemap as a template image with the same name as the target DDS in the affected texture ). @AluminumHaste please post the results for r_showSurfaceInfo 1 to the thread. Thank you!

Mission: "The Elixir" Reading: Lady Barrington's Diary I checked the mission thread, and nobody else seems to have issues. 2.11 Well, now I found a thread already existed. I can't find a way to erase my topic, so please do so freely. Looks like a hopeless bug. Luckily it is rare.

Now that The Dark Mod 2.11 is out, please share any thoughts, issues, or well-wishes here. Thank you!

Just read this whole thread, and here is what I learnt: Player can carry body up ropes, vines, and ladders. All of them are quite situational, but still it shows that it was never planned to restrict possibility of lifting a body up. Of course, we are not going to change this behavior. Mantling with a body: I think everyone is OK with allowing about waist-level mantle with a body. If you can put body down on a table and mantle on it, then it's surely safe to allow mantling with a body, although I wouldn't keep this 100% strict and minor bump in this height should be OK. Throwing body from rope: I'd say I'm OK with that. I personally hate that the game does not allow me to throw a body where I want. Fall damage: I think it is very hard to balance this, since it depends much on physics, and that is today also frame-dependent. In case of unconscious body it depends on ragdoll physics, which is very hard to control. How high player can fall without damange/dying should be more or less fixed, but as for body... I'm eager only to fix major issues, like "falling from any height does not induce damage".

I'm not noticing the blackjack helper animation anymore. I tried using "tdm_blackjack_indicate 1" and didn't notice a difference. Is it working for anyone else? Also, the following is in the console log. WARNING:tdm_base01.pk4/script/tdm_weapon_blackjack.script(90): Thread 'thread_701': missing 'ready' animation on 'player1_weapon' (*unknown*) WARNING:tdm_base01.pk4/script/tdm_weapon_blackjack.script(104): Thread 'thread_701': missing 'unready' animation on 'player1_weapon' (*unknown*)

DarkRadiant 3.8.0 is ready for download. What's new: Feature: Support new frob-related material keywords Improvement: Mission selection list in Game setup is not alphabetically sorted Improvement: Better distinction between inherited and regular spawnargs Improvement: Silence sound shader button Improvement: Add Reload Definitions button to Model Chooser Fixed: Model Selector widgets are cut off and flicker constantly on Linux Fixed: DarkRadiant will not start without Dark Mod plugins Fixed: GenericEntityNode not calculating the direction correctly with "editor_rotatable" Fixed: RenderableArrow not drawing the tip correctly for arbitrary rotations Fixed: Light Inspector crashes on Linux Fixed: Models glitch out when filtering then showing them Fixed: Skin Editor: models not centered well in preview Fixed: "Copy Resource Path" includes top level folders Fixed: Skin Editor: internal test skins are shown if Material Editor was open previously Fixed: Changing Game/Project doesn't update loaded assets correctly Fixed: Model Chooser: initially hidden materials aren't revealed when enabling them Fixed: Choosing AI entity class 'atdm:townsfolk_commoner_update' causes crash Fixed: Sporadic assertion failure on shutdown due to LocalBitmapArtProvider destruction Fixed: Prefab Selector spams infinite error dialogs on Linux Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.8.0 and of course linked from the website https://www.darkradiant.net Thanks to all the awesome people who keep using DarkRadiant to create Fan Missions - they are the main reason for me to keep going. Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. The list of changes can be found on the our bugtracker changelog. Keep on mapping!

TTLG? That's Through the Looking Glass Forums. A looking glass fan community. Has been around for a long, long time. https://www.ttlg.com/forums/

No, not really, have only seen him on the forums many years ago. He deserves a lot of credit for providing the SVN infrastructure in the beginnings of the project, it's been only later when we transferred this to a hosted server. Memory is blurry, but I think my time working on TDM and his don't overlap that much - I had been getting more active, and he pulled back a bit. He bootstrapped quite a few important systems, IIRC he's been working on light gem and the first Stim/Response and Inventory implementations. From what I recall, he gave the project an organisational backbone in the technical department which is crucial to keep things together. Folks like Spring and NH who have joined long before me could give more insights, I guess. (Looking at my join date makes me feel old either way. From TDM's current view point, the year 2006 seems like right at the beginning, but actually the mod had already been existing for two years by that time I joined. With the first release in 2009, 2006 is rather in the middle. Heck, I haven't touched the mod code for at least 10 years - and I can still remember a few things, which is a testament of how much it occupied my thoughts back then).

Last night we chatted on Discord about Vulkan support and PBR, bringing up a system for adding proper reflections once more. I suggested screenspace reflections but it was argued reflection probes would still be better than SSR in our case, a ticket for that is already open but I'm uncertain whether it's the best way: A manual approach would need new entities to be placed by the mapper... this requires extra effort and would exclude old FM's that are no longer updated, while the result will also be inaccurate and static meaning you won't see an AI reflected as they walk on a shiny metal plate for instance. If PBR with realistic graphics can be a hope for 2.12 or later, we'll definitely want to do it right rather than using a limited / limiting system. A technique came to mind that might just work for our engine and setup. I wanted to share it here before I forget the specifics; This might already be a common practice and even have a definition, for the purpose of this thread I'll just describe it as I originally imagined it and feel this would work for our engine. The idea is we'd use reflection probes but in an automated fashion: A probe is automatically spawned in every valid area (within bounds) in the player's view, at a given grid unit size. For example: If the grid scale is 16, a probe may exist at position '0 -48 16' another at ''0 -48 32' and so on. Every point projects its result on all surfaces in its radius which contain a specular channel masking it, the best alternative presently available till we were to convert all textures for PBR support. The cool thing is the same cubemap can also be projected as a light source, allow for global illumination in addition to just reflections! This would be similar to how the Irradiance Volume works in Blender / Eevee except each dot renders a little cubemap from its perspective. I already know what everyone is rightfully thinking: This is going to kill performance! After all each probe needs to produce a render from its perspective, and being a 360* panorama it will open portals in all directions. Normally that would be insane, but I thought of various ways in which the impact could be greatly minimized to very bearable amounts. The frame buffer of each probe will be at a very small resolution by default since much detail shouldn't be needed. Even 64x64 per cube face might do. Each probe only needs a draw distance double its grid size, given it only has to see as much as is necessary to fill the gaps between it and its neighbors. So if the grid size is set to 64, each probe would only have a draw distance of 128 to cover the space in between its neighbors, nothing beyond that would exist to it. Only probes the player can see would ever be spawned and calculated; If the view frustum doesn't overlap the virtual cube who's corners touch that probe's neighbors, the probe is dropped from memory. Probes are also only spawned in a valid visible space, never out of bounds including rooms culled by portals. A draw distance after which probes are removed or not spawned can also be included. This would further help by making any probe further than X distance be ignored, slowly fading away as to not noticeably pop in and out of existence. Reflections / GI are a discrete effect you'll only see up close. Similar to lights and shadows, the result of a probe should be cached and not calculated unless necessary. This means that unless something moves within radius of that probe its cubemap won't be rendered again. Probes would only be updated either when they first come into the player's view, or if something touching their cube has moved. Note that particles and lights with animated textures would have to count as you may see them in a detailed reflection, candles and torches would force constant updates per-frame for probes they intersect. If with all that performance is still affected, frame skipping is also a solution: Reflection probes can update at a lower frame rate to further decrease their impact. If you have a 60 Hz monitor and are running TDM at 60 FPS max, reflections could run at 30 / 20 / 10 FPS without looking out of place. They could in fact be defined as a fraction of your average framerate, so for the FPS you get you can decide whether it's going to be 1/2 or 1/4 or so on of that... this would have the added advantage of exponentially gaining back FPS the lower your FPS goes. There are several reasons why I believe this would be better than mappers manually placing new probe entities: Extra work is required for the mapper, who needs to figure out how to cover each area in probe lights. Every piece of the map would need to be encompassed in a reflection / GI probe otherwise you won't get shiny surfaces or bounce lighting which will look out of place. Most existing FM's will never be updated to use this: Only maps created or updated after the feature is introduced would benefit, anyone playing old missions will get boring visuals without reflections / GI which will be inconsistent to new ones. I strongly believe this should be done as an universal effect like SSAO. Single large probes will produce inaccurate results; The larger a cubemap is, the more drift and a fake results you get with distance from its center. This can be mitigated by using parallax corrected cubemaps which should be used for automated cubemaps too... none the less you get a single point of vision for a large room which makes the result inaccurate the further you go... with an automated approach you could have many probes in a dense grid (if your hardware allows it) for a much more accurate result at any position and angle. What are your thoughts on this solution, do you think it's realistic and can work out? I do believe it should be either this or screenspace reflections the way they're done in Godot or Blender / Eevee. If SSR isn't the right choice for our engine, reflections and global illumination alike could be captured using a global grid of capture points shining within their respective areas.

Check the actual damage amount in the screenshot. It's almost 40 000. Edit: also, bodies dropped from that height fall flat. I haven't tried the max possible height yet, maybe the ragdoll does kick in after a certain point. Perhaps the whole thing should have a separate thread

There are other complications though. How much fall damage should player take, if they decide to jump off a rope with the body? Should the player let go of the body or not? Also, right now it's much harder to jump off the rope with the body than without it. Why? And last but not least, how would you teach players these things, possibly without much hand-holding and text prompts explaining the rules? I guess I'm with @STiFUon this one, if you restrict dropping the body, you'll save yourself (and mappers) a lot of headaches. But even that doesn't solve all the problems, I know I'm in the minority in these forums, but as a player, I really appreciate the beauty and efficiency in simplicity of the design. Not overthinking everything and adding more and more rules for the sake of realism (or anything else).

Mods said it'll stay open for 24 hrs. I'm on a later schedule in US central time, so I only just now am catching up on the AMA. I'll be sitting in and watching the thread for the rest of the day. I guess this is why we share a dev team that spans multiple continents.