Search the Community

So heres is the beast up and running the app in the screen is KDE Connect SMS in case you were wondering. Only problem so far is one i had with several distros... the wifi driver for the broadcom BCM4360 is inherently unstable at times and does not even get close to the speeds it is capable of on windows 1.3gb vs 135mb yuck it also has a habit of random disconnects when moving a lot of data so not really a good wifi card to pair with it, sadly it is built in to my mainboard and i dont have a spare atm. as for gaming the titles you can see in the screenshot all run quite fine with some performance deprecation due to being windows games but i have to say proton has come a long way allready. older games are actually more irritating to get running sometimes, timeshift outright crashes and i have had no luck getting it to run yet, wheel of time runs but required some tinkering because the gog version uses a ddraw wrapper for the quicktime video codec so i had to make some alterations with lutris environment variables to get it running. eg. go into runner options DLL Overrides add a new key containing ddraw in field one and n,b in field two. this tell wine that the game uses its own ddraw.dll and to not touch. lutris strangely also set the game executable to the quicktime player so i had to correct that .

Isn't that what I'm experiencing, though? You can hear it in JackFarmer's video (3rd post). It seems to fit the description.

I don't notice an issue with moving at map start. Do you mean you can't move at all? There are a few small furniture pieces around the player that might cause you to be unable to move further in certain directions. The only time I immobilise the player in that FM is when a cutscene camera is activated, long after map start. I didn't know about immobilisation flags back then. Thanks for the subtitles!

The King of Diamonds Info Summary: Your accomplice is in over their heads and needs your help. It's the end of winter and the streets are quiet. Taverns, city watch, graveyards and pipes... you might even encounter a diamond! Build time: about 6 months Type: City FM/Exploration Size: Medium Completion time: 30 mins - 3 hrs, depending on how much you're willing to explore! Download http://www77.zippyshare.com/v/Z1fZy41Q/file.html - Zippyshare https://www.dropbox.com/s/428jkpoi14544pd/kingofdiamonds.pk4?dl=1 - Dropbox Available via the In-Game Mission Downloader! Screenshots Notes This is my first TDM FM, it came about from me learning how to use the editor and all of its different features. No doubt, you may see the variance in quality between the FM's different sections. Have fun figuring out what I built first and last, hah. For the most part, I focused on exploration and interesting readables. You'll find that you can complete the main objective in about half an hour, if you know what you're doing and that's perfectly fine, but if you're not getting lost and exploring, you're missing out! Big thanks to Bikerdude for his help throughout the beta-testing phase of this FM - fixing a lot of performance hitches, putting some bells and whistles and introducing new spaces that allowed me to expand greatly on the FM's readables and objectives. Without those, and my beta testers' further suggestions, this FM would be decidedly more boring! Acknowledgements Mapping credits: Bikerdude - Re-visportalling half the map, SE Maketplace, Graveyard, Bell Tower, SW street, misc. Spooks - the rest. Readables: Spooks Voice work: Goldwell, Bikerdude, Spooks. Beta testing: Aosys, AluminumHaste, Goldwell, Oldjim, nbohr1more Lute songs from No Honor Among Thieves. Breath script from Business as Usual. Technical Info Version 1 Last Updated: 13/05/2016 This mission has a very open layout. Even though a lot of care was taken to ensure performance would be good, it's bound to fluctuate at long view-distances. If you have an average computer expect some dips to the 30s. You have my apologies for that.If you're having FPS troubles, try setting your LOD Detail menu setting to Low. Numerous objects will have their shadows disabled, which may improve performance somewhat. I also recommend typing tdm_lod_bias_changed in the console when you're in-game, just to make sure all LOD entities have been activated.This mission does not support localization out of the gate.This mission requires TDM version 2.0.3.FAQ Stuck somewhere? I've some hints for you in the FAQ section. Enjoy playing and remember to be kind to Birdie!

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.

