Search the Community

Okay... I'll be honest... I did not expect that cutscene. I was slightly frustrated by this mission/map, due to skill issue =P but that touch of felt like a reward. I do have a question - what are those golden things actually? Like the one near the clothes iron above girl's room looked like a press or a stamp. That's a big stamp =D

I think yes. The root of the issue is always an opaque wall (in terms of areas/visportals) which does not cast shadows (in terms of lighting). Shadowcaulk is both opaque and casts shadows, so there is no contradiction.

@snatcher I understand that when you feel your work doesn't live up to your goals that you don't want it out in the wild advertising your own perceived shortcomings but that leads to a troubling dilemma of authors who are never satisfied with their work offering fleeting access to their in-progress designs then rescinding them or allowing them to be lost. When I was a member of Doom3world forums, I would often see members do interesting experiments and sometimes that work would languish until someone new would examine it and pickup the torch. This seemed like a perfectly viable system until Doom3world was killed by spambots and countless projects and conceptual works were lost. I guess what I am trying to say is that mods don't need to be perfect to be valuable. If they contain some grain of a useable feature they might be adapted by mission authors in custom scenarios. They might offer instructive details that others trying to achieve the same results can examine. It would be great if known compelling works were kept somewhere safe other than via forum attachments and temporary file sharing sites. I suppose we used to collect such things in our internal SVN for safe keeping but even that isn't always viable. If folks would rather not post beta or incomplete mods to TDM's Moddb page, perhaps they would consider creating their own Moddb page or allow them to be added to my page for safe keeping. Please don't look at this as some sort of pressure campaign or anything. I fully understand anyone not willing to put their name next to something they aren't fully happy with. As a general proviso, ( if possible \ permitted ) I just want to prevent the loss of some valuable investigations and formative works. The end of Doom3world was a digital apocalypse similar to the death of photobucket. It is one of my greatest fears that TDM will become a digital memory with only the skeletons of old forum threads at the wayback archive site.

Congrats on the release! Remember to check ThiefGuild as well as the DarkFate forums (via Google Translate) for additional feedback.

I may know why the builders and guards suddenly go all aggro, and it has nothing to do with a window. If you wait long enough, eventually Malachi gets killed by the elevator and they don't think it was because they elevator lacks safety features. I did a playthrough and Malachi was killed by the elevator but I had knocked out all the other roving builders that would have seen him. After I finished, I went in and set up on the table by the elevator that had a candlestick on it. Eventually old Malachi got chewed by the elevator and they all alerted. Sometimes other people get killed on the elevator at that point and sometimes it says I failed the don't kill anybody objective and sometimes it doesn't. Don't know if it'll happen every time. My first attempt either I didn't wait long enough or it may be some triggers need to happen. The second time I still waited quite a while but Malachi eventually died on the elevator again. So if that isn't intentional, that may be what starts the issue.

Another issue I ran into which I remember from playing the mission way back: you can basically softlock yourself here if you jump onto the boulders as they float up. You get stuck in them and can't jump anymore. Edit: if you just stay on one of these boulders for too long, you get stuck too.

