STiFU

Hi everyone, I know I am pretty late to the party, but I have been doing some playtesting of this feature and I am honestly loving the way bodies are handled now: hold mouse to move it around, release mouse to drop it again (hold-type-grabber). It just feels very natural and somewhat authentic this way. I love it so much that I would like to see it optionally extended to all grabber-interactions. I also think that the new control scheme is a bit inconsistent because, depending on entity type, different kinds of inputs are required to achieve the same game functionality (the grabber). Here is a table showing how different entity types are currently controlled: Entity type Short Press Hold Button… ...Release Button Junk Grabber Nothing Nothing Food Grabber Eat Nothing Loot Pick-up Nothing Nothing Bodies Shoulder Grabber Release from Grabber Lights Grabber Exstinguish Nothing Tools Inventory Nothing Nothing And here is a suggestion of how I would change it to make it consistent and to have more objects use the fun hold-type-grabber from bodies (of course the release from grabber by button release could be made optional such that a second click would release from grabber) . Entity type Short Press Hold Button… ...Release Button (or optionally press again) Junk Nothing Grabber Release from Grabber Food Eat Grabber Release from Grabber Loot Pick-up Grabber? Release from Grabber? Bodies Shoulder Grabber Release from Grabber Lights Exstinguish Grabber Release from Grabber Tools Inventory Grabber? Release from Grabber? All use-type interactions would be on short-press, whereas all grabber-interactions would be hold-type or on long press / press again. In addition to being more consistent, this control scheme also has the advantage that the grabber is always intentional, i.e., you never accidentally pick up a junk object. The only downside I can see right now is that, with the hold-type interaction, object rotation is a bit more finicky with the hold-type-grabber, because you have to press two buttons at the same time, but it's absolutely doable (I tried).

Ahhh, so that's what the x-rays feature is. I read that term multiple times, but its development must've fell into one of my inactivity phases.

Can't believe I missed this FM and played this now almost two years late. Congrats @Wellingtoncrab, what an incredible achievement. I loved every bit of it and it is sooooooo beautiful! Those volumetric lights really go a long way!! How the hell did you pull off I also loved the idea that you start out with almost nothing and have to acquire your tools, which kind of introduces some metroid vania elements to your FM. And that writing... Damn! If I had to be really nitpicky, I would say that your FM had too many tools scattered around that you don't really need. Tool scarcity is always a sure-fire way to create tension, so I think your FM would have been even better if there were less flashbombs, water arrows etc., and more loot instead.

Haven't read the whole thread, but my theory is that this happens when you have already picked up the key the other guard (pool area) is wearing.

I fully agree. And I also love the visuals. They are just fitting and perfectly resemble what I imagined Citadel to look like when I was a kid. Here's what I wrote about the game:

I feel like these efforts should go into the ingame mission viewer rather than an external application that most people are never going to see.

I honestly think without the survival aspect, you'll lose interrest even quicker. Survival games are all about overcoming harsh living conditions, whilst improving your gear, which gives you a sense of progress and accomplishment. Sure, exploration also plays a big part in Subnautica, but the exploration is hugely driven by the need for upgrades, and if the upgrades are simply not required without survival mechanics, the whole thing falls apart. I for one found the game incredibly boring, once I had unlocked all upgrades and discovered all relevant story bits. Still, the first 30 hours or so were very fun. If it just weren't riddled with bugs and had a few more quality of life features that makes everything less of a hassle.... Two of my favorite survival games, Stalker Anomaly and Green Hell, are very hard and unforgiving as well and that's exactly what makes them work so well. Once you understand their mechanics and know how to handle the different dangerous situations, incredible stories tend to unfold just by the game systems and you feel incredible for mastering these situations. Here is a cool systems-based story I experienced in Green Hell: One notable exception from this "the more hardcore the better"-rule of survival is Valheim. In that game, you are not punished for not eating or drinking properly. Instead, you get bonus stats by consuming dishes. So basically, you can just walk around in your base all day and build stuff or cut trees etc. without ever eating anything. That doesn't mean that this game is easy, 'though, as those consumables are definitely needed for the challenging combat during exploration and boss fights.

Thanks everyone, for putting in so much work, especially our mighty @stgatilov, but also all the other devs and testers.

Outer Wilds and Inscryption for their genre defining nature and utterly brilliant design. Sekiro for redefining Sword Fighting in video games and SIFU for adapting and expanding that to fist fighting. Hollow Knight for setting a new benchmark in the Metroidvania genre. Doom Eternal for introducing more players to the flow-state due to its mechanics. Other notable mentions: Amid Evil for its awesome abstract level design in an oldschool boomer-shooter setting DEATHLOOP for combining a nice single player experience with an immersive multiplayer part There is no Game - Wrong Dimension just for being so absolutely meta and funny. OlliOlli World because it is simply a shitton of fun and comes with a soundtrack that instantly raises your mood.

Usually, processes can access about 3.5 GB with LAA.

I would say, just have the max height configurable via cvar, so we can fine-tune it later. And maybe add a shouldered mantling animation time multiplier cvar that linearily slows down mantling while shouldering to simulate encumbrance.

I think we should leave shouldering while climbing as is to avoid breaking anything, but we should probably fix what @peter_spy just discovered. Maybe disallow dropping bodies while attached to climbable. Anyway, I guess we are all on the same page regarding shouldered mantling: Waist-high only. @stgatilov noted on the bugtracker that the current implementation doesn't tie in well with the existing mantling conditions. So, my suggestion would be, once 2.11 is out the door, we'll fix that and whip out a dev release. Sounds good?