Related to looking into the stray marks associated with Stone font characters... I've noticed that the nominal 12 pt DDS (which as discussed above only kicks in under 8 pt) has only ASCII glyphs... nothing with code points above 127. Maybe that's why the corresponding 12 pt DAT file was not distributed, as a workaround to force the engine to use 24pt instead, because tels never got around to finishing the low-priority aspects of the project. The 24 pt DDS does have the ANSI glyphs. At a glance, most are fine; a few are a bit ragged. I didn't check compliance and completeness with TDM's character map as given on the wiki. I don't feel ANSI improvement is a 2.12 item. I've got a test FM to show all the characters. At some point, after refinement, I'll post a link.

Hm, I am not sure I follow. Shouldn't the behaviour of the Rim shader be independet of actual geometric complexity and normal map based complexity? If the answer is yes, then brushes should also look fine because the applied material provides geometric complexity. Reshade is awesome. I use it all the time to improve the visuals of old classics. The Post-Lightmaps-Era games just look so much better with some SSAO...

TDM Modpack v3.8 released in the opening post Introducing... the SHOCK MINE MOD v1.0 We must thank @wesp5 for this one! Flashmines are a rare item nowadays. Shortly after production begun blueprints of a more practical equivalent made it into the streets and Flashbombs took the market by a storm. To make matters worse, Flashmines had a critical flaw and the inferior chemical components degraded over time and Flashmines were quickly known to have caused misfortunes. The Flashmines that remain in the black market are now old, unpredictible, and dirty cheap. "I am not interested, chap. Too dangerous! A single spark and I am out of business!", could be heard from a merchant in a tabern. Later that evening a few Flashmines had a new, mysterious owner. A couple of nights after the first altered Flashmine was put to the test with shocking results. The original "Electric Mine" can be found in wesp5's Unofficial Patch. Stims are, in my experience, unreliable and for this new take on the infamous mine I ended up scripting everything. New sounds, different effects... but more importantly, KO's are now credited to the player. A Shockmine is a powerful, silent weapon that can put most of your opponents down but be careful, Shockmines can be deadly. Whenever you stumble across a Flashmine just grab it! Our protagonist knows well what to do with it. Big thanks @wesp5 ! HUNTER BOW MOD v1.1 Something that buggered me from day one is the mandatory reload when you miss a shot with the Rope Arrow. The Hunter Bow Mod has been upgraded so that when you miss the shot you have the opportunity to retrieve the arrow. Sometimes arrows will land in inaccessible places but hey, you at least have a chance now. CLASSIC BLACKJACK MOD v1.3 A little update to conclude the "It Just Works" exercise. The blackjack is now as reliable as it can get... KO guaranteed: no indicator and no quick-save required. FLASH GRENADE MOD v1.1 Flashbombs no longer clip through the world and the script has been greatly improved. There is no way Flashbombs can fail now: if AI are within range and sight, AI will be blinded. I consider this the definitive version. --------------------------------------------------------- Thanks to @Dragofer & Company, The Dark Mod 2.12 will allow different mods to coexist so expect a reorganization of the mods included in the pack sometime early next year. Until then, have fun with the TDM Modpack! The download can be found in the opening post. Full changelog: ============================== v3.8 - New release ------------------------------ • STANDALONE SHOCK MINE MOD v1.0: Initial release. • FLASH GRENADE MOD v1.1: Resolved clipping issues, better AI blind detection. • HUNTER BOW MOD v1.1: Retrieve rope arrows when missing shots. • CLASSIC BLACKJACK MOD v1.3: Improved collision detection. • PLAYER SKILLS MOD - DISTRACTION v1.4: Revised mod, new method. • Modpack: Minor general corrections. Cheers!

