Search the Community

Extensive customization options are appropriate during the pre-release testing or early roll out of a new feature. The people testing the feature can't know yet what configuration will work best for them, much less the people making the patch. My expectation is that by the time you have to make a final decision about including this patch in the next official update of TDM, there will be a rough consensus about the optimal parameters for the new mechanics, and you will only need one toggle for the new behavior. Or, preferably, there would be no need for an option at all if we can only get over our OCD about preserving arbitrary semantic grouping in our key-bind allocations; and embrace a superior control scheme that's not designed around highlighting an old gimmick feature whose trendiness expired with the Half-Life 2 era of FPS. But that's a pipe dream. Maybe instead we can just all agree that the general>gameplay options are getting a bit crowded. Perhaps we could split some of them off into an "appearance" or "accessibility" tag. As more people make their own mods and we modernize our accessibility options it is going to become a problem regardless. Best to get ahead of it. I agree, and that is one of TDM's strengths. It borrows and combines many of the best features from the three beloved Thief games, but it also gives FM creators tools to expand their creative vision in new directions. To some Thief purists that will never be an enticing proposition. But I don't see this feature as throwing a bone to those Thief players specifically, but just player in general who are bouncing off our game because it deviates from some genre conventions for no obvious reason, which makes them think this is an unpolished product. It is true that Thief was what set these conventions, and (shockingly/s) it is mostly Thief players who are interested enough in TDM to give it a try... but our responsibility to address these problems (if we can) is the same as if AMD or Linux players were having technical problems with TDM. They are people who we want to be part of our community because we never know if one of them might make the next FM like Iris, or do something crazy-innovative with TDM that we can't even imagine!

Wow! This is something interesting. You have areas 177 and 179 (you can detect them using teleportArea command) with 8 visportals between them, all in same plane. I hope this is as intended, and you really have many separate visportals? This should be perfectly valid of course. FloodLightThroughPortals searches for all visportal sequences which might get some light rays through. For some reason, it manages to go back and forth between areas 179 and 177 something like eight times in the same sequence. It is not forbidden for the traversal to go through the same area many times, but it is forbidden to go through oriented visportal twice. However, there are too many possible sequences of going through 8 two-sided visportals, and the code obviously tries to enumerate and save them all. At some point it bumps into 32-bit integer limits and everything crashes. By this moment it has wasted 32 GB of RAM so I don't think it would live long even if it did not crash here. You don't have the issue in 2.11 because: This is a dynamic light from some lantern bot, TDM 2.11 only runs this function for static lights. TDM 2.11 does not try to save all sequences, it would only enumerate them in horrendously slow time. I think some lantern bot crosses the visportal between areas 179 and 177 at this moment, causing the issue. Also, you can most likely reproduce it in 2.11 by putting a large enough light at the same location (12565.0205, 411.300110, 522.249939).

Is there some reason that the custom head can't be just given to the player at the outset (in some def file), and not swapped? Might be more stable, I'm guessing.

Seems like an inoffensive suggestion to me. It would not provide much of a challenge though since all one need do is let go of the mouse and voila: perfect stillness. For that reason, to work as advertised I feel like it would need to be tuned to be a non-factor 98% of the time, such that even veteran players would forget it exists until suddenly, surprise! here's an edge case where it matters. Like: only movements greater than 90 degrees per second trigger the effect. Basically it would just be an in-game jump scare mechanic. If something makes you as the player character involuntarily jump or flinch then that has a chance of being spotted. In the hands of a devious FM author that could make for some extremely memorable scripted moments. That's all just in principle though. In practice, this is an idea that would cost development energy to implement, and we want to make sure that investment is committed wisely. Remember how the community flipped the f*** out when Hazard Pay had the audacity to restrict saving, going so far as to make a mod specifically to negate the author's intent, and basically ensuring that no FM that's not a deliberate troll will ever use that feature again? Great use of resources that was. /s

Because of the latest reports in this topic I just re-played this mission in TDM 2.11a and I didn't run into any issues. For some reason though the map is duplicated, which is annoying but apparently harmless.