Losing the option for stencil shadows would be extremely sad. TDM has the best stencil shadows implementation I've ever seen, and they look far better than shadow maps. They also perform wonderfully. Stencil shadows not supporting shadows on translucent surfaces is a bummer, but that's a fine tradeoff. Personally, I'd rather not see alpha-tested shadow occluders, because they look awful and are distracting. Shadow maps in general look bad and pixelated -- quite immersion breaking. Another issue with shadow maps is that they substantially increase the usage of the GPU. For those using laptops or integrated GPUs, it could cause performance or heat issues. For those with decent dedicated GPUs, increased wattage (and therefore heat) can and does turn on its GPU fans. The wattage on my AMD RX 6700 XT can become tripled when using shadow maps. That's undesirable. The advice I give players is: There really isn't a "best" shadows implementation these days. Some devs and players prefer one over the other. Regardless of which is chosen, stencil shadows and maps are used where needed. So, I'd try out both and pick the one you prefer. Here's Fen complaining about shadow maps. Complaint #1 (7:28): Complaint #2 (23:46): In his next video (Written in Stone - 4 - Chocolate Coated Brendel Bar), he turned on stencil shadows, and as far as I know, he never complained again. The following area in Written in Stone shows a good example of alpha-tested shadow occluders. Yes, technically the moving leaves cast shadows, but it looks awful in game, in my opinion. I know others like it. The same scene using stencil shadows looks amazing in game. (The screenshots don't do a good job demonstrating how it looks in game.) The current hybrid system is fantastic. It gives people choice. Those who prefer stencil shadows can use them; those who prefer shadow maps can use them. People become attached to the "art" and "style" of a mission, and changing the shadow implementation changes the art and style. If one must be dropped, I'd say shadow maps should be dropped from the menu settings. Use shadow maps for volumetric lights and stencil shadows everywhere else. And, I agree with nbohr1more that defaulting to rules consistent with stencil shadows is a good idea.

As everyone know, right now we have both stencil shadows and shadow maps in the engine, and the player is mostly free to choose whichever he likes more. Due to the reasons I provide below, stencil shadows will most likely be dropped in some future, but that future is definitely not here yet. Unlike shadow maps, stencil shadows do not support: Alpha-tested shadow occluders. Shadows on translucent surfaces. Volumetric lights with account for shadows. Soft shadows with contact hardening. Point 4 can be ignored, point 3 has an automatic workaround by forcing lights with volumetrics to shadow maps. Points 1 and 2 result in major difference in behavior between the two modes. For the reference, we have one more technical difference: Front faces cast shadows in shadow maps mode, but don't cast them in stencil shadows mode. I recall how initially volumetric lights had their shadows disabled in stencil shadows mode, and mappers were not happy because that's a big difference in behavior. One issue was that every mission has to be beta-tested in both modes. That's why right now I mostly follow the same strategy: Alpha-testing is disabled when rendering shadow maps (since 2.12), unless you enable r_shadowMapAlphaTested. Shadows are disabled on translucent objects (since today's 2.13 dev build), unless you enable r_shadowMapOnTranslucent. I wonder if this is still what majority of the mappers think is best?

I like how this has essentially become a Linux thread despite it not being the intended focus. I play around with Ubuntu MATE because I like Ubuntu and the MATE variant has an environment I prefer with a bunch of changes I like, a good compromise between old and new. That said, TDM behaves a bit oddly in Linux. For some reason in TDM it misses the occasional mouse click - if I happen to click fast enough there's a chance the event won't register. It seems to be something inherent to the Doom 3 engine in Linux - even in dhewm3, if I make a really fast click on the mouse it can sometimes ignore that mouse event and not fire the weapon. Generally you have to be really quick on the down/up event for it to happen, but it happens, it's reproducible and I can't just accept having to consciously be aware of my mouse behaviour and remembering to click long enough to guarantee the event is registered. I'm sure many won't notice this issue, but I'm pretty fussy about such things so it annoys me. This doesn't happen on anything else in Linux, just Doom3/TDM. Not surprisingly Windows doesn't have this issue, and it's a good example of the reasons why I don't bother moving entirely to Linux. I can't stand odd quirks like this and there's odd quirks EVERYWHERE in Linux. There's quirks aplenty in Windows too of course, but I'm used to them.

I spend 90% of my time on Linux Mint. I occasionally pop over to Windows 10 to check a few things or run some updates but Linux Mint is my home. TDM runs better under Mint than Windows for me but your mileage may vary. When running TDM in Linux, you must set FPS to "Uncapped Mode" in the Advanced settings, the old capped mode has terrible stuttering and performance under Linux ( even native Doom 3 has this issue ). You can set Max FPS to 60 if you are worried about any inconsistencies with game timing ( the only known issues are rare problems with audio behavior at really high FPS). Just don't use the native 60FPS capped mode, use Uncapped mode with a Max FPS value.

