Search the Community

For the FM? For beta 1 it's here: https://drive.proton.me/urls/H1QBB04GA0#oBZTb1CmVFQb I've already done around 100 fixes though, so you might want to wait for beta 2 which should be ready in a couple of days hopefully. All links are in the first post of the beta thread here: https://forums.thedarkmod.com/index.php?/topic/22439-the-lieutenant-3-foreign-affairs-beta-testing/

So, that's how it was explained to me. Even though it seems counter intuitive, using Direct X maps has worked for me. I was recently trying to import a bunch of textures from Polyhaven.com (they offer both OpenGL and directX normalmaps) and I used the OpenGL version at first, but when I put it in-game there was an inverted green channel. I then used the directX version and the normalmap worked just fine I'm happy to be corrected on any of this though. Maybe Polyhaven does something different with their normals, or I'm doing something wrong

Is that really correct? Unless TDM team changed stuff from Doom 3 times, if you use Doom 3 as example, normal maps that represent outward surfaces, use OpenGL system, those that represent inward surfaces, aka holes, use D3D system. On real DirectX renders, outward surfaces, use the D3D system instead and the OGL one for inward, is inverted. And to reinforce this the original example by idSoftware, looks to use the OpenGL system see here cyan for top, purple for the bottom, in d3d is inverted. Thou like I said maybe the TDM team changed all of this by now... edit: Incorrect info so ignore it any mod is free to delete this if he/she wants.

I think this is a slippery slope fallacy. Just because the ability to customize exists does not mean most mappers will use it. On the contrary, if one considers the customization that are already available, we see that the overwhelming majority of mappers stick to the defaults. The exceptions are interesting also. Kingsal's the only mapper that readily comes to mind who habitually deviates from presets seemingly just for the sake of being different. However everything they make is clearly in service of cohesive visions. Hazard Pay, no matter how you feel about it, unarguably loses a great deal of its survival horror character if you take away the napalm arrows or the punishing save system. The Voltas don't need to use Thief style elemental crystals in place of TDMs arrow model, but the fact that they are there makes a definite statement about the author's awareness of their inspiration for their work in TDM from the original games, which in turn draws attention to other, subtler creative choices. I think it's also telling that some of kingsal's modifications have been adopted by other authors. As OrbWeaver said, "If the defaults are widely disliked, they should be changed." However, how can the community come to a consensus unless there are maps to showcase the advantages of new innovations? Requesting, or worse requiring, players to go in and manually change settings in order to experience a new mechanic is never going to gain any traction. Certainly it is not worth the effort of creating an entire map built around a new paradigm.

"May his iron mold the current as we were molded. May his instrument expel all obstruction as we are his instruments." - Collected Sermons of Master Plumber Roto Rooter Few would dare cross the Bridgeport Plumber's Guild. Fewer still could glimpse their secrets and live. CC0 POLYHAVEN PLUMBER PACK BETA Includes: Fully modular pipe kit with optimized shadow mesh, two skin variations and near perfect grid snapping at grid level 4 Moveable plunger prop which is fully compatible with the AI weapon system Worry free CC0 license All credit to the great polyhaven.com for the original mid poly meshes - consider supporting them on patreon. I just decimated and then rebaked the assets as well as converted the maps from pbr and made the additional model and material variations.

I understand some changes that break backwards compatibility, long as they're kept minimal and hopefully don't render old FM's unplayable unless patched. We should keep in mind some maps may never get updated, especially ones who's authors might no longer be around... at the same time some things can't be easily improved because keeping it backwards compatible is more challenging, I felt a few things were limited for that reason a couple of times.

Yeah, as I said elsewhere, it's not so much that the missions are broken that is frustrating to me and several other affected authors, it's that there was zero communication to the affected authors that this was going to be happening beforehand. There is no reason why a message couldn't have been sent to the affected authors saying "hey, this will be broken in the upcoming dev build for X reasons. I thought you'd like to know before surprising you." Or even an open discussion beforehand about why these authors decided to make these customizations to begin with. Plain and simple, that's just a lack of respect. If you have the time to break these, you have time to communicate and see if there might be a solution to avoid all this (and there is!). And perhaps from YOUR perspective, you might think this reaction seems silly, unnecessary, and that this is totally fine, but from my perspective and that of a few others, it's not. EDIT: In addition, when creating or modifying existing assets, I and others take great care in making sure that these changes don't break existing maps. And if they do, we do whatever we can to own up to that and fix it. I do expect that same level of respect to be shown to existing maps so they aren't just broken with reckless abandon and no clear path forward.

It's a bummer I'm not personally good in drawing maps.

Funnily enough, I was going to ping you and see if you wanted to draw the map. There is something included which could technically be called a 'map', but it sucks. The issue is the FM doesn't cover a huge area, but there is a LOT of vertical overlap so the options are a single map which provides vague guidance (the option I've gone with), or loads of tiny maps for each area (which would suit an automap probably).

I think that this discussion is probably similar to discussions that idSoftware themselves had about the challenges of texture storage in engines that heavily rely on Normal Maps for real-time lighting. The conclusion was Megatextures ( later known as partially resident textures ) but the suggestion was a little too ahead of its time. Heck, early Megatexture games would probably benefit from detail textures more than idTech4 because they capped the pixel density to allow larger map-sized textures. Many modern games have caught up and use partially resident textures but do so in a more conservative way thus making them part of a hierarchy of texture usage methods that includes texture atlases and traditional tiled textures.

Correctly me if wrong. Apperantly xdata formatting doesn't work well with the lang references. So this: maps/man2/mission_briefing { "num_pages": "1" "page1_body" : "#str_b1" "" "#str_b2" "" "#str_b3" } Doesn't work. You can only do this: maps/man2/mission_briefing { "num_pages": "1" "page1_body" : "#str_b1" } And then in the lang file you have to add the whole text of page 1 and get newlines via \n etc. So writing a (text only) briefing or readable and after that translating, is probably not something you want to do. I didn't actually test this with readable's, but it seems to me it would have the same limitation.

Interesting idea. Not sure about my upcoming time availability to help. A couple of concerns here - - I assume the popup words uses the "Informative Texts" slot, e.g., where you might see "Acquired 80 in Jewels", so it likely wouldn't interfere with that or with already-higher subtitles. - There are indications that #str is becoming unviable in FMs; see my just-posted: https://forums.thedarkmod.com/index.php?/topic/22434-western-language-support-in-2024/

In post https://forums.thedarkmod.com/index.php?/profile/254-orbweaver/&status=3994&type=status @nbohr1more found out what the Fixup Map functionality is for. But what does it actually do? Does it search for def references (to core?) that don't excist anymore and then link them to defs with the same name elswhere? Also I would recommend to change the name into something better understood what it is for. Fixup map could mean anything. And it should be documented in the wiki.

Another failure by @kingsal. Firstly the mission is way too short. And like his other missions, the quality is supreme, keeps me playing and neglecting real life duties. Never feeling the frustration of getting stuck, never resolving to walkthrough material. Is it a sign of excellent design or rather a lack of challenge? Also extreme attention to detail, engaging maps from room to a room, gorgeous visually. I understand this is just a free-time effort for someone who could instead make money out of his skills but, I'm sure you could do better.

Ok, but you could also load all maps in your campaign, but in a different order. Or you could make a copy of the map and change some things. So it doesn't have to be an entirally different mission (which indeed might be too much work). So for example the first mission has an objective to place the plans to build a bridge over the river in a specific place. Then the next mission has that bridge (map1), or does not have that bridge (map2). Mapper only has to make a copy of the map and remove the bridge (and maybe a small amount of other things). I just think that having only one specific order is pretty restrictive. But if it's a lot of work to implement it might not be worth it.

Another thing, not sure if it's entirally related: If you have a campaign, you might want to have different maps loaded depending what you do in the mission. Currently there's one specific order, but it would be cool if another map could be loaded. So you could get different debriefings, but also different followup missions based on that. I don't want to derail the topic, so if needed this could be split into a new feature request.

Alright, so, I'm a Texture Artist myself for more than 20 years, which means I know what I'm talking about, but my word isn't law at all, remember that. I've worked (mostly as mods, I am a professional but I much prefer being a freelance) with old DX8 games up to DX12. When it comes to Detail Textures, for my workflow, I never ever use it except rarely when it's actually good (which, I emphasize on "rarely"). This is one reason I thought mentioning that I worked with DX8 was logical. One of the few times it's good is when you make a game that can't have textures higher than what would be average today, such as, World Textures at 1024x1024. Making detail textures for ANY (World, Model) textures that are lower than 128x128 is generally appealable. Another is when the game has no other, much better options for texturing, such as Normal Maps and Parallax Mapping. Personally, I think having Detail Textures for The Dark Mod is arguably pointless. I know TDM never had a model and texture update since 2010 or so, but most textures do seem to at least be 1024x1024, if there's any world texture that's lower than 256x256, I might understand the need of Detail Textures. Now, if this was a game meant to be made in 2024 with 2020+ standards, I would say that we should not care about the "strain" high resolution textures add, however, I do have a better proposition: Mipmaps. There are many games, mostly old than new ones, that use mipmaps not just for its general purpose but also to act as a "downscaler". With that in mind, you boys can add a "Texture Resolution" option that goes from Low to High, or even Lowest to Highest. As an example, we can add a 2048x2048 (or even 4096x4096) world texture that, if set to Lowest, it would use the smallest Mipmap the texture was made with, which depends on how the artist did it, could be a multiplication of 1x1 or 4x4. One problem with this is that, while it will help in the game with people who have less VRAM than usual these days, it won't help with the size. 4096x4096 is 4096x4096, that's about 32mb compressed with DXT1 (which is not something TDM can use, DXT is for DirectX, sadly I do not know how OpenGL compresses its textures). I would much rather prefer the option to have better, baked Normal Maps as well as Parallax Mapping for the World Textures. I'm still okay with Detail Textures, I doubt this will add anything negative to the game or engine, very sure the code will also be simple enough it will probably only add 0.001ms for the loading times, or even none at all. But I would also like it as an option, just like how Half-Life has it, so I'm glad you mentioned that. But yet again, I much prefer better Normal Maps and Parallax Mapping than any Detail Textures. On another note...Wasn't Doom 3, also, one of the first games that started using Baked Normal Maps?

Interesting! Does it update all default textures so it's used on everything in the world? I should replay it and check that out: It would give us a good view of how the effect will feel in practice. Looking at the page, they seem to do it the conventional way I was thinking of trying out, which is currently supported by the engine but more limited than a proper implementation. It also looks like they're only doing it for the albedo channel, to be effective detail should be applied to all maps... the normal map is where the improvement should be most noticeable as it responds to lighting and modifies everything else. The implementation I'm thinking of should be universal like all effects and work on any FM new and old. It would be controlled by a menu setting, no one needs to enable it if they don't like how it looks or it impacts performance. Each detail pass should fade and be hidden with distance, we don't want to stress pixel lighting by having it compute thousands of dots on distant surfaces each frame. Just like the TDM ambient method, we'll likely need a special segment for materials meant to indicate what kind of detail each texture wants, then based on settings and camera position the renderer must modify each surface accordingly.

There's been talk over the years on how we could improve texture quality, often to no avail as it requires new high-resolution replacements that need to be created and will look different and add a strain on system resources. The sharpness post-process filter was supposed to improve that, but even with it you see ugly blurry pixels on any nearby surface. Yet there is a way, a highly efficient technique used by some engines in the 90's notably the first Unreal engine, and as it did wonders then it can still do so today: Detail textures. Base concept: You have a grayscale pattern for various surfaces, such as metal scratches or the waves of polished wood or the stucco of a rough rock, usually only a few highly generic patterns are needed. Each pattern is overlayed on top of corresponding textures several times, every iteration at a smaller... as with model LOD smaller iterations fade with camera distance as to not waste resources, the closer you get the more detail you see. This does wonders in making any texture look much sharper without changing the resolution of the original image, and because the final mixture is unique you don't perceive any repetitiveness! Here's a good resource from UE5 which seems to support them to this day: https://dev.epicgames.com/documentation/en-us/unreal-engine/adding-detail-textures-to-unreal-engine-materials Who else agrees this is something we can use and would greatly improve graphical fidelity? No one's ever going to replace every texture with a higher resolution version in vanilla TDM; Without this technique we'll always be stuck with early 2000's graphics, with it we have a magic way of making it look close to AAA games today! Imagine being able to see all those fine scratches on a guard's helmet as light shines on it, the thousands of little holes on a brick, the waves of wood as you lean into a table... all without even losing much performance nor a considerable increase in the size of game data. It's like the best deal one could hope for! The idTech 4 material system should already have what we need, namely the ability to mix any textures at independent sizes; Unlike the old days when only a diffuse texture was used, the pattern would now need to be applied to both albedo / specular / normal maps, to my knowledge there are shader keywords to combine each. Needless to say it would require editing every single material to specify its detail texture with a base scale and rotation: It would be painful but doable with a text injection script... I made a bash script to add cubemap reflections once, if it were worth it I could try adapting it to inject the base notation for details. A few changes will be needed of course: Details must be controlled by a main menu setting activating this system and specifying the level of detail, materials properties can't be controlled by cvars. Ultimately we may need to overlay them in realtime, rather than permanently modifying every material at load time which may have a bigger performance impact; We want each iteration to fade with distance and only appear a certain length from the camera, the effect will cause per-pixel lighting to have to render more detail per light - surface interaction so we'll need to control the pixel density.

I'm not using the Quake 3 engine, I'm using the Godot engine. The results seem ok, except when faces are slanted, but I'm not sure why it happens. I'm trying to find out. I don't know anything about the Q3 engine, so I'm not the one to say what's correct and what isn't about the map format. When I said "correct", I just meant that it's the same value that is displayed in the editor. But there are differences between the Q3 format from DR and from other editors I've tested, like TrenchBroom and NetRadiant Custom. They keep the texture values as they are in the editor. One other difference is that DR exports entity brushes with coordinates relative to the `origin` spawnarg, for example. Though DR is also the only editor that enforces the `origin` spawnarg. (I know there are two Q3 formats, and I'm using the equivalent one on all editors.) I'm importing maps into Godot using a plugin. I've made some changes to it to accommodate for the differences in the map format and some editor specific stuff (e.g. DR uses "rotation" matrices instead of euler "angles").

So..., texture issues are being the only road block I'm having so far in trying to use DR with Godot, but I'm not exactly sure why yet. However, I've noticed when exporting maps in quake3 format, that the texture values don't match the ones in the editor. This is the door face in the map file: hs vs rot hscale vscale ( 24 64 0 ) ( -24 64 96 ) ( 24 64 96 ) darkmod/door/wood/board_brown_nails_hinge 64 256 -180 -0.375 -0.375 0 0 0 The horizontal shift is the only correct value. Is this a bug?

Yes. Sure, I will change it, but I do mind. In addition to changing the forum title, I have also had the name of the pk4 changed in the mission downloader and the thiefguild.com site’s named changed. It's not just some "joke". The forum post and thread are intended to be a natural extension of the mission’s story, a concept that is already SUPER derivative of almost any haunted media story or most vaguely creepy things written on the internet in the past 10 or 15 years. Given your familiarity with myhouse.wad, you also can clearly engage with something like that on some conceptual level. Just not here on our forums? We can host several unhinged racist tirades in the off-topic section but can’t handle creepypasta without including an advisory the monsters aren’t actually under the bed? (Are they though?) I am also trying to keep an open mind, but I am not really feeling your implication that using a missing person as a framing of a work of fiction is somehow disrespectful to people who are actually gone. I have no idea as even a mediocre creative person what to say to that or why I need to be responsible for making sure nobody potentially believes some creative work I am involved in, or how that is even achievable in the first place. Anyway, apologies for the bummer. That part wasn’t intentional. I am still here. I will also clarify that while I love the game, I never got the biggest house in animal crossing either. In the end Tom Nook took even my last shiny coin.

Thanks for the feedback @Rio_Walker As mentioned in other comments in this thread, the optional objective was meant to be for players who enjoy exploring every inch of the map. If all you want to do is complete the mission via the primary objective it's pretty straightforward. It was also meant to be sort of 'open world' in that if you explore everywhere you pick up little hints and bits and pieces and put them together at the end to solve that objective with. It wasn't meant to spoon feed the player. But again maybe not everyone enjoyed that approach. It was also kind of a knee-jerk reaction to players not liking 'linear' missions. But it seems some people still do like that And yeah, some players don't like big maps. I get that. I don't like playing them myself a lot of the time The issue with the bow crash is a known issue (not just with this mission) which we haven't got to the bottom of unfortunately:

Looks great, thank you! That looks even better: It's where DeusEx had its player status screen, feels even more like TDM with DX characteristics now I think I placed it above the light gem as that's where player info was technically being stored, with the new subtitles covering that position the move is a great decision. By the way: If anyone wishes to continue and improve this mod, I'd appreciate seeing your remixes of it. I had it mostly finished last time on my end; I think the main issue was upgrades require items to be placed on maps, augmentations may not work on every FM without a way for them to automatically spawn in random places... my imagined solution was to also offer upgrades based on loot gathered or other achievements but I never got around to adding that.

I've seen fun workarounds like that in other game modding as well. Years ago, maybe even a decade, some fella who was making a mod for Mount & Blade over at the Taleworlds forums revealed that he put invisible human NPCs on the backs of regular horse NPCs, then put the horse NPCs inside a horse corral he built for one of his mod's locations/scenes and then did some minor scripting, so the horses with invisible riders would wander around the corral. The end result was that it looked they're doing this of their own will, rather than an NPC rider being scripted to ride around the corral slowly. Necessity is the mother of invention. I don't know about the newest Mount & Blade game, but the first generation ones (2008-2022) apparently had some sort of hardcoded issue back in the earlier years, where if you left a horse NPC without a rider in its saddle, the horses would just stand around and wait and you couldn't get them to move around. Placing an invisible rider in their saddles suddenly made it viable again, at least for background scenes, of riderless horses wandering around, for added atmosphere. First generation M&B presumed you'd mostly be seeing horses in movement with riders, and the only horses-wandering-loosely animations and scripting were done for situations when the rider was knocked off their horse or dismounted in the middle of a battle. Hence the really odd workarounds. So, an invisible NPC trick might not be out of the question in TDM, even though you could probably still bump into it, despite its invisibility.