STiFU

Yes, while Saint Lucia and A New Job are a little different, seeing that they are parts of the official introductory campaign, we usually use the bugtracker only for engine and core asset related issues. Please use the respective FM threads in the future.

Infinifactory now free on Epic. Great automation / optimization puzzle game. Had quite some fun with that one.

It stands for campaign or single mission.

That bug report could be interpreted in two ways: One, the ingame-downloader-sorting needs changing, Two, all other lists needs changed sorting. The current sorting does not even resolve the issue as the sorting is still different from the missions web page.

CMOS all the way! It is in a way truly alphabetical, while allowing for efficient searching, and it is a world-wide standard way of sorting things.

It was most definitely the shortcomings of T3 that spawned the development of TDM.

To be fair, he has put forward a lot of evidence internally. There was a huge (and heated) discussion and we eventually landed on a compromise. I totally understand, 'though, how you feel like this comes out of nowhere. I get it. This!!!!! Absolutely this! I have been arguing for something like that for years, but I do understand the arguments of those opposing this. At least you can sort by release date now.

It is already implemented. This is exactly what my extension of the new control scheme does. tdm_holdfrob_drag_all_entities Have fun, mate! EDIT: Correction: Sorry, I misread your post a little bit. Only for extinguished lights and food remains, the hold-type-grabber is used with my extension. For lit candles and food, short frob is still grabber and long frob is extinguish / eat. The thing is that there are plans to keep only one control scheme on the long run, which I am totally against, 'though, see below. I have already commented/suggested internally that the frob-code needs refactoring anyway, and if we were to do that for 2.13, we might as well introduce a simple switch. Basically, the code would determine if short frob or long frob has been pressed and then decide which action to perform based on the chosen control scheme. And for your information, my preferred solution has always been to keep the original controls, but have long-frob as a shortcut for frob + use. This might be an option with the proposed refactor. Let's try to keep the discussion constructive, please. There is no need to make it more heated.

I think that was directed at me, as I usually argue for the new control scheme (albeit with some modifications). I liked that post because it contained some valid points of criticism: Especially the first point frequently happened to me. Yes, the new frob-to-loot feature is there to help, but I still sometimes accidentally shouldered a body.

You can buy a displayport to hdmi adapter very cheap.

How you get from Prey, an immserive sci-fi game, to BG3, a D&D fantasy cRPG, is beyond me, but it sure seems to be a good game.

You are effectively using a different GPU when using the onboard VGA port, which raises the question, what CPU / onboard GPU are you running? My bet is that your 2 Gigs of VRAM are simply insufficient for running Iris at Full HD. Could you try a small FM like "The Parcel" with the new monitor and GPU?

It was mainly the overhead mantle with its long initial hang-phase, that was shortened, while everything else was just minor adjustments. The hang-phase really was extremely long and shortening that was a good suggestion in my opinion. However, I do agree that we went a bit too far with the adjustment. One might argue that a very short hang-phase is realistic, when jumping upwards with high velocity. Conversely, it is rather unrealistic when falling fast, which is why I had internally proposed to keep a longer hang-phase when falling fast. That suggestion didn't gain a lot of traction, 'though, and I did not want to stretch the discussion even further, so I just did not follow up on this. By any chance, did you also try the extension of the new frob system where the hold-type-grabber is used not only for limbs, but for all junk etc.? You can enable it with tdm_holdfrob_drag_all_entities. What are your thoughts? I had implemented that in order to make the new system a bit more consistent.

Maybe reducing the cvar in_padDeadZone will help. Documentation on controller support: https://github.com/fholger/thedarkmodvr/wiki/Gamepad-support Having said that, it is usually sufficient to crouch-walk, i.e., creep not required.

I doubt that we have the man-power to pull that off these days. Since TDM has no actual legal entity, nothing can really happen to anyone of us other than a request to take it all down, which we would happily oblige of course and then start to fix up the critical textures. I am sure, once the need to fix them up is actually there, the man-power will naturally reactivate for TDM. I also doubt that anyone would come after TDM at this point, as it is a beloved community project that had tons of news coverage in the past and the creators of textures.com know about and approve of us. I was also trying to find our internal discussions about these licensing issues, but couldn't find them anymore. Maybe @nbohr1more knows any further sources?

Oh that was my bad. I had it the wrong way around in my head. My mistake, all good.

Store the attached files in your darkmod folder. Activate old vs new speeds via "exec OldMantleSpeeds.cfg" or "exec NewMantleSpeeds.cfg", respectively. I am surprised to find that pm_mantle_pullFast was actually decreased by 50 ms. I did not catch that during Code-Review. Why was this done? Now the regular pull and the fast pull are almost identical. NewMantleSpeeds.cfg OldMantleSpeeds.cfg

You got the short answer because you presented incorrect information "our save system steals your acquired loot" and you asked for a change in functionality in a very pushy way. The correct way to start this thread would have been somethine like the following: Please note that all developers, myself included, work on TDM on their freetime for fun and for free, and pushy requests like this and offending developers are the most efficient ways to NOT get something implemented in the game. (Asking for "a real admin" doesn't help your case much either, I am afraid)

100% correct. Also, in some cases, you might want to create a named save and then revert to your latest quicksave. This would not be possible of quickload were always to load the latest save. @CrisiusXIII now that you know how typical saving systems work, I suggest to use this very easy workaround: After creating a named save, either remember next time that your latest save was a named save and load that the regular way, or simply create a quicksave after the named save. However, then I would ask, why would you even create that named save in the first place?

That sort of tone doesn't fly in our forums.

Quickload loads your quicksave-slot, not the latest save. It's as simple as that. FYI: Your thread title is wildly misleading.

This extension of the new control scheme is included in 2.12 beta. If you want to try it, you can enable it through the cvar tdm_holdfrob_drag_all_entities.

DEATHLOOP has never been a stealth game. It has some stealth mechanics, but it is clearly intended to be an asynchronous multiplayer shooter with mild rogue-elements, wrapped in a nice mystery-adventure. Honestly, the gameplay idea is genius, but you have to like multiplayer in order to be able to really enjoy this game. Playing it offline is really not as exciting.

Other than Redfall, Arkane really didn't do anything wrong in recent years in my oppinon, and that game was publisher ordered, so it doesn't count! DEATHLOOP is awesome, if you embrace the multiplayer part of it.