Changelog of 2.13 development: dev17042-10732 * Restored ability to create cvars dynamically, fixing bow in missions (5600). * Fixed issue where .cfg files were saved every frame (5600). * Added sys.getcvarf script event for getting float value of cvar (6530). * Extracted most of constants from weapon scripts into cvars (6530). dev17035-10724 * Support passing information between game and briefing/debriefing GUI via persistent info. Also changed start map & location selection, added on_mission_complete script callback (6509 thread). * New bumpmapped environment mapping is now default (6354). * New behavior of zero sound spawnarg is not default (6346). * Added sound for "charge post" model (6527). * Major refactoring of cvars system to simplify future changes (5600). Known issues: * Bow does not shoot in some missions (only in this dev build): thread dev17026-10712 * Nested subviews (mirrors, remotes, sky, etc.) now work properly (6434). * Added GUI debriefing state on mission success (6509 thread). * Sound argument override with zero now works properly under cvar (6346 thread). * Environment mapping is same on bumpy and non-bumpy surfaces under cvar (6354 thread). * Default console font size reduced to 5, added lower bound depending on resolution. * Added high-quality versions of panel_carved_rectangles (6515). * Added proper normal map for stainglass_saint_03 (6521). * Fixed DestroyDelay warning when closing objectives. * Fixed the only remaining non-threadsafe cvar (5600). * Minor optimization of depth shader. * Added cm_allocator debug cvar (6505). * Fixed r_lockView when compass is enabled. dev17008-10685 * Enabled shadow features specific to maps implementation (poll). * Auto-detect number of parallel threads to use in jobs system (6503). * Improved parallel images loading, parallelized sounds loading, optimized EAS (6503). * Major improvements in mission loading progress bar (6503). * Core missions are now stored uncompressed in assets SVN (6498). * Deleted a lot of old rendering code under useNewRenderPasses + some cleanup (6271). dev16996-10665 * Environment mapping supports texcoord transforms on bumpmap (6500). * Fully disabled shadows on translucent objects (6490). * Fixed dmap making almost axis-aligned visportals buggy (6480). * com_maxFps no longer quantizes by milliseconds on Windows 8+. * Now Uncapped FPS and Vsync are ON by default. * Supported Vsync control on Linux. * Added set of prototype materials (thread). * Fixes to Stone font to remove stray pixels (post). * Loot candlestick no longer toggle the candle when taken. * Optimized volumetric lights and shadows in the new Training Mission (4352). * Fixed frob_light_holder_toggle_light on entities with both skin_lit and skin_unlit. * Now combination lock supports non-door entities by activating them. * Added low-poly version of hedge model (6481). * Added tiling version of distant_cityscape_01 texture (6487). * Added missing editor image for geometric02_red_end_HD (6492). * Added building_facades/city_district decal material. * Fixed rendering with "r_useScissor 0" (6349). * Added r_lockView debug rendering cvar (thread). * Fixed regression in polygon trace model (5887). * Added a set of lampion light entityDefs.

Some changes were made to the training mission, but this process began while 2.12 was already in beta testing, and it became too extensive. To my knowledge this mainly consisted of adjustments to the messages in order to match the new 2.12 control scheme, addition of a vine arrow training area, some minor gameplay changes as well as major visual changes. A last minute major issue caused the mission to be reverted to its 2.11 state except for the adjustments to the popup messages. The training mission is slated to undergo proper beta testing of its own later on.

