Search the Community

Congrats on the release! Thanks for the great mission, I had a lot of fun. I played the mission with Linux and had no problems

And those pics that Daft Mugi posted do show the problem with TDM maps, but I also have to say, that is a problem with TDM shadow maps, not with maps in general, I never seen such ugly issues in Stalker for example or Call of Juarez and many other games. Perhaps those shadow maps issues arise from people not thinking of shadow maps at all, when creating their lights, shadow maps do require a little more tweaking to look good, specially at grazing angles, because they are literally textures, so perhaps moving the lights a little solves those problems or even increasing the shadow map res. Just think about this, if shadow maps where that ugly, the gaming industry would never deprecate stencil shadows and we would still be seeing a ton of games using them, but is totally the contrary, games with stencil shadows, are the minority, even idSoftware removed them, I think since Rage (i'm not totally sure about Rage...) and up (besides obviously Doom 3 BFG). For example: Wolfenstein II Dishonored 2 Evil within 2 (this particular shot is impossible with stencil shadows, because of the blood that is a particle effect with alpha) etc. For obvious reasons TDM fans have a good opinion of stencil shadows and I comprehend that, they do look very good, TDM and Wolfenstein 2009 are the games with the best soft stencil shadows that I haver seen, but maps can also look good, if given the chance and used to their full potencial. another game with good stencil soft shadows Thou tree shadows on this game seem to use something else or literally stencil shadows because sometimes they look like a blob on the floor instead of seeing the individual leaf.

Open questions for all. As a mere player, have you ever modified other games? Have you installed unofficial fixes, patches, updates, upgrades, expansions, mods? Were you happy it all was well documented? Were you happy that you could control what was being installed? Were you happy that it worked? Were you happy that you could install other stuff alongside without problems? Were you happy that you could uninstall it? Did you care about the authors or flame wars going on in obscure places of the internet? Players download stuff, sometimes read the instructions, install it and judge it. ---------------------------------- My friend Wesp5, Listen to the feedback. As a start, I would like to see the patch, or parts of it, in pk4 format. If you were to split your patch into standalone mods, which mods would you produce?

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.

You'll be surprised to hear but I don't quite get it either. Based on my understanding, there are a few confounding factors that make this a challenge. 1. We did a lot of work to ensure that the "included missions" were made part of the install so first time players would have a curated experience. Moving the missions back to the mission database might require undoing that work. 2. It is entirely possible to add the missions to the mission database while also being included in the installer but doing this will invite a few problems: 2a. What if the user updates the mission and then finds that their TDM install is somehow borked. They might run the installer to repair it and this will revert the mission version. If they fail to update their mission after this revert they might have incompatible save games that cause crashes and confusion 2b. What if a user starts downloading a mission update and at the same time starts a TDM upgrade ? 2c. Users opening bug tickets for a base TDM version due to problems seen in the included mission that are no longer present in the updated one, thus making it more tedious to narrow down duplicate bug submissions. 2d. Players seeing the missions on the TDM missions download page and downloading the package to install in the FMS directory then seeing duplicates in the mission list because the downloads page renames the packages with hashed filenames. All the above challenges revolve around potential user error and even though it should be obvious not to do these things, we have to compare the above to the vast swaths of folks who are begging to include TDM into Steam because unpacking a zip file and running an installer executable within a folder is "too difficult and confusing". One thing that we have the ability to do is change the file in the 2.12 installer repo so that if users run the updater it will apply the new mission. This change would not be visible to users so they would not get any alert about it. We would just have to announce it and hope that players watch for TDM announcements. I am doubtful anyone would want to work on it but I suppose that there could be some way to pass some sort of signal to the mission downloader when included missions have been changed on the installer side so they get a different update indicator. Still would be kludgy because you'd either be telling the player to exit TDM and run the installer or making TDM invoke the installer internally. So that is my take on "why" based on my own knowledge. Of course, part of my inability to "understand it" is due to my incredulity that we need to cater to players who are so below the bar in computer literacy that they would inflict these problems on themselves in the first place. None of this is an official stance just my own take on why the proposal to "let two updater processes control the same files in the same folder" has been rejected ( other than that such designs usually horrify programmers on a primordial gut level and if you mention that any program that does this you will see any programmer in vicinity instinctively reach for headache or stomach medicine ).

Excellent. This will take up my whole upcoming week, I'll take all my time off to good use testing the latest release candidate and suggest if there's really any problems. The devs are right that the beta sounds like its no longer regressed between introduced features. This is going to make my week!

Could it be anything to do with the shape of the geometry? Is a curved staircase looking at the images. Or the thickness? Thou by that image those stairs are anything but thin. Is just that I have seen thin walls leak light, while ticker ones do not and I have seen this, in more than one engine even in lightmapped ones. Also is that brush geometry or a imported triangle mesh? You will correct me if wrong but afaik the engine treats triangle mesh's, a tad differently from brush geometry, like it doesn't automatically inline the triangle mesh geometry, into the overall baked brush geometry (unless your force it), so it leaves a invisible "gap" there where the mesh connects with the brush wall? Could be floating point accuracy problems, like you recently talked about?

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!

Oops, in that last release, I accidentally didn't check character spacing in the codepoint range 128-159. And sure enough, there were problems with character 131 & 132, which needed 4 more pixels of horizontal box shifting than the 3 pixels they got earlier. So here's a better version: fontimage_24.dat of Feb 24

What do you mean by moving them around? You move them from the models folder into another folder? Models must be placed in the models folder. Otherwise, DM/DR cannot find them anymore causing the problems you mentioned in your post.

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!

Here is another update to the English Stone font's DAT file used for subtitles and some readables: fontImage_24.dat This supercedes the Jan 30th update. As agreed, now all character spacings - as given by xSkip - are preserved (from this file in TDM 2.11). Exception: the Jan 30th repair of garbage metadata for "<" and ">" remains, including xSkip repair. ASCII Characters (lower 128). The earlier Jan 30th post summaries those ASCII characters that needed metadata changes to avoid adjoining stray marks. (The detail report below updates newer reversions and minor revisions.) ANSI Characters (upper 128). An analysis was also made of the status of the Stone 28 pt font's characters in the upper codepoint range of 128-255. This could be of interest if the subtitle system was some day expanded to include European languages, and continues to use the historic codepage method. The analysis also prompted some additional DAT tweaks now. Broadly, implementation of the upper-range characters (standard or TDM-specific, as defined in the TDM wiki's I18N - Character mapping I18N) is incomplete for Stone 24 pt. The status is: 43% (55 chars) Good as is. 9% (12 chars) Good enough after DAT tweak included in this update. 6% (7 chars) Missing and shown as hollow box. 30% (38 chars) Missing accent/diacritic. 7% (9 chars) Otherwise weird. But often suggestive of glyph work started but not completed. In addition, 7 chars within categories (3-5) were "improved", but are still not good. To really solve categories (3-5) requires DSS bitmap surgery (and corresponding DAT adjustments), which is beyond the scope of planned work. DAT tweaks of ANSI characters (like with ASCII) were careful to avoid changes to xSkip. Tweaks can be further grouped by problem solved.... In category (2): - (4 chars) Char is clipped, with stray mark from adjoining character on other side. - (7 chars) Stray mark, without char clipping. As improvements in categories (3-5): - (3 chars) Stray mark, without char clipping - (4 chars) Out of valid range on top edge A categorized itemization about treatment of specific problems and characters, with further details, is here: Information about methods, including new tools, to conduct this analysis and tweaking will be forthcoming, mostly after the 2.12 release.

in case you wonder my beard was white when i hit 25 only started getting some grey streaks in my hair in the last two years hehe. and for those younger here enjoy your youth while you have it at around 40 the problems start (just look at those receeding hairlines atrocious!!!), well if the hair was my only problem i could live with it hehe i also got gall stones kidney stones and a nasty fall which broke my back in two places at around that time. So enjoy it while you can or stay away from ladders

Are you aware of the pointfile feature? Dmap writes these .lin files into the maps directory. Display them with File->Pointfile and look for red lines that visualize problems like leaks and visportal problems. Which faces of a brush are sealing depends on the material assigned to the face. I don't know exactly which ones seal and which don't.

The problem does not show up with all related dev builds. However, I cannot test with the last build (16854-10518), which I simply cannot start and get the report EDIT: As per our friend dragofer's suggestion, I made a blank script file in this build and removed the turrets from the WIP for a test. Then I can start the game and the mission and can save/load without problems. Summary: 16842-10488: no problems 16854-10518: cannot test (see above) 16854-10518 (modified scriptfile, no turrets) : no problems beta 1: problem appears

No, you are right, that was my mistake. Thank you for asking that, cause this would have caused me problems during beta testing as every AI must be on the same team in this mission. Anyway, this happens when both are on the same time (tested three times, each time the same result): https://streamable.com/0n3yqg This is much better...but far from perfect. During the second try the other guy returned, but did not assist his friend.

New script for mappers: my flavour of a fog density fading script. To add this to your FM, add the line "thread FogIntensityLoop();" to your map's void main() function (see the example in fogfade.script) and set "fog_fade" "1" on each foglight to enable script control of it. Set "fog_intensity_multiplier" on each info_location entity to change how thick the fog is in that location (practically speaking it's a multiplier for visibility distance). Lastly, "fog_fade_speed" on each foglight determines how quickly it will change its density. The speed scales with the current value of shaderParm3, using shaderParm3 = 1000 as a baseline. So i.e. if shaderParm is currently at 1/10th of 1000, then fade speed will be 1/10th as fast. Differences to Obsttorte's script: https://forums.thedarkmod.com/index.php?/topic/14394-apples-and-peaches-obsttortes-mapping-and-scripting-thread/&do=findComment&comment=310436 my script uses fog lights you created, rather than creating one for you. Obsttorte's script will delete the foglight if entering a fogfree zone and recreate it later more than one fog light can be controlled (however, no per-fog-light level of control) adding this to the map requires adding a line to your void main() script, rather than adding an info_locations_settings entity with a custom scriptobject spawnarg in my script, mappers set a multiplier of fog visibility distance (shaderParm3), while in Obsttorte's script a "fog_density" spawnarg is used as an alternative to shaderParm3 smaller and less compactly written script fogfade.scriptfogfade.map

I haven't used DR in a while, and saw that my old layout was gone. Trying to muck about and re-establish some half-assed approximation of that took a while. Problems I had: "View -> New XY View" . OK, I need an YZ view, does that cover it? Took a while to determine, yes it does, you have to use Ctl-Tab to get to alternatives. (Never used that much in the past, once I had my 3 orthogonal views). HOWEVER, with this new system, sometimes I would create the 2D view, but couldn't then direct Ctl-Tab to it. Bug? It became clear after a while that there were some places you could dock, and some not, and that the blue haze would indicate that. And that those locations might change depending on what you did before. One problem for me was I had a 2D view that I wanted to dock in the right lower corner, but it would only do a full-height docking. And after a full-height dock, there was no way to grab a corner handle to make it less than full height. I'm not asking for that feature... I just wish I had a reasonable understanding of the best way to sequence and manage the horizontal and vertical splits. So: Do update the now-obsolete section of the user manual, and ideally provide a thorough video to illustrate the new system. (Sorry, datiswous, your vid above is not it.) Hint: That unrushed video, with audio, should demonstrate how to approximate each of the old layout styles.

@MirceaKitsune - have you raised a bug report for this particular problem (searching in the wrong place if shot by an arrow)? I think I have found the cause of it and can write it up in the bug tracker. In short, I believe the intended behaviour is that the victim is supposed to search halfway between him and the shooter (presumably chosen because he shouldn't really know where the shooter really is) but the code that sets this point gets overridden shortly afterwards by code that sets the search point to his current location. It's quite instructive (if you like that sort of thing) to read up the various bugs reports on AI behaviour that have been raised down the years. In particular, bug 3331 contains a number of fixes to problems similar to those reported in this thread.

Congratulations on the release! Downloading now!

As someone who tends to alert guards often and occasionally stir trouble when going through a FM, I noticed some major issues when it comes to AI realism and awareness during combat or when guards face difficult situations. Everything's fine when AI go about their usual patrols... once trouble takes place however, the illusion falls apart as guards act like they're less self aware than a toddler. Indeed AI realism can't be improved past a certain point as there's a limit to the effort the team can put into something so complex... yet I do believe a few improvements can make AI behavior much more realistic and exciting. After analyzing this issue for a long time, I decided to put it all it into a few main points... I apologize for their length as I wanted to go in a bit of detail on each one, hope folks have the time and patience to read them. Biggest issue is AI are unaware of where attacks are coming from. I recently made another thread on how I climbed on a table and blackjacked two guards to death as they sat there doing nothing, something that also happens when shooting them with arrows as guards only explore the nearby area. The issue seems to be that AI don't account for the direction a hit comes from, they only know something hit them but act as if it must be some mystical force of nature: If you're sitting in a parking lot and an asshole neighbor throws a tomato at you from his balcony, you aren't going to cluelessly investigate the road in front of you when the projectile clearly came from behind and hit you in the back of the head, instead you'll storm into the building and start looking for which of the neighbors facing that side of the road may be the culprit. Despite voice barks existing for this exact scenario, we never see AI running to get help from other AI. NPC's will do one of two things: If armed and with enough health they will attack or search for you nearby, if hurt or unarmed flee to a random location. I've never seen an AI consciously run up to another AI asking for help and bringing them to where they spotted me, even when fleeing the AI seems to go to a random location. They don't share knowledge with each other generally speaking: The only awareness AI spread to other AI is alert level, meaning NPC A becomes alert if it sees or hears that NPC B is alert too... beyond that there's no coherence or actual cooperation, the voices may indicate some form of searching together but friendly NPC's are never seen actually engaging. Another big issue is voices being played (or not played) in disconnect with what's actually going on. There are AI voices for most important circumstances but they're very rarely activated: It's a miracle to hear a guard say "someone's been hurt" or "there's a body here" when noticing someone who's unconscious or dead. What seems to happen is if AI was already alerted by another peculiarity such as a noise, they're no longer surprised by anything else and won't play the voices designated for that scenario, so they'll only mention a body if that's the first thing to alert them in any way. Furthermore AI don't actively talk with each other while searching together, everyone acts as if they're on their own and not a team. What happens after a conflict is over. For this discussion I won't focus on better permanent alerts, that has greater difficulty implications and I think I made a separate thread on it a while back. The problem I noticed is once the immediate alert has gone down, AI return to full normality and act abnormally calm: The idle voices change from saying things like "it's a quiet night" to "we've got an intruder" but that's about it. In any realistic scenario even a trained guard would be shocked after being in a fight or finding a body. Below I'll list the immediate improvements I see to those problems, which without having an understanding the code myself am presuming can be changed without too much effort: When an enemy hits the AI with any weapon, the AI should be alert to the estimate location of the shooter. If you're standing atop a tower and fire an arrow at a guard, the guard shouldn't draw his sword and look around their nearby vicinity like a fool, but instead run up to the tower where you're standing granted they can pathfind their way to that location. If the player is far away the destination should be fuzzy and a random location nearby, thus the guard won't run to your exact location but will still climb the stairs and enter a room near it. AI need to learn how to ask for help instead of fleeing to random places when not attacking. If an ally who isn't already alert can be found nearby, the scared AI should explicitly run to their location tell them where you are then have the ally either run to your location (if armed) or go to another ally to get them to your location (if unarmed). Even if an AI is already alert, finding a body or dropped weapon or broken arrow should result in the AI speaking the voice line for that circumstance, only being engaged in combat should suppress it. I'd go further and support repeating those voice lines: A guard yelling "we have a dead body" several times during the first seconds of discovery would make them appear more shocked. Similarly talking to a nearby guard shouldn't be done just once when the two first meet: When multiple AI are searching for you, they should constantly alternate between single voice lines (eg: "I bet you're right over there in those shadows") and looking at another guard to talk to colleagues (eg: "I know I saw him here keep searching"), this would be a huge improvement since guards currently act like they're completely unaware of each other during a coordinated search. Making guards permanently affected after an incident is a trickier one but a few tweaks could improve it. The most immediate solution would be changing the idle animations: Instead of stretching or blowing their noses or eating candy, AI should be seen randomly cowering or face-palming or even playing the scout animation to look around carefully. One suggestion I'd absolutely throw here: If the AI found a dead body from an ally, have them cry occasionally... I think that would be an interesting and unexpected detail, that will also get players to think and feel more about the consequences of their actions and how they affect the world. There are other ones I could get into, but some would be more difficult and likely not worth trying to solve. Most notable and worthy of at least a mention is how AI walk over the bodies of fallen friends as if they're doormats: Obviously there's no way to have them drag bodies to the side, but maybe an avoidance mechanism so they don't look like jackasses trying to profane their dead friends by literally stepping all over them could be a fix for that as well! Let me know what you think of those points and if there are other AI issues you've noticed yourself or better solutions you can think of: I'm not sure if I got everything here but I definitely believe the problems exist and we could make the world more natural and immersive with some simple fixes.

Here's my first FM. A small and easy mission, inspired by Thief's Den and The Bakery Job, where you must find and steal a cook's recipe book in order to save a friend from going out of business. Download: Mediafire (sk_cooks.pk4) TDM Website's Mission Page The in-game mission downloader Thanks to: The people who helped me get this far, both in the forums and on Discord. The beta testers: MirceaKitsune, Mat99, Baal, wesp5, Cambridge Spy, jaxa, grodenglaive, Acolytesix ( Per the author in the beta testing thread. ) Skaruts has given permission to the TDM Team to add Subtitles or Localization Strings to this mission. (No EFX Reverb.) If anyone from the Community or TDM team wishes to create these we will gladly test them and update the mission database.

damn btw dont do this if you have problems with the current avaliable nvidia driver 435 since it is broken in some games. So obviously i tried the beta version... well now i can reinstall

With TDM 2.12, after the credits finished, the "Mission Complete" screen did not display. I found that the screen was black and I could hear my footsteps when I tried to move around. I think the reason for the mission not completing successfully was that the "Do not kill or harm allies" objective was never marked as "1 = STATE_COMPLETE" instead it was left as "0 = STATE_INCOMPLETE". Note, I didn't use noclip throughout the mission. Same as: https://forums.thedarkmod.com/index.php?/topic/18054-fan-mission-the-accountant-2-new-in-town-by-goldwell-20160509/&do=findComment&comment=458491