Search the Community

I created discussion here and mentioned authors (maybe I missed someone though). Unlike the previous thread about main menu GUI overrides, I think the new one does not look aggressive . The main question there is why this was done, and how to adapt to avoid this problem now and in the future. Indeed, all the missions will be fixed by 2.13 even if some authors don't respond. Dev builds regularly break something, although usually it is done unintentionally. I added "known issues" point on the dev build, which happens pretty rarely. I apologize for the negative emotions this change has caused. Sometimes I am too rough in communications. Moreover, I am not a creative kind of person, I'm more a technical type of person. Thus I believe in interface boundaries, so in my mind the blame for breakage is always on the side that violates these boundaries. Anyway, I know I'll have to fix the breakage, probably myself if necessary.

And... running another update and the problem is solved. Sorry for the noise.

What is the problem with bugtracker 5600? Does the player start without a bow now?

The Megatextures concept predates idSoftware. It even predates hardware accelerated 3D in consumer graphics. The problem it solves is managing image diversity. It is well suited to photogrammetry where almost nothing is repeated \ tiled. It is not well suited to human texture artists because even the most perfectionist ones are going to use some sort of template that they repeat and thus it is a waste to store the resultant work as unique pixels rather than tiles.

I havent tried in 2.11 yet but I will. Just an update on this. For now I think I fixed it by: - Addressing most of the warning in the log above. Outside common errors like some missing textures and such that are part of the core. - Made sure to give my parallel lights "parallelSky " "1" spawnarg. - Deleted my .aas files and rebuilt them - Dmapped the entire thing Right now I am not getting the load error . It's a very hard problem to nail down because the console isn't giving a specific script name that it's getting hung up on (if that is even the issue similar to Amadeus's problem) AND I am actively working on the mission, creating new errors, fixing other broken things. ect. Its definitely something I fear will pop back up in beta testing though

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.

@Ansome's question is correct. Nothing in real life ever has a perfectly sharp corner, and one of the pieces of advice often given to newbie modellers trying to make things look realistic and avoid the "obvious CG" look, is to give sharp edges a tiny bevel so they look like something that might be manufactured in real life. The problem you've got in DarkRadiant is (1) dealing with tiny bevels using regular brush geometry is awkward, and (2) brushes aren't smoothed at all (unlike the cube on the right which actually has full smooth shading which you don't notice because of the tiny bevel). So unless you're willing to create imported 3D models with smoothed bevelled edges and place them on the corner of your buildings, adding bevels in brushwork might be more trouble than it's worth. Probably the most important things with brickwork corners is to make sure the bricks line up properly. There's nothing more obviously CG than a plastered-on brickwork texture which just ends in an unrealistic column of cut-off bricks, with mortar joints that are completely unaligned with the brickwork on the adjacent face.