I took a quick look at the training mission and I didn't notice many changes in the first place. Some new windows on walls that didn't have them, but was something gameplay related changed? I found there are still a lot of unique items missing in the object handling section which I added in my patch for example. The main issue I have with the TDM training mission hasn't been tackled, namely that it isn't a mission at all, just a loose collection of tutorial areas. Which is fine when you want come back and re-train something, but bad if you want new players to have fun discovering TDM! Yes, the two campaign missions try to do the latter, but in other games the training/tutorial is done much better in a linear fashion (e.g. Half-Life and Opposing Force) or is even integrated in a story (Bloodlines and many others). It would probably be a lot of work, but maybe it would be possible to modify the training mission, so it represents a linear sequence in which you learn one basic principle after another while actually playing a mission that is has a story and is fun! If you really think people are going to replay it, maybe shortcuts could be added to the single areas. Right now all areas start from a central room, maybe they could be connected so that there is one way where you enter a door and go around the whole room to exit at the end? (If people agree, that the training mission should be changed, maybe we should open a new thread for this discussion.)

Fun mission, took me around an hour to do. Multiple points of entry was really nice! Only issue I had was But otherwise, great first mission!

So I thought whether to mention this here, in the end I guess it makes sense as it's now technically a bug report. The discussion started out as a feature request, or rather a set of them... then it was mentioned that one of the functionalities I described should in fact exist, but an error is causing it to be overridden. We aren't sure when it was introduced but since I've always observed the broken behavior it might be years. You can read the full conversation here: https://bugs.thedarkmod.com/view.php?id=6436 What I observed and initially requested: When the player shoots at an AI, the AI shouldn't go searching in a completely random direction, and instead go somewhere toward the player as they should have a general sense of where the arrow came from. Currently guards completely ignore the direction of an attack and will cluelessly run to a completely random spot when hit which is very unrealistic: If an arrow hits you in the back, you aren't going to sprint forward looking for the perpetrator there. How this turned into a bug report: Someone investigated the issue and discovered that when attacked, AI should in fact be picking a search area between their own position and that of the players. I understand the pain event mistakenly overrides that decision, causing the guard to pick random locations within their own radius when attacked. Now that this is known, maybe this can be fixed in time for 2.12 so we aren't stuck with the broken behavior for the whole release?

Issue confirmed. It looks like the shadow count in that scene has grown from 2K to over 15K. It is being investigated.

Thanks! Looks like a map change rather than an engine issue. To verify further can you test beta 5 or newer with uncapped FPS set to max 300 in the advanced menu?

Welcome to the forums Ansome! And congrats on making it to beta phase!

"...to a robber whose soul is in his profession, there is a lure about a very old and feeble man who pays for his few necessities with Spanish gold." Good day, TDM community! I'm Ansome, a long-time forums lurker, and I'm here to recruit beta testers for my first FM: "The Terrible Old Man", based on H.P. Lovecraft's short story of the same name. This is a short (30-45 minute), story-driven FM with plenty of readables and a gloomy atmosphere. Do keep in mind that this is a more linear FM than you may be used to as it was deemed necessary for the purposes of the story's pacing. Regardless, the player does still have a degree of freedom in tackling challenges in the latter half of the FM. If this sounds interesting to you, please head over to the beta testing thread I will be posting shortly. Thank you!

Update: @JackFarmer The root cause of the turret crash has been found. It seems that it was given the same physics code as the security camera but does not have handling for cases where no clip model exists. Removing the physics code fixes the issue. That said, I guess we may look into adding it back so that the turret follows the same destruction features as the camera?