Oh boy. Thanks for investigating this, reading the issue description I suspected that the XPath queries might be failing, but I thought it was rather due to the libxml2 version used in newer Ubuntus. I recall now that the automated Ubuntu build on Github is not running the unit tests (couldn't get it to run and gave up at some point) - so I missed that this is breaking stuff. I searched around for existing code to find out what to pass for that encoding parameter in xmlReadFile, but I couldn't find anything useful, everybody seems to pass NULL as argument, which I ended up doing too. I'm all for that, I was that close of doing it when I upgraded libxml2 for Windows. As long as it's supporting XPath and XML Tree manipulations, I'd go for the most light-weight one, maybe even header-only. Our libxml2 usage is confined to xmlutil, so it should be possible to switch. edit: I'd vote for pugixml, it seems to be still alive and has XPath support. It's what I've been using in the TDM game code too. But still, if it's the tree manipulations that break the queries, we can either try to find out what we are doing wrong here, or move away from pushing the .game data into the registry trees - it might not be necessary after all, since most (if not all) code is relying on the GameManager interface to get do the queries. For the moment being, I can revert the change to xmlReadFile, so that my repo is functional again. Are you still investigating this? You seem to have gotten quite far already.

I don't consider this an urgent or highly important feature, but found the concept useful enough to ask and may definitely use it on my maps. I actually don't know if it might already be implemented: No FM I'm aware of does this and it's not mentioned on the AI Relations (Editing) page either, however the AI Relations (Scripting) page mentions a gradual sys::OffsetRelation function but doesn't specify if it's also a gradual change in the AI's behavior. When setting team relations you normally have just 3 options: -1 (enemy) 0 (neutral) 1 (friendly). There is one limitation in this system: They seem to be integers and not floats, meaning you can't also express an amount by which the teams should be allies or enemies. Having this ability could have interesting use cases: You may want teams that still oppose the player but don't care that much and will only attack if you get right in their face or stick around for too long. As such you should be able to use values between 0 and +1 or -1 to indicate an interest level in the relationship, as well as values above +1 or below -1 to boost the AI's friendliness or hatred toward another team beyond its normal levels. Consider for instance a FM where thugs protect a territory they own: They don't like the player wandering into their turf, but seeing you is more of an annoyance than an emergency... they aren't as motivated to catch you as a citywatch guard who knows the player is a wanted thief and will immediately jump to apprehend you. In this scenario the relationship between thugs and the player could be changed to -0.25: Now you can walk between thugs for a few seconds and they will ignore you at first, but if they see you for too long you're eventually getting attacked. A super simple implementation would be to merely multiply the AI's alert increase rate from a target with its abs(relationship) toward it: If you set it to -0.5 for instance, AI on that team will take twice longer to be alerted by you until eventually attacking, same for allies who will be slower to notice a friend in trouble... meanwhile if you set it to -2 AI on that team will go alert twice faster than normal. I presume this solution can be done by changing one line somewhere in the alert code, and should have the accurate behavioral effect intended without reducing visual / audio acuity... no existing FM or default behavior should be affected either since I can't think who would be using those values if this feature doesn't already exist.

Hi folks! Since today, long awaited features of mission management are available on our portal. Mission reviewing is also here at the same time! For more information check out the post here: https://www.thiefguild.com/news/1/9443/the-guild-of-creators-and-players Creator Account description: https://www.thiefguild.com/showcase/creator_account How to review missions: https://www.thiefguild.com/showcase/reviews

OK. Thanks! In my case the issue is moot because I don't know how to do it. Hence my plea for help... If an FM author built their mission using assets that are licensed CC-BY-NC-SA (which I believe all do), if I understand correctly then that means they must license that mission under CC-BY-NC-SA too. Which in turn means anyone can build further on their work as long as they follow the conditions stipulated in the license. It seems odd to release a work under a certain license and then say "but I don't want you to do what the license explicitly grants you to do". "Applying a Creative Commons license to your material is a serious decision. When you apply a CC license, you give permission to anyone to use your material for the full duration of applicable copyright and similar rights." (https://creativecommons.org/faq/) If an author once benefited from the license when they created their mission, why would they not want others to benefit similarly from the same licenses? The license requires their name be mentioned in every remix that follows. At the same time I can understand that some creators more than anything want to create. The desire and drive to create may be so great that they accept conditions during the time of creation, to give them artistic freedom and to use the best available assets; contitions that they regret later when their work is finished and published, and they want to keep control over it. For the OMs I think the project as a whole would benefit from a relaxed and welcoming stance towards changes.

Time ago it was discussed here about Hearing Impaired and Hearing Unimpaired modes. Nothing was decided back then and now we have everything. This actually turned to be a good move because code-wise we now have lots of tools at our disposal but, in my opinion, by firing everything at all players we may end up alienating many / most. I want the average player - interested in subtitles - to keep subs enabled and have a good time enjoying the good work done here and elsewhere and I keep working on an alternative: Alt Subtitles for 2.12 v0.1 Background replaced with a (fake) font outline Widget removed (too many things to focus on) Text transparency based on distance (imperfect) Story subs can take up to three slots Barks limited to a single instance Yellow color for story subs (intensity reduced a little from previous attempts) Light grey color for barks It is far from perfect but it may lead to other ideas. Download the pk4 attached to this post and move it to your root folder. I suggest taking the Braeden Church mission for a spin. Delete the pk4 once testing is complete. z_alt_subtitles_v0.1.pk4

At least for bark subtitles, fast readability is important, because they shouldn't be on the screen much beyond the vocalization time, and for fast talkers, that's not real long. Of the existing fonts available, Carleton and Stone are the easiest to read quickly at a glance. If you were going to allow a different font for story subs, assuming they are generally articulated at a more leisurely pace, then you could consider a more "themed" font. Still, a lot of TDM fonts are pretty slow to scan/parse.

I understand, and I would distinguish between the two possible cases where * we make money from it, and * someone else can make money from it. As long as we don't make money from it, it should not get us into trouble, right? I also don't see further formalization as as a requirement, so both pillars can remain intact. If they licensed their assets under CC-BY-NC-SA then that licensing prevents their assets to be monetized without their consent. I don't see how a creator can object to which license other creators choose to use, or if others choose to monetize assets they create. Also, even if a creator once licensed their assets under CC-BY-NC-SA, it doesn't prevent themselves from monetizing it. It's their assets. (They can't revoke the CC-BY-NC-SA license, nor is that necessary.)

