Search the Community

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)

Oh wow, that is amazing! It must require a custom script I imagine? Didn't think that was possible even with one and the S/R system, that's very impressive. Definitely curious about a few things: Does it distinguish between collisions with the glass and frame? If the arrow hits a metal part it shouldn't do anything, it should only break if the glass in particular was hit. If the lamp is triggered by a switch, does flipping it no longer turn the light on once it's broken? Can you use a broken skin rather than model? With some lamps it would be easier to only change the skin and replace the glass, of course both should be supported based on what works best for each lamp.

Ever since I worked on "Chalice of Kings" with Bikerdude, I have wanted to get flame particles with new particle glares into the core mod. My reasoning was that the candles have glares and the un-glared torches look mismatched. This proposal was met with mixed reactions, so (knowing the history of TDM feature proposals...) I have created a technical demo. You may download it here: zzz_flameglare.pk4.txt (fixed) Just rename without the .txt extension at the end and place it in your Darkmod directory. Here are some screens. Using particles for this is probably the wrong way to go now that Duzenko has an emissive light feature in his branch: http://forums.thedarkmod.com/topic/19659-feature-request-emissive-materialsvolumetric-lights/

I was confused by this as well when I first started learning DR, the user guide is now slightly out of date. Dark Radiant now uses a modular system that you can freely rearrange and add elements to as you see fit. In your screenshot you can see the buttons to add new cameras and orthoviews, which you can move or resize like a browser window. You can do the same with the UI that contains things like the media and entities tab and even drag them out into their own separate UI element if need be. With a little tweaking you should be able to approximate the Doom 3 editor layout by hand. Hope this helps!

It's okay! I'm down with any option hence why I asked. But I agree: Most players would likely not approve of such a change being done retroactively and affecting all old FM's, so it would likely be best as a derivative entity for mappers to use in the future based on new or existing lamps that can provide one. In any case it would likely require engine changes, not something you can currently do with a script: Lights already use their own hardcoded script classname which can't be overridden. Even if it weren't for that I don't think there's a way to intercept broadhead arrow collisions and check what kind of surface they hit, even with the Stim / Response system. There should probably be two new spawnargs: A breakable boolean enabling the feature on an entity, and a skin_broken to specify the skin used when a light was smashed.

"...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!

Cannot reproduce on Ubuntu 22.04. Although the Entity List can take a long time to load in a large map (painterswife.pk4) at no point does it lock the system or capture the mouse.

I don't know if it possible to do that is a very useful system that cod radiant use, you can place your prefab in your map go into it make your modifications and save them without re export your prefabs again Here's an example from my old map: Another example, select the prefab go into it Make modifications save them, leave the prefab and it'll be updated in your map