RE Glitches with the Stone (aka Stone Print) font. Probably the minor artifacts with this font - mentioned in the bugtracker - are due to the fact that this file is missing from the distribution: tdm_fonts01\fonts\english\stone\fontimage_12.dat <== MISSING which I surmise causes the 24pt font to be used instead and scaled down. There is some reason to believe the missing file was present at one time, because the corresponding .dds file is present: tdm_fonts01\dds\fonts\english\stone\stone_0_12.dds And the russian paths have both the .dat and .dds files (2 of the latter in the case of russian) for this font. (I think trying to copy the russian version of .dat to the english branch would fail big time.) If someone with access to an archive of very early TDM full distributions can check to see if it is available, that would be great. That would be the best way to go, because that file may contain hand-tweaks to the font spacing. Otherwise, it could be regenerated from the .ttf file and tweaked, a somewhat fraught endeavor (at least if I were to attempt it).

Not to be a nag, but I was thinking about the columns problem. If you go to the view source tab in the wiki article: https://wiki.thedarkmod.com/index.php?title=Fan_Missions_for_The_Dark_Mod&action=edit The raw table data is accessible directly: |- !align=left|{{TDM-FM|written|Written in Stone}} |Bikerdude, Amadeus, Dragofer |{{Forumlink|https://forums.thedarkmod.com/index.php?/topic/21265-written-in-stone-beta-210-only-20220128/}} |2022-01-28 |338 |Yes |Yes |CCC 22, Elixir |City Missions |Undead, Horror Themes |- Each pipe character represents one of the columns.