Well, I hate to be that guy, but as a researcher who has done tons of subjective tests with big subject groups, I would like to jokingly comment that the used test procedure does not allow the conclusion that people prefer short press frob for shouldering. What we can conclude from this poll is that people prefer short press frob for shouldering as well as various other actions AND long press frob for alternative actions in favor of short press frob for various actions as well as double-press frob for alternative actions including shouldering. This is the classic error of modifying too many determining factors between test cases and attributing the results to only one of the determining factors. However, I don't question that there is strong agreement with making shouldering the primary / short-press frob action. This has been criticism of TDM for a long time. We've had people coming to the forum asking for shouldering over and over again. So I concur to change this and set it as the new default even.

I quickly hacked this in yesterday evening and it actually worked quite well. Having the option to both toggle-type-grab and hold-type-grab junk objects is a nice quality of life feature to me. It actually worked for most loot and inventory items in the training mission as well, so that's also pretty cool. However, what isn't so cool is that food remains, unlit candles or candleholders (that never even saw a candle) are not treated as junk objects so the hold-type-grabber ist not applied. This requires some more coding logic, but should be fairly doable. So basically, above table would have to be altered in the following way. With this adjustment, long press would always execute a special action first and would then consistently degrade to hold-type-grabber. Entity type Short Press Long Press Junk Toggle-Grabber Hold-Grabber Food Toggle-Grabber Eat Food remains Toggle-Grabber Hold-Grabber Loot Pick-up Hold-Grabber Bodies Shoulder Hold-Grabber Lanterns Toggle-Grabber Extinguish / Light Lit Candles Toggle-Grabber Extinguish Unlit Candles Toggle-Grabber Hold-Grabber Tools Inventory Hold-Grabber

This is false. The quick-press frob action never happens before or after the long-press frob action. The single-click action always happens before the double-click action. You stated the following about double-click: Long-press frob to extinguish a candle never moves it. Double-click frob to extinguish a candle always moves it slightly. Therefore, long-press frob works well for ghost players whereas double-click frob does not.