Oh my, this is embarassing for me. I was sure this was not possible, sorry. I guess sometimes your mind plays tricks on you. Maybe I just never tried because I implicitly assumed this was too unrealistic to work. Your point that it is too late to change this, is absolutely valid then.

Good catch. If that's true, we have to fix that! That's not intended design, as far as I know.

@datiswous, @Daft Mugi, @wesp5, there are some valid points and questions raised in this thread, which I am happy to address in a lengthy post soon, but at the moment, I am really sick with a nasty cold, so I feel I can't do them justice. Maybe another team member will answer them in my stead, otherwise, you will just have to wait until I feel better. In any case, @Mods, could you please move this discussion to a separate thread like "About our release and decision making processes"? This has nothing to do with beta anymore. FYI: To check which team members are still active, you can just visit their profile and check their "last visited" timestamp. Edit: I now saw that @Dragoferalready gave a good answer to most questions, thanks.

Of course, all your contributions are welcome. The thing about this specific feature you are implementing is that there was no universal agreement about it within the team to begin with. Just because something is listed on the bugtracker, doesn't mean it is an accepted featurerequest. Anyone can write anything to the backtracker. Furthermore, your patch changes core mechanics in a significant way that have to be thorougly tested not only for 12 hours by you, but by a whole testing community for a week at least, and @JackFarmer already described two maps that would soft-break by this feature. Lastly, you want it to be included now, i.e., at the end of beta phase. Our current beta build is a release candidate, which means that, if no further issues are found, it will be released as is. I am afraid, it is simply too late. You can of course just offer a modded 2.11 with your change included.

Well, I wouldn't put it that harshly, but changing core-mechanics is definitely not for the beta-phase.

Ok, let me start by saying that TDM was never supposed to be a simple copy Thief 1/2 mechanics in a newer engine. It was always catered towards the more hardcore players, seeking a challenge. Do we really need to restrict mantling while shouldering at all? > Yes, because all the 100+ existing FMs were designed with the current ruleset. Changing the ruleset afterwards could alter or even break the vision an FM author had for their mission and that is something we explicitly want to protect because these authors sometimes put years of work into their missions. If we restrict the player while shouldering, what should the rules be? > It was argued that lifting a body over small ledges is already possible, by dropping the body and moving it around without shouldering. This is very cumbersome, however, so being able to mantle small ledges while shouldering would be a nice quality of life improvement. While shouldering, what's the tallest object that can be mantled? > Waist high. Height could be controlled by a cheat-cvar. While shouldering, should there be different object height requirements between crouched and standing? > Yes, crouched should be lower. It would create some additional tension to have to stand up to perform the mantling. While shouldering, can the player mantle during a fall or jump across to another ledge? > Player cannot jump while shouldering. Conversely, he should not be able to mantle while shouldering and falling. While shouldering, what mantle types are allowed out of: push, pushNonCrouch, pull, pullFast, hang? > Definitely not hang and anything pull. That is only triggered for big heights. While shouldering, it should probably play the usual viewport animation, but a bit slower.

I mean, yes, obviously there is an internal forum where decisions are made regarding how to move forward with the game. That's how things work. And not just in our team, everywhere. Or do you see Apple discuss their business plans and new "innovations" in public? That being said, the team values all well though out ideas, feedback and suggestions, but even if everyone agrees that a certain feature would be nice to have, it doesn't automatically mean that it's going to happen, because there has to be a dev willing to do the work. You have to remember that we are all doing this for free on our free time. Every dev picks the task they are interested in the most. And that's precisely the reason why these excruciatingly long beta phases are so annoying: they prevent you from doing the stuff you really want to do. TDM is open-source and you can do with it whatever you like, but for something to be integrated officially into the game, the team has to agree on that. If you want to see a feature happen, implement it yourself and send in the patch, like Daft Mugi does. But be warned: Not everything listed in the bug tracker is a feature that has been fully agreed upon. It is always a safe bet to ask first, before doing the work. If you patch is not integrated into the core mod, you are of course free to offer it as a mod for TDM. Regarding the internal decision making process. It is rarely about personal preference, but more about: Is it in line with the existing vision / look & feel of TDM? Could it break anything? Number 2 especially applies to breaking FMs, which is a no-go because of the enormeous work mappers have put into their FMs.

Yes, sorry about that. We could be clearer with our communication in this regard. However, please understand, that it is really not that common for external contributors to be working so much on bug fixes and new features, so this is kind of new to us as well. And of course the team has to agree upon all contributions, regardless of external or internal origin. The beta was announced Dec, 2nd, and that was also the moment for 2.11 feature-freeze.

Just saw the discussion on the bug tracker. Please don't feel discouraged, @Daft Mugi. A lot of your stuff has already been integrated during beta phase, which we usually never do, so that's actually something you can be proud of. Once we start beta, we have a feature block even for long standing devs. Only bugfixes go into trunk at that point. New features are only commited to feature branches and will be integrated in the next version. But I get it. I've been in your shoes a few times myself.

There has been a long internal discussion about mantlling while shouldering, and it has been pretty much inversally agreed upon that v1 and v2 are a no-go. v3 was the best compromise we came up with: A nice quality of live improvement while staying true to the original gameplay rules that mappers have designed there missions around. However, not everyone was 100% onboard. If you have an implementation for v3 already, that's cool. Are there any open questions about this or why are you saying that there was no agreement about how this should work? Generally speaking, 'though, I am very surprised @stgatilov is letting bigger changes like this in so late in this beta phase. We are usually very restrictive about new features as soon as beta starts because it usually just prolongs the beta phase.