This is my second time opening Dark Radiant in another computer. When i open it i see this: ( i don't know why the image appears blurry here ) So far i see the Grid and the Camera are not scaling well. Notice that i am using fractional scaling in Ubuntu (Resolution: 2560x1440 - Scale: 150% - Refresh Rate: 165.00 Hz) System info attached system_info.txt

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.

The real St. Alban was a pagan who became a celebrated religious personality, this All Saints Day 2010 The Dark Mod places its own spin on this mythical figure. Screenshots: Intro: "'Business' has been slow lately, even more so after most of my gear got snatched during a Watch raid... I've since been forced to hit the streets and pick pockets for a living. But my luck was about to change, last night I was approached by a red hooded figure with a proposition... As we sat down in a dark corner of a nearby inn, he told to me that the Builders of St. Alban's Cathedral in the Old Quarter had recently unearthed a discovery that might lead to the final resting place of some saint." " But before I do anything, I need to get my tools and stash from the evidence room at the local watch station." "with the hawks, doves will congregate they will drop honey from the cliffs wine will surge over the earth the sheep will wander harmlessly with the wolf then the wicked will rise, but to retribution" - 'scripture of St Alban' There is a new version out now, see the following thread St Albans Cathedral version 1.6 Build Time: about 2-3 months. Thanks:- Huge respect to the Dark Mod team for such a great mod and for all the hard work they put into it and continue to put into it. Special thanks to Fidcal, Serpentine and others for their help on the forums and to Testing:Ugoliant, Baddcog, Grayman, Lost soul, Bjorn and Baal (for doing all the Vp work in the town. Readables: Ungoliant and Mortemdesino for all awesome work on the readables. Resource: Fids, Grayman, Ungoliant - guis, models & images. Misc: Loren Schmidt - the author of the map I based the cathedral on. Info: # Like Thief2, some things are climable, pipes, wall vines etc.. You can also drop some of the keys, some door that are frobbabe mean there is another way inside - explore u taffer! # Due to TDM being a lot more of a resource hog than T2 I have been forced to limit the number of Ai in the mission, but they have better placement than my last mission. # On all difficulty levels the player starts with vertualy no tools/weapons, there are weapons to be found - read, read, read! # For the love of all that is holy, read the briefing otherwise you will problems completing the mission. Known issues:- # This mission will have less than optimal fps at a few points on the map, mid range DX9 card(X1900/GF7800) or higher required. # On low end PCs I recommend, V-sync is off, AA is off, Aniso is 4x or lower and that any and all background apps are closed.

Particle collisions cannot be computed in realtime, particles are purely graphical effect which cannot interact with collisions. So the collisions have to be precomputed beforehand, just like dmap precomputes triangulations of brushes. Most of the nuances grow from here. It was possible in theory to run it automatically during dmap (just like e.g. you never have to run aas tool directly, because dmap calls it automatically), but I'm afraid it would annoy everyone because it may take quite a lot of time depending on settings. Now that some people have some practice with this, should we change it? Most importantly, collisions are precomputed statically. If you move the emitter, the collision information becomes wrong. All objects which seem dynamic are automatically excluded from precomputation, so the particles will still go straight through all the guards and moveables. What do you mean by "default" behavior? Default behavior of what? particles? Like make all particle emitters stop on collisions automatically? What about cases when mapper wanted particles to pierce walls? What about moving particle emitters? The goal was to reduce amount of work actually. As soon as you are able to set one huge particle emitter over the whole map, I think you don't have to mess with it any more, just remember to execute runParticle occasionally when you want up-to-date collisions. Before that, mapper had to split the rain patch into many patches and manually tweak every patch so that it stops at proper height. As far as I understand, it was very time-consuming and painful. As for areaLock, it does not restrict particles to single area. It only disables the whole system if renderer proves player does not see the specified area. As long as the door is open, you should still see rain falling indoors, no? Yeah, this is a tough question. Texture layout: Only works properly if particle evolves exactly the same way if emitted from the same location. Interacts with texturing: requires you to set non-overlapping texcoords in 0..1 range on the emitting surface. The only option in TDM 2.08. Ok for straight-falling rain, but snow is out of question. Linear layout: Only works for a periodic system, i.e. the whole system exactly repeats itself after some time. Precomputation might take a lot of time, especially if you insist on a large period. [problem for maintainers like me] If particle code is changed in TDM engine, the collisions must be recomputed. Was added in TDM 2.09. Supports pretty much any kind of particles, although snow was the main goal.

Yeah it would be cool to see some more detailed statistics and it’s a shame they aren’t really captured. Since we are talking about fan mission platforms, where players also make the content for the game, I feel like the best thing we’ve got is you can look at the number of content releases for the games. Keep in mind the graph counts campaigns as single missions - so for example NHAT and TBP both count as 1 mission. A good year for TDM has has approaching maybe 50% - mostly we’re 25-30%. https://www.ttlg.com/forums/showthread.php?t=152494 You could also look at the number of ratings thief missions get on https://www.thiefguild.com/ vs TDM ones, but that is pretty iffy in that you could chalk that up to more awareness of the site in the thief community than TDM Out of curiosity is there a reason a thief player can’t be a new player? I kind of think a player is a player and new players would be ones who are playing the dark mod who weren't? Is there disagreement the base of players most likely to pick up the game are fans of the thief games? They are certainly the most fruitful place to find feedback on the game beyond the sphere of this forum that I have seen. When we were trying to finish up SLL there was a lot of discussion on the forums about how long it had been since there was a release for the game. I am thankful that the stats show at least some stability over the years in terms of releases for TDM, but the trend for all of the games is decline. Not doing anything is a valid response if that’s what the devs want to do - it is not possible to provide evidence that any effort will slow that inertia. As a player and content maker I would just prefer trying to find feedback where it is offered from players who were willing to try the game but ultimately could not engage with it and see if there is anything that can be done within reason to ease them into the game. The game has a lot to offer imo. All those players are potential contributors - contributions in turn attract players - it’d be nice to see the cycle go on as long as it can.

dev17008-10685 is available. Speaking of the new parallelization, it would be great to check that the new version does not get slower than the older ones The only different there is number of threads used in jobs system. Previously it was always 2 threads, now it is (NumberOfPhysicalCores - 1). However, detection of physical cores number might be buggy --- the numbers are reported near the beginning of game console.

People who use Blender for object editing sometimes run into a problem with material names. It has a character limit of 63. That's usually fine but some existing TDM materials have names which are longer than that, so it becomes impossible to use them. An FM author can make a copy of the material with a shorter name, but that might be adding unnecesary complexity for people who are just making standalone objects to share. I've been mounting a valiant campain on various Blender forums, and some of their LinkedIn posts, to get them to increase the limit, but to no avail. So it's time to take a different approach. Would it be feasible for TDM to rename long materials? The rendering system would have to intercept and replace calls to the original names, or something like that. I'm not sure if that would be an easy thing to implement or if it would set off a chain of complex events or coding etc. Another possible approach could be a material ID sytem, so in Blender the material name could be WoodPlanks_4ACFB987B, which would correspond to something like TDM\long\path\to\material\WoodPlanks That might even be beneficial for shorter material names, as even they are not user friendly to look at in some interfaces.

Oh no, that's not how the Steam Deck works. On a computer, each key is programmed to do only one thing.In any game, when you press "F", the system will understand that the "F" key was pressed. But on the Steam Deck, I have to assign functions to each key myself. For example, I can make the "A" button act as "space" and the left trigger as "right-click". That's why I'm saying that opening the console on the Steam Deck is difficult. Even though it has a lot of buttons, I have to temporarily program three keys for functions that are not really used.

well decided to have a look at setting it up on solus and ... it does not exist as a package. you can still build it yourself but there are some pitfalls. timeshift relies on dcron which was removed from solus so you have to create the auto backup sequence with systemd yourself (i hope your good at scripting). create a textfile, name it "timeshift.service" with following content: [Service] ExecStart=/usr/bin/timeshift --check Create a second textfile, name it "timeshift.timer" with following content: [Unit] Description=Run timeshift --check [Timer] OnBootSec=10min OnUnitActiveSec=60min [Install] WantedBy=timers.target` copy both files to /usr/lib/systemd/system (-> sudo cp timeshift.service /usr/lib/systemd/system # same for timeshift.timer) Now enable the timer: sudo systemctl enable timeshift.timer you might need these dependencies before building timeshift. sudo eopkg install libgee libvte rsync dcron libjson-glib even though dcron is listed as a dependency it does not work with solus because it is systemd based.

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

For an as-yet unknown reason, this commit seems to break XML parsing on Linux: #6439: Use xmlReadFile instead of xmlParseFile which has been deprecated and removed. Privatise Document() constructor accepting an xmlDocPtr. As far as I can see, the commit is entirely correct. xmlParseFile is indeed deprecated, and the new usage of xmlReadFile matches what the libxml2 examples are suggesting. But the result is that although the xmlDoc* returned from the function is not NULL, nothing XML-related works, the entire registry system returns only empty values, and almost all of the tests are broken (because the main radiant core cannot be initialised without any registry values available). Changing back to xmlParseFile makes the problem go away but is an unsatisfactory solution because it specifically reintroduces a deprecated function call. I am not sure whether this is a bug in the specific version of libxml2 on my Ubuntu system, or something incorrect about how we are calling xmlReadFile (i.e. perhaps it requires an encoding or a particular non-default option to correctly process our XML files). Unfortunately like many of the core GNOME C libraries, the documentation is bare-bones and explains almost nothing (like what any of the parsing options actually mean), and I cannot see an obvious way to ask libxml2 to return meaningful errors, or to query exactly what might be wrong with a constructed xmlDoc* object. It makes me wonder if it would be better in the long term to ditch the reliance on libxml2 and instead use one of the light-weight C++ XML parsing libraries like RapidXml or pugixml instead. Not exactly a trivial change but might not be too cumbersome since the existing XML code is wrapped in our own xmlutil classes and not generally used directly by the rest of the codebase.

Yes, the stim/response system allows for this kind of thing. Easy enough to emit a custom stim around the lantern and put a response on all photophobic AIs to that stim. The response script would check whether the photophobic AI is within the lightbeam, then call a flee function on it. The main problem is that the flee function is unreliable if the AI is already busy with something else.

This is a different issue than the click of sound at the start of every transition that I was talking about in earlier posts that you're referencing. This may be a problem that's always been there but nobody really noticed or commented on it, or maybe only for certain ambients? So the first problem is that the ambient starts abruptly at game start presumably because the sound system isn't online yet to process the fade in, and it just starts the ambient at full sound. So then you added a delay, but since you're not coming off of a previous fade out to sets the volume to zero, it plays the full volume ambient through that delay and then cuts to zero and fades in. My idea is that if you want a fade in from the start, don't start with that ambient as it is. Start with a .1 second of silence, and then fade in the ambient. There are two ways I can think to do that. (There might be other ways.) 1. Some ambient soundshaders start with a "leadin" spawnarg that starts it with a bit of silence, originally used to stop the click of sound (soundshaders ending in "_z", there were two versions, one with and one without the _z, unless that was later changed). You could confirm that the soundshader for that ambient uses a "leadin" arg, or if it does but it's not long enough, maybe use a custom soundshader to use a longer leadin blip of silence. (In that case you'd have to make the longer silence file yourself.) 2. Or another possibly easier way may be to start with an "override" sound, look at the Sound Override part of the tutorial with silence, and then after .1 second or whatever, transition that to the normal location-based ambient according to the instructions, and then the override sound will fade out and yours will fade in. I think you'd do that by setting the override arg to "1" from the start and then change it back to "0" after 0.1 seconds using Target_setKeyVal as the instructions say. Confirm that the "silence" sound is stereo. I noticed if you start it with a non-stereo sound, the system stays non-stereo. I think that was fixed, but good to double check. If it isn't, then you could do the same thing with a normal ambient that just starts off silent or very quiet for that first .1 second.

Updated my previous post with youtube vids. Youtube is a lousy website for this kind of thing, though... If only imgur wasn't being a crap... Anyway, my system is old and slow, yea, but I'm not sure this has to do with that. This seems to never happen to me in other people's missions, and in my missions it's only the first time I enter a location. I've also had @Mat99reporting having this issue with my mission as well, but I don't know what kind of system he has.

I think the default gamma was raised to 1.2 to reduce banding and color precision artifacts at the low end of the brightness scale. There are probably some confounding factors that make that a questionable decision. 1) At the time of this discussion, I believe TDM's bloom settings were generating extra contrast and thus lowering gamma 2) By the time that soft gamma was implemented, we also were using a new bloom system that does not tie the bloom effect to other post processing effects 3) There was some attempt to make TDM shaders compliant with industry gamma defaults but that attempt to adhere to standards may have caused problems because most games are much brighter than TDM so using calibration established for use in brighter games may cause unintended results. These days, I normally set gamma to 1 ambient gamma to 1.1 and set my postprocess color curve to 0.2 or 0.3 which darkens gamma back to something similar to 1. Maybe someday I'll purchase a monitor calibration machine and try to sort out the ideal default state.

For proposal #1, I imagine making a mission fitting seamlessly between the two stock missions in TDM would be a tricky endeavor, truth be told. The first mission is a small tavern robbery and the second is a modestly sized church break-in with a very reasonable jump in difficulty—fitting a mission snugly in between these two in terms of difficulty and scale is a high bar to reach. A contest to make a sequel to "Tears of St. Lucia" sounds more reasonable and would probably flow better for someone playing all three for the first time. I'd probably avoid doing something TDS related when a similar contest that allows Dark Mod entries is already ongoing, but proposal #3 sounds fun if we're given enough freedom to wildly reinterpret a Thief 1 mission. I'm somewhat mixed on the slot system as it really comes down to whether or not you want a full campaign with no repeats out of this contest. I personally wouldn't mind playing 2-3 different interpretations of something like the Bonehoard, it's bound to be interesting seeing what elements of a mission FM authors focus on.