Hi, I'm messing around with patches to see what can be done with them, and I have a couple of questions. None are critical issues, as a matter of fact, I doubt I'd notice them or cared if I were playing someone else's map, but as I'm learning, knowing what can't be done is sometimes as important as what can be done. Here's the thing: is it possible to bevel a surface not parallel to one of the orthogonal axes, in other words, a slanted bevel? To be more specific: I'm having problems with snapping it to the grid; it doesn't want to. I mean, I have done the bevel, and it looks nice from a distance, but the slanted surface refuses to snap to the grid, which causes a visible, although small, seam (or at least I assume that's the reason.) And projecting the texture is also a bit of pain. Let's see if I can attach a picture... OK... [a few/lots of minutes later] messing around with it one side now looks much better (almost imperceptible seam, tbh,) but the other side still looks off. I still can't snap to the grid the four corners (interestingly, it's the main brush, the frustum, the one that refuses, not the bevel, which is perfectly snapped). I can snap three of the four corners, but there is always one that shifts on its own will, even when using the smallest grid. See the next two pictures, where I have the main brush and the patch selected; the dots overlap except that one. And if I snap that one, another will shift (clockwise? I think.) I mean, that's like... what, 1/3 of 1/8 of a Doom Unit? 1mm? Not game-breaking, really, and nothing that can't be hidden with some trim or just in shadows, but I wonder if there's a technique for this or what I did wrong. [Hmmm, after some thinking, I wonder if my issue was creating the original cube on grid X and then cutting the triangular corner for the bevel on a different grid size so the corners were weirdly placed... I'd have to test that out] And speaking of seams, is it possible to make a smooth texture transition from the surface of a cylinder (or ring or whatever) to its cap? See the third picture, which is the rounded base of a column. If it's not (or it takes a lot of effort or editing), then it's no big deal, as there are more important things to worry about. But if there's a quick & easy way (natural projection hasn't worked for me in this instance), it would be good to know. Thanks!

This is being investigated. 2.12 has the needed save state features so the cause is still unclear. If the problem cannot be solved in a reasonable time-frame, we may need to revert to 2.11 turret features and suggest completing any needed additions via local changes to your mission (... pretty unlikely, as we are highly motivated to retain the 2.12 turret improvements). However this gets resolved, it is the last blocker issue for 2.12 to leave beta phase.

Excellent mission(s). I ran into the infinite loop bug when Not exactly a bug, but I did have the issue with the innkeeper going in and out of his room repeatedly like a cat with thumbs. I just learned about TDM a couple months ago (Best Christmas Gift Ever) and have been playing the missions oldest first with some exceptions for series. While most are pretty good and some are exceptional, you're the first to come up with a gimmick to get me to replay a mission.

Something I was thinking of: Even if some assets are non-commercial, are all assets at least accounted for to make sure they're credited accordingly and can be distributed? I ask following an issue in another great project I work with called Red Eclipse: They don't have NC assets but did have a few texture packages they had to remove because they later found out their clauses were incompatible with the project. If this hasn't happened in well over a decade it's very unlikely anyone would complain today and request removal for any reason, but if any resource had its license misunderstood that could destroy existing FM's unless perfect replacements were found. Obviously I presume the team never included any asset randomly found on the internet without verifying their explicit requirements in detail, but it doesn't hurt to check. I think the best that can be done otherwise would be to have a list of which assets are libre or have the NC clause: That way a map can choose to use those models and textures that are free if the author wants their FM to be fully libre, albeit this would handicap an author in what packages they can use. If core assets like character models or textures are also NC, the idea is likely pointless as you can't make a FM without those, at best you can skip a few texture packages... not sure about other things like core scripts or defs, since they're technically code I presume those are GPL?

Making a note: During the 2.04 development cycle: Source Revision 6550 Assets 14407 the door on the balcony became nonsolid for the player It was still working on Assets 14406 and Source 6544. 6544 was introduced at 14404 and no other binaries were added between. 14407 only added binaries ( compared to 14406 ) so this was not an asset \ def issue. Edit: During the 2.04 dev era ( 2015 to 2016 ) we still compiled game dll's. The breaking change happened in Rev 6551 ( the tdm console only renders to binary revision ) Changes: https://github.com/stgatilov/darkmod_src/commit/3f6f6f62bbba029bbcfec271ef08cac68fbfc2e4 @stgatilov I don't see any problem areas in this commit. Can you confirm?