We had extensive discussion of why our license is the way it is, especially when we were going standalone. There are reasons it's CC-NC-etc., and one of the big ones is that anything that tries to link the mod with money and formalization has been trouble for us, like team-breaking trouble. Well the asset license was settled long before that just in dealing with the contributors (and the engine came with GPL3 from the start of course). There would be asset creators that would (rightfully) riot if money were able to flow to some creators and not to them, because they didn't spend 1000s of hours on this mod for some knucklehead to spend 2 hours for some crap whatever and get paid for it. But the debates happening during the run up to 2.0 validated it. But even before that, we've talked a lot about the basic principles for how the team works, and avoiding entanglements with money and formalization are like two of the central pillars that most of us (I understand) wouldn't like to open back up to debate. What I see from this whole line of discussion is that you want to make a branch project with the engine. That's fair by itself. The engine license let's you do that. But it's something that should be a true branch, like you ought to make your own forum for it and develop it there. Then I think it's fair for you to let us know it's happening and even ask if anyone is interested in joining you there, and some people may want to do that. But I think it's best if you branch off and develop it separate from this forum and team if you're going to drop one of our central organizational pillars in what's gotten us this far.

I am less familiar with the MLA Handbook, so I don't know what (if anything) it says about how to account for definite and indefinite articles when sorting lists based on titles. I can't find anything about it online. Let's hope they don't come after us if they find out and disagree. Edit: According to the link I provided in my previous post, "MLA style follows the The Chicago Manual of Style", so there is no conflict between them.

Now the subtitles use volume modifier, it's called "gain". This gain is passed to OpenAL along with .ogg file data to play. In order to determine how loud that would play, it is necessary to read the .ogg data, compute some kind of amplitude, then add gain to it. The amplitude should be computed with some pretty long time window, so it's better be accumulated continuously.

I've been asked to post about the increased mantle speed in 2.12 as some folks have been curious about the change. After a lengthy internal discussion along with testing and input by several mission authors, it was agreed internally to increase the mantle speed. But during 2.12 beta testing, we would like feedback on any bugs or issues that you find. The reason for the change was to address feedback from players that mantling was "painfully slow", "slow and clunky", "mantling sucks - it's just slow", and so on. Several mission authors supported making mantling faster, and so the dev team decided to tweak the mantle speed. There were multiple implementations with the final implementation being a compromise. Also, the dev team studied some parkour techniques to ensure that the mantle phases and timings were good enough. The changes include: The original mantle phases were kept as that is what longtime TDM players are used to, and only the duration of some phases were reduced. Changed the pull animation so that it has both acceleration and deceleration rather than just deceleration. Tweaked the swaying back and forth a bit to work better with the increased speed. When the player in forced into the crouch position at the end of a mantle, crouch near the end of the mantle rather than the beginning in order to remove the sudden "dip" of the player's view. A majority of dev team members were against adding a menu setting, so being able to toggle between the old and new mantle speeds will not happen. It is recommended that you try out different "Mantle Roll" values as some prefer "0.1" and others prefer "0.5". We hope you all enjoy this adjusted mantle speed, especially the overhead mantle, which is now more consistent with the other mantle types. Bug tracker: https://bugs.thedarkmod.com/view.php?id=6343

Looking at the code, the originals were "pm_mantle_pull 750" and "pm_mantle_pullFast 450". The new "pm_mantle_pull" value is "400". A "pm_mantle_pullFast" value of "450" would be slower than regular pull, not faster. With both being set to "400", they are at least similar. Other than that, it's subjective and the feedback from playtesters was positive. Also, referenced internally here: https://forums.thedarkmod.com/index.php?/topic/22256-movementcontrols-settings-in-main-menu/&do=findComment&comment=489158

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?

See this post: I wonder if it could be modified so that the set_frobable could be done when box is at a quarter of open animation. I think that this has to do with frob-distance and/or if the container where the item is in also has frob-higlight. It think that when the box is opened, frob-highlight for the box-body should be enabled. So the best would be probably: If box is closed, whole box should have frob-highlight enabled. When box is open, only lid should have frob-highlight enabled. This should be applied to all core prefabs. I also have this sometimes with messages sticking to doors, where it is very difficult to frob the message or door.