Nice knowing you are looking at this. Btw when I made my own version of "namedEvent" gui cmd, I just copied the convention of other gui cmds like the "localSound" cmd, what I found is that it made the usage of simple nameEvents in GUI's very fast, with no need to mess with c++ and compile the engine. I think exactly the same reason quake 4 developers said they implemented it, thou like you said we don't know how they made their version. Perhaps is why I had some issues with my implementation when trying to call more complex onNamedEvents, so is something that needs to be well tested. Simple example of usage (the following code is untested and should be looked as "pseudo" code) windowDef Desktop { rect 0,0,640,480 backcolor 0,0,0,1 menugui 1 float "text_state" 0 onInit { // just in case ... if("Desktop::text_state" != 0) { set "Desktop::text_state" "0"; } } //*************** Events ************************* onNamedEvent ClearText { set "Text::text" ""; set "Desktop::text_state" "0"; } onNamedEvent SetText { set "Text::text" "Hello world"; set "Desktop::text_state" "1"; } //************************************************ windowDef Text { rect 240,41,165,110 visible 1 forecolor 1,1,1,1 text "" textscale 0.5 font "fonts/micro" textalign 1 } windowDef back_btn { rect (320-55),(240-35),50,30 visible 1 text "Click Me" textalign 1 textscale 0.3 font "fonts/an" onActionRelease { if("Desktop::text_state" == 1){ namedEvent "ClearText"; } else { namedEvent "SetText"; } } } }

Terrific! The beta test thread is up: https://forums.thedarkmod.com/index.php?/topic/22238-beta-testing-the-spider-and-the-finch/

Thanks for all the feedback. My original post was the short version of a long story. So, just to clarify, I always create my account details separately in my password file first and only then copy it into the real log in. My password file is on a flash drive with a back up of the entire drive in a separate room in case of fire or theft. But in this case I couldn't access my main password file on the pc because, of course, it wasn't set up yet So I plugged it in my laptop. Guess what? The laptop doesn't like that drive for some reason. So I plugged in the backup drive and created my details there then copied them into the Win11 setup. Once setup there's a million things to configure how I want Windows and I'm still working on that two weeks later. At some point during this period I became aware my password backup drive was still at hand so I stupidly thought I might as well do a backup before I put it away in the other room! I backedup the main password file over the backup file (which had the only copy of my new Win11 details!) I can't believe I did that because I'm paranoid and really meticulous about organising and backing up account details. Just shows no matter how careful one tries to be one can still make a mistake. Next thing is I've always had problems with Microsoft Accounts. I've set up four or five over the years because every one gives wierd errors without explaining what the problem was. I once had a long session direct with M$oft where I gave them so many personal details to sort it all out and yet they still couldn't fix it! So here I set up yet another new one. So I'm reluctant to reset the password in Win11 in case it conflicts with the same password in the Microsoft Account. (Does that matter?) Or I could reset the password in the M$ account log in and then reset the password in Win11 using the same password. Would that work? As far as that hack, how long is 'ages' to crack it? Hours? Also, what would happen if I create a new user in Win11. I'd probably have to re-install software that is not public user I guess. But would I still be able to set admin privileges where needed? Not sure I'd gain anything. It would still conflict with the Microsoft Account. I can't get my head round all this crap; drives me nuts. Or I could do nothing until there is a problem. Odds are with my luck a pc only lasts two or three years. My previous one won't boot but might be recoverable if I can create a portable Win11 disk and fix the boot sector thing. Life is so bloody complicated. 200 years ago, the only tool I'd have to worry about is my spade which would last a lifetime of labouring on a farm 14 hours a day.

oh boy, i realise this is an old post from a decade ago, and maybe i should start with asking what the default keybindings are on keyboard and mouse for this game is and then go and maky my own keybindings, i'm using a program called controller companion which makes the bindings work, and it's probably better than this old tutorial when it comes to having alternate bindings to fully grasp what's needed. but i'm having trouble with the default bindings not quite being as accurate with the current updated version of the dark mod, and it's basically making anything i bind not properly work which makes the game impossible to play, yes i know i could play on keyboard but the whole reason for the controller is simply due to a disibility i have in my hands which makes long term gaming on keyboard and mouse a real strain on my arms and wrists and fingers and i would rather play with my controller.

Welcome to the Dark Mod forums MarsManon! Thank you very much for the kind words about SLL, it's always nice to hear We all worked real hard on bringing Grayman's map to life and I'm glad you enjoyed it

I was so enchanted by this FM, I had to sign up to the forums the same day I finished it to come thank the authors Genuinely, truly incredible work! I was so overwhelmed in places that I resorted to just shouting joy at my monitor two, three, maybe four entirely separate times while playing. Exploring, puzzling, finding something new, trying to use it, and finding it does a whole new, separate, wonderful thing! There aren't enough words inside me to describe the feeling. It was breathtaking. I don't have any specific feedback that hasn't come through this thread before Thanks so much for making this, for all the inspiration and ingenuity and effort it took. If I never play another level this good, in any other game, in my life, I'd be fine with that.

Hello again TDMers. I am using Text entities to make notes on the map of things I need to do. However, I constantly need to manually add the TEXT property every time I add one. The Text is the basic reason I am adding these things. Is there a way to make the TEXT property show up by default when I create the Text entity? Maybe also the Force property (defaulted to 0) and playerOriented (defaulted to 0)? I use these three properties regularly, but they are not present by default. Appreciated. Clint

Personally, for this kind of game, double-clicking and double-tapping are the kind of things that instantly get a sour taste in my mouth as soon as I hear it, because I already know from experience that it not reliable enough and it's more prone to human error. You said it yourself: It may also happen accidentally if your fingers twitch, or if your mouse misregisters an extra click, or when you think you didn't hit the target and immediately click again, but it so happens that you did hit the target the first time; or when you're hasting to perform the same task multiples times in quick succession (not very relevant here, but I couldn't count how many times I died in minecraft tapping keys to adjust my position and accidentally double-tapping forward and sprinting off a cliff). Also, given that we're talking about the right mouse button, I'm feeling even less inclined. I can double-right-click, but it doesn't feel very comfortable. It's really not something I'm used to, so it requires a degree of effort (and I suppose it will get my hand tired, as @Wellingtoncrabmentioned). Yup. I like ghosting. To be fair, I play with my own lax rules, but I still feel bothered if I have to tamper with the natural order of things, if I think it's unnecessary or that I shouldn't be forced to. It might seem petty, but it's part of what makes the challenge interesting. You never know, the candle owner might have noticed before bed that the candle was about an inch away from a spec of dust, and in the morning he might realize that that distance has changed. So, from a ghosting perspective, when you tamper with things without needing to, you've introduced a point of failure. If the game requires it, that's another story -- it turns into "I can't work around it, so I have to bend the rules because of it". But as far as I'm concerned it still bothers me and kind of ruins the challenge. For example, TDM has been leaving a really sour taste in my mouth when it comes to dropping keys, because lots of missions don't allow it (because unfortunately they're not droppable by default in DR, and for no good reason, afaik). After Snatcher's post about the delay interfering with manipulating bodies, I was growing tempted to agree with reversing it, but then I realized both ways have issues of the same kind. If you can click to shoulder, then you can't click to drag body -- you always have to hold button, which is not great if you're dragging a body a long distance. If you can click to drag a body, then you can't hold to drag a body. You always have to click to drag and then click to release, which is also not great when you're dragging limbs for a pose or something. (I suppose this might be even more annoying than the other.) Maybe I should posting this in that thread.

Thanks everyone for the kind words and feedback! Version 1.1 - https://drive.google.com/file/d/1IiHuD293mIb-kQL_t5dJzKnsnkXl4IN_/view This version has better performance, thanks to b1k3rdude (@Bikerdude - it's not tagging for some reason?) who redid the visportaling in the outdoors area (as well as monster clipping the outdoors, and some decoration on the flat rooftop) - can't thank you enough! This has major impact on the outdoors FPS. I also replaced most of the faux-skybox models with their lowest LODs. Other fixes: Unfortunately still unsure about freezes related to the bridge moving...

There's a group of players who have meticulously tested and adjusted ghosting rules for The Dark Mod. Please see: Official Ghosting Rules: https://www.ttlg.com/forums/showthread.php?t=148523 Ghost Rules Discussion: https://www.ttlg.com/forums/showthread.php?t=148487 Why alienate an established group of dedicated players?

I stopped playing because it lowers performance to a slideshow over time. I'm using proton (Linux), so maybe that's the reason. Here somebody explains it: https://hardforum.com/threads/dark-messiah-framerate-drops-after-in-game-loads.1429977/

Sorry that I cannot provide a more meaningful feedback: the current lean feels good to me and your new lean feels good to me as well. I must have low standards in this regard and both approaches are perfectly serviceable. You have my support for this change if it is perceived as an improvement. Something that's bothered me from day one though is that the left/right (and forward to a lesser relevance) lean buttons seem to have their own agenda. Freedom of movement is handicapped and you cannot lean left or right incrementally or left-to-right and right-to-left dynamically. For some reason you have to go back to straight every time before the next move. I don't know how to explain myself but just launch TDM and lean left/right repeatedly, you should understand what I mean.

I did something similar by improving the description of some of the key binding. Everybody is going over them and might pick up additional info about e.g. the use key. This is one reason why, escpecially if we can't agree on a frob behaviour, there should be an option button to switch it, which automatically will make people aware that the feature exists!

Ok so the original reason I came up with this question is that I was looking at Sotha's Button Controlled Animated Briefing To make that work, you have to edit a gui file and put the text blocks in it. Wouldn't it be easier if you can use text from xdata instead? Then the gui file is just for the looks and operation, like a template that you snap onto your mission, while you create the text in the xdata file. I wondered if that's possible. The normal text based briefing also uses a gui (obviously), which then includes the xdata file. At that point I was thinking of a broader aproach for other gui's, but I probably should've keep it simple.

This just isn’t a true description of the scope as lined out in the original post. Why is it that you feel there is reason enough that you get to decide to just change this? Why is a change which is completely backwards compatible with the existing control scheme “radical”? It is clear in this thread there are players that want this, and anyone who doesn’t doesn’t have to use it. Why at a minimum can’t it go out for testing with more players in a proper dev build like the frob highlight did?

This, just like click again to drop a body, is already included in the patch. If a switch, button or door are highlighted you will interact with them without dropping the body. There are probably more objects this would need to cover which will come up with more testing (readables maybe?) Seems like elements of the patched executable aren’t working with your install for some reason?

Another reason for long-press frob for special action: 2.11 already has one, multiloot. Quick-press frob to loot. Long-press frob to multiloot.

Sure, let's then just add a couple of settings to the menu: Shoulder body: frob/use Extinguish candle: frob/use For some reason we have an "Open Doors on Unlock" setting and surprisingly (for me) it is set to "Yes" by default. I don't quite understand why doors should open automatically and expose me but I guess back in the day there was a similar "Thief does it" discussion that fortunately ended up in truce.