When talking about a possible libre version of TDM (https://forums.thedarkmod.com/index.php?/topic/22346-libre-version-of-tdm/) it seems we believe all media/gamedata included in TDM is licensed CC-BY-NC-SA. I am not familiar with how the process of adding new media/gamedata works today; I have seen files uploaded to the bugtracker which developers then commit to SVN, but I don't know if there are other ways. It may be a good idea to implement a process that when new components (media/gamedata included in TDM) are added, the contributor is asked to be explicit about the license (a choice which may defaults to their previous preference, for usability). It won't fix the past, but it may help in the future. This will make it easy for contributors to add future data under a more permissive license if they choose. Libre media can be added and its license can be tracked, rather than assumed to be CC-BY-NC-SA. I suggest looking at how Wikimedia Commons has implemented this: the contributor state the source and license at the time the data is uploaded. This can be done either by providing urls or by saying "It's my work and I choose this licsense". The first step could be to add a way to keep track of each filepath in SVN, author, license, sources. Start by setting the value for each file's license to "(default/legacy CC-BY-NC-SA)". Possible implementations for a user interface for new additions are: * Use our own wiki, which runs Mediawiki (same as Wikimedia Commons). I see several benefits of this, but we also need a way to accept uploads of batches, not just single files. * Look at how other open source projects have solved this. There may be more appropriate solutions available. ... but I'll leave the implementation open. Suggestions are very welcome! If the author of each file already in SVN can be tracked, then it may be possible that the author is willing to give a blanket permission for all their past files in one statement, and all their files in SVN can be updated in one commit. A productive contributor willing to release some of their work under a more permissive license could make a big change. If Dark Radiant would support letting mappers search media/gamedata by license (does it already?), it would make it easier for mappers to create a completely libre mission, which would help facilitate a TDM-libre release. If I understand things correctly. This post does not address all details and it may contain misunderstandings or assumptions, but it's a start. Also relevant: * Is there a compiled and maintained list of recommended or deprecated resources for mappers to use? * https://forums.thedarkmod.com/index.php?/topic/20311-external-art-assets-licensing/

The main problem of the art direction of T4 is that is *ONLY* that kind of dark (=the "gloom" fallen over the City), prologue apart. Prologue atmosphere is just perfect

Ah, pity I wasn't reading the forums back in February. I'm fond of that game, along with Bugbear's other early title, Rally Trophy. I was never too good at FlatOut, but it was always a hoot to play.

If all written strings were kept in XD files, the process would be easier. We shouldn't need map edits for this. The current system makes mission updates a real problem to the point that only long dormant missions are viable for translation.

BTW, my concern about #str values is about those distributed in FM-specific .lang files. For standard assets, where the info would be in tdm_base01.pk4/all.lang and its derivative .lang files, I guess that's less of a problem. In that case, maybe, instead of using a #str_<number>, you could use a fixed prefix, like: #str_shouldered_<english_name> or #str_moveable_<english_name> That is, like #str_shouldered_chair A general string like that might be used with multiple different chair models, as you intended. If the author overrode the shouldered name with a non-#str name: #str_shouldered_chair --> cushy chair with clue then any translated general strings would be hidden, and just the English version shown.

Complaint From Players The player must pick up candles before extinguishing them, and then the player must remember to drop the candle. The player must drag a body before shouldering it (picking it up), and the player must remember to frob again to stop dragging the body. The player finds this annoying or easy to make mistakes. For players who ghost, some of them have the goal of returning objects back to their original positions. With the current "pick up, use item, and drop" system, the item might not return easily or at all to its original position. For example, a candlestick might bounce off its holder. (See player quotes at the bottom.) Bug Tracker https://bugs.thedarkmod.com/view.php?id=6316 Problems to Solve How can the "pick up" step be eliminated so that the player can directly use or interact with the item where it is in the game world? How can so much key pressing and mouse clicking be eliminated when the player wants to directly use an item? How can candles be extinguished and lanterns toggled off/on without first picking them up? How can bodies be shouldered without first dragging them? Solution Design Goals Make TDM easier for new players while also improving it for longtime players. Reduce tedious steps for common frob interactions. Make it intuitive so that menu settings are unnecessary. Do not introduce bugs or break the game. Terms frob -- the frob button action happens instantly. hold frob -- the frob button is held for 200ms before the action happens. (This can be changed via cvar: 200ms by default.) Proposed Solution Note: Some issues have been struckthrough to show changes since the patch has been updated. Change how frobbing works for bodies, candles, and lanterns. For bodies: Frob to shoulder (pick up) a body. Second frob to drop shouldered body, while allowing frob on doors, switches, etc. Hold frob (key down) to start drag, continue to hold frob (key down) to drag body, and then release frob (key up) to stop dragging body. Also, a body can be dragged immediately by holding frob and moving the mouse. For candles/lanterns: Frob to extinguish candles and toggle off/on lanterns. Hold frob to pick it up, and then frob again to drop. Frob to pick it up, and then frob again to drop. Hold frob to extinguish candles and toggle off/on lanterns. For food: Frob to pick it up, and then frob again to drop. Hold frob to eat food. For other items: No change. New cvar "tdm_frobhold_delay", default:"200" The frob hold delay (in ms) before drag or extinguish. Set to 0 for TDM v2.11 (and prior) behavior. Solution Benefits Bodies: New players will have less to learn to get started moving knocked out guards. With TDM v2.11 and earlier, some players have played several missions before realizing that they could shoulder a body instead of dragging it long distances. Frob to shoulder body matches Thief, so longtime Thief players will find it familiar. Second frob drops a shouldered body. Players still have the ability to both shoulder and drag bodies. Compatible with the new auto-search bodies feature. Dragging feels more natural -- just grab, hold, and drop with a single button press. There is no longer the need to press the button twice. Also, it's no longer possible to walk away from a body while unintentionally dragging it. Set "tdm_frobhold_delay" cvar to delay of 0 to restore TDM v2.11 (and prior) behavior. Candles: New players will have less to learn to get started extinguishing candles. With TDM v2.11 and earlier, some players didn't know they could extinguish candles by picking them up and using them. Instead, they resorted to throwing them to extinguish them or hiding them. Hold frob to extinguish a candle feels like "pinching" it out. Once a candle is picked up, players still have the ability to manipulate and use them the same way they are used to in TDM v2.11 and earlier. For players who ghost and have the goal of putting objects back to their original positions, they'll have an easier time and not have to deal with candles popping off their holders when trying to place them back carefully. Set "tdm_frobhold_delay" cvar to delay of 0 to restore TDM v2.11 (and prior) behavior. Solution Issues Bodies: Frob does not drop a shouldered body, so that might be unexpected for new players. This is also different than Thief where a second frob will drop a body. "Use Inv. Item" or "Drop Inv. Item" drops the body. This is the same as TDM v2.11 and earlier. This is the price to pay for being able to frob (open/close) doors while shouldering a body. Patch was updated to drop body on second frob, while allowing frob on doors, switches, etc. Candles: Picking up a candle or lantern requires a slight delay, because the player must hold the frob button. The player might unintentionally extinguish a candle while moving it if they hold down frob. The player will need to learn that holding frob will extinguish the candle. The player can change the delay period via the "tdm_frobhold_delay" cvar. Also, when the cvar is set to a delay of 0, the behavior matches TDM v2.11 and earlier, meaning the player would have to first "Frob/Interact" to pick up the candle and then press "Use Inv. Item" to extinguish it. Some players might unintentionally extinguish a candle when they are trying to move it or pick it up. They need to make sure to hold frob to initiate moving the candle. When a candle is unlit, it will highlight but do nothing on frob. That might confuse players. However, the player will likely learn after extinguishing several candles that an unlit candle still highlights. It makes sense that an already-extinguished candle cannot be extinguished on frob. The official "Training Mission" might need to have its instructions updated to correctly guide the player through candle manipulation training. Updating the training mission to include the hold frob to extinguish would probably be helpful. Similar Solutions In Fallout 4, frob uses an item and long-press frob picks it up. Goldwell's mission, "Accountant 2: New In Town", has candles that extinguish on frob without the need of picking them up first. Snatcher's TDM Modpack includes a "Blow / Ignite" item that allows the player to blow out candles Wesp5's Unofficial Patch provides a way to directly extinguish movable candles by frobbing. Demonstration Videos Note: The last two videos don't quite demonstrate the latest patch anymore. But the gist is the same. This feature proposal is best experienced in game, but some demonstration videos are better than nothing. The following videos show either a clear improvement or that the player is not slowed down with the change in controls. For example, "long-press" sounds long, but it really isn't. Video: Body Shouldering and Dragging The purpose of this video is to show that frob to shoulder a body is fast and long-press frob to drag a body is fast enough and accurate. Video: Long-Press Frob to Pick Up Candle The purpose of this video is to show how the long-press frob to pick up a candle isn't really much slower than regular frob. Video: Frob to Extinguish The purpose of this video -- if a bit contrived -- is to show the efficiency and precision of this proposed feature. The task in the video was for the player to as quickly and accurately as possible extinguish candles and put them back in their original positions. On the left, TDM v2.11 is shown. The player has to highlight each candle, press "Frob/Interact" to pick up, press "Use Inv. Item" to extinguish, make sure the candle is back in place, and finally press "Frob/Interact" to drop the candle. The result shows mistakes and candles getting misplaced. On the right, the proposed feature is shown. The player frobs to extinguish the candles. The result shows no mistakes and candles are kept in their original positions. Special Thanks @Wellingtoncrab was instrumental in improving this feature during its early stages. We had many discussions covering varying scenarios, pros, and cons, and how it would affect the gameplay and player experience. Originally, I had a completely different solution that added a special "use modifier" keybinding. He suggested the frob to use and long-press frob to pick up mechanics. I coded it up, gave it a try, and found it to be too good. Without his feedback and patience, this feature wouldn't be as good as it is. Thank you, @Wellingtoncrab! And, of note, @Wellingtoncrab hasn't been able to try it in game yet, because I'm using Linux and can't compile a Windows build for him. So, if this feature isn't good, that's my fault. Code Patch I'll post the code patch in another post below this one so that folks who compile TDM themselves can give this proposal a try in game. And, if you do, I look forward to your feedback! Player Complaints TTLG (2023-01-10) Player 1: TDM Forums (2021-03-13) Player 2: Player 3: TDM Forums (2023-06-17) Player 4: TDM Discord (2021-05-18) Player 5: TDM Discord (2023-02-14) Player 6: Player 7: Player 8:

It's a big project, so it's important to test everything thoroughly and run several tests. "The Lost Citadel" had a lot of bugs in the first release because I didn't test enough. I will not repeat this mistake. I have fixed all problems found during beta 2. Beta 3 shall include all subtitles and briefing videos. The problem is that I'm still missing some voices. This means we can't complete the game subtitles and produce the briefing videos. In the worst case, I'll have to do a new audition for this stuff, but currently I don't feel like it.

The problem with the bow after loading seems to be a common bug of 2.10, I noticed it in other missions as well!

I believe the engine sets mindistance = 1 and maxdistance = 10 if they are not set explicitly in the sound shader. At least that's what I see here: https://github.com/stgatilov/darkmod_src/blob/trunk/sound/snd_shader.cpp#L154 Anyway, if DR sets spawnargs to the same values as in sound shader, that's not a problem for the suggested change in the meaning of zero value. But setting maxdistance = 0 will be

I manually integrated and tested your PR. There is good news and bad news: The good news is that when running with the "GDK_BACKEND=x11" flag, using the clipper tool no longer breaks the window forcing me to restart DR afterward, the model / entity viewer no longer experiences the issue either. The bad news is that flag is still required, every viewport retains the problem if running Radiant in Wayland mode, we still have a big problem Linux users will increasingly run into as distros adopt it (KDE Plasma 6 now uses Wayland by default). So please integrate the PR if it doesn't break anything, it makes life much easier in the meantime! But this should remain open until either DR or WxWidgets or Wayland solve the core issue that exists when running in native mode.

heh yeah i wonder if trumph has stock in nvidia ? all those lawsuits... , not even so sure it will just blow over tbh, here in denmark we allready use AI heavily. one example of all things it now governs are taxes well in the worlds most tax heavy country who just loves tech i'd say thats a no brainer but c'mon... not really feeling the need for more upgrading for a good time either, my machines now run the latest stuff no problem and i recently aquired a motorized table for my aching back (well it really started to ache after i had to lift it to the first floor... damn that hing is heavy 65 kg) and me nearing 57 years with a back who was broken in two places which required operation with two artificial discusses and a lot of screws and with heavy nerve damage because it took them 10 years to dicover it was broken i can only say ouch.

A couple more: https://forums.thedarkmod.com/index.php?/topic/21739-resolved-allow-mantling-while-carrying-a-body/ https://forums.thedarkmod.com/index.php?/topic/22211-feature-proposal-new-lean-for-tdm-212/ https://forums.thedarkmod.com/index.php?/topic/22198-feature-proposal-frob-to-use-world-item/ https://forums.thedarkmod.com/index.php?/topic/22249-212-auto-search-bodies/

sadly the upcomming 8xxx series from amd will only be for midrange atleast according to leaks (grain of salt maybe ?). well it would be something quite different thats for sure not sure if 32 gb vram would actually help (what is the max texture size today ?), it might help if they really go nuts with the detail level in upcomming titles but i suspect this might take longer as the game companies dont want to alienate players with less vram. ofc it will come at some point but i dont see it in the near future. the 2 and 3 gb vram chips might actually make a dent in the bus width war. what the hell happened with hbm memory ???, the old fury cards could actually do 4k no problem with only 4 gb vram because the hbm memory was so blazing fast.

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?

@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.

Author Note: This is a brand new mission and a new entry into the accountant series. There are some different than usual puzzles in this FM, so if you find yourself stuck try to think about your pathway forward in a logical manner. And if you're still having troubles then pop by this thread and ask (preferably with spoiler tags). This FM is brand new and serves as the first installment in The Accountant series, a few years back there was a small prologue style mission released however I felt that it did not represent The Accountant series so I decided to go back to the drawing board and do a whole new mission that's larger, has a better level design and has a story that lines up closer to what I plan to do with the accountant series. The mission is medium sized and you can expect between 30-90 minutes to complete it depending on your playstyle. Beta Testers Captain Cleveland Crowind Kingsal PukeyBee Skacky SquadaFroinx Voice Actors AndrosTheOxen Epifire Goldwell Stevenpfortune Yandros Custom assets Airship Ballet Bentraxx Bob Necro Dragofer DrKubiac Epifire Kingsal MalachiAD Sotha Springheel SquadaFroinx Available via in-game downloader File Size: 233 MB - Updated to v 1.1 (01.06.2018)