TDM Beta Release schedule confusion and frustrations

[Daft Mugi]

I've spent a lot of time recently submitting patches to fix some bugs and working on a few things that I think would really improve the feel of TDM for 2.11. They are very small changes, and they are meant to polish what's already there without changing or breaking anything for anyone.

1. (Available 2.11 beta 7)
   1. Added player "tdm_toggle_sheathe" cvar and "Toggle Sheathe" setting (6232) (thread).
   2. Renamed "New Missions" to "Missions List" in main menu (6230). @nbohr1more cleaned up my original patch. Originally, proposed by @snatcher (post).
   3. Fixed initial difficulty highlight on Objectives screen (6229). @stgatilov cleaned up my original patch.
   4. Fixed Objectives title slightly cut off on low text scale (6234). @stgatilov cleaned up my original patch.
   5. Made it possible for the player to change "pm_noclipspeed", so noclip speed can be set (6237).
2. (Available in next beta)
   1. Make "tdm_toggle_creep" work like other toggle cvars, and add "Toggle Creep" to the settings menu (6242) (thread).
3. (Not available)
   1. Make the inventory parchment background (dds file) separate from the "Missions List" parchment background (dds file). Without the patch, if you change the inventory background, it will also change the main menu. Patch submitted (6241) to decouple the inventory background from the main menu. This is meant for players who want to edit the inventory background (dds file) themselves (e.g. reduce its brightness without affecting the main menu).
   2. When you drop a long distance and land in a mantle, damage is shown after the mantle animation is complete. Partial fix submitted (6231). I think I'll need @stgatilov's help on this one. Bikerdude was very kind and provided a test map for this, which helped to expose an issue with my original patch.
4. ("pm_mantle_while_shouldering" cvar available in 2.11 beta 7) It was requested by Bikerdude one year ago to allow mantling while carrying a body. Due to feedback, I've submitted three patches each with a different behavior, starting in August 2022 (5892) (thread) :
   1. (Patch v1) Always enable mantling while carrying a body.
   2. (Patch v2) Only enable mantling while carrying a body if "pm_mantle_while_shouldering" cvar is set. This is already available in 2.11 beta 7.
   3. (Patch v3) Restrict mantling at the waist. There is no agreement about how this should work yet.
   • I've spent over 12 hours of work and testing on (v3) so far, so it would be incredibly discouraging if a final decision is not made between versions (v1), (v2), or (v3) for 2.11. Personally, I think patch (v1) always enable mantling while carry a body is best. This matches Thief 1 & 2 and does not require a cvar. If (v3) is chosen, the rules need to be decided.

These are the final issues / bug trackers I have for 2.11. I hope they can make it into the final release of 2.11, because I think it would make TDM feel more polished and give a better first impression for newcomers. And, Thief players would have a better first time.

Edited January 26, 2023 by Daft Mugi

[STiFU]

33 minutes ago, Daft Mugi said:

I've spent a lot of time recently submitting patches to fix some bugs and working on a few things that I think would really improve the feel of TDM for 2.11. They are very small changes, and they are meant to polish what's already there without changing or breaking anything for anyone.

1. (Available 2.11 beta 7)
   1. Added player "tdm_toggle_sheathe" cvar and "Toggle Sheathe" setting (6232) (thread).
   2. Renamed "New Missions" to "Missions List" in main menu (6230). @nbohr1more cleaned up my original patch. Originally, proposed by @snatcher (post).
   3. Fixed initial difficulty highlight on Objectives screen (6229). @stgatilov cleaned up my original patch.
   4. Fixed Objectives title slightly cut off on low text scale (6234). @stgatilov cleaned up my original patch.
   5. Made it possible for the player to change "pm_noclipspeed", so noclip speed can be set (6237).
2. (Available in next beta)
   1. Make "tdm_toggle_creep" work like other toggle cvars, and add "Toggle Creep" to the settings menu (6242) (thread).
3. (Not available)
   1. Make the inventory parchment background (dds file) separate from the "Missions List" parchment background (dds file). Without the patch, if you change the inventory background, it will also change the main menu. Patch submitted (6241) to decouple the inventory background from the main menu. This is meant for players who want to edit the inventory background (dds file) themselves (e.g. reduce its brightness without affecting the main menu).
   2. When you drop a long distance and land in a mantle, damage is shown after the mantle animation is complete. Partial fix submitted (6231). I think I'll need @stgatilov's help on this one. Bikerdude was very kind and provided a test map for this, which helped to expose an issue with my original patch.
4. ("pm_mantle_while_shouldering" cvar available in 2.11 beta 7) It was requested by Bikerdude one year ago to allow mantling while carrying a body. Due to feedback, I've submitted three patches each with a different behavior, starting in August 2022 (5892) :
   1. (Patch v1) Always enable mantling while carrying a body.
   2. (Patch v2) Only enable mantling while carrying a body if "pm_mantle_while_shouldering" cvar is set. This is already available in 2.11 beta 7.
   3. (Patch v3) Restrict mantling at the waist. There is no agreement about how this should work yet.
   • I've spent over 12 hours of work and testing on (v3) so far, so it would be incredibly discouraging if a final decision is not made between versions (v1), (v2), or (v3) for 2.11. Personally, I think patch (v1) always enable mantling while carry a body is best. This matches Thief 1 & 2 and does not require a cvar. If (v3) is chosen, the rules need to be decided.

These are the final issues / bug trackers I have for 2.11. I hope they can make it into the final release of 2.11, because I think it would make TDM feel more polished and give a better first impression for newcomers. And, Thief players would have a better first time.

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.

[stgatilov]

50 minutes ago, Daft Mugi said:

I hope they can make it into the final release of 2.11, because I think it would make TDM feel more polished and give a better first impression for newcomers. And, Thief players would have a better first time.

To be honest, that can be said about 99% of changes to the game

8 minutes ago, STiFU said:

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.

Yes, that's exactly what is happening
I'm trying to filter all these changes depending on how scary they look to me.

Out of what Daft Mugi has listed that is not in beta211-07 yet, I think only the fix for damage from fall + mantle is going to make it.
The rest of the changes... I'd better not hurry.

The general rule is that we do development before beta starts, not after.
And especially not in the second half of beta.
 

[STiFU]

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.

[stgatilov]

14 minutes ago, STiFU said:

I've been in your shoes a few times myself.

Like... who was that person who pushed the latest major mantling changes during beta?...

UPDATE: Maybe things got mixed in my mind

[datiswous]

8 minutes ago, STiFU said:

Once we start beta, we have a feature block even for long standing devs. Only bugfixes go into trunk at that point.

I think that the move to beta came a bit sudden. Could be nice to have more clearance on when and why it is decided dev stops and beta phase starts. I could be wrong though.

[Daft Mugi]

As someone new to contributing, this has been an incredibly frustrating and stressful experience. I've felt like I'm racing towards an unknown deadline. I've lost track of how many hours I've put into TDM testing and code writing this month.

One of the biggest sources of stress is not knowing the beta release schedule. TDM 2.10 was released March 2nd, 2022. So, my thinking was that these could get in this month (January), and then February would be mostly frozen.

These are small changes compared to other patches I've seen made, and I don't consider them at risk of breaking the game.

The "mantle while shouldering" code change is simple, but the hardest part is agreeing on its behavior. That changed behavior will affect both players and mappers. At least some players want that change, so I don't understand the hold up and big controversy. The main reason I saw against it was that an existing mission might have a mantle trap, so this change would break their mission. But no example was given of even a single case of this.

The other source of frustration is not knowing what the internal dev communication is. I've been doing my work mostly in the dark. Also, sometimes I get surprised by a message like "the group has decided X" without a reason.

And, from my point of view, my changes have been mostly bug fixes uncovered during beta testing.

It would be a shame for players to have to wait an entire year for these bug fixes. And, I'm writing a TDM getting started guide for Thief players, incorporating these recent changes, because I know veteran Thief players would likely enjoy these changes. Again, not knowing the release schedule, I'm also racing to finish that guide against an unknown deadline. I wanted that guide's release to be the same day as TDM 2.11's release.

Edited January 26, 2023 by Daft Mugi

[STiFU]

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.

[datiswous]

1 hour ago, STiFU said:

There has been a long internal discussion

I actually for quite some time have been wondering what the internal forum is for.. I get a feeling that the normal forum discussions aren't really decision making, this is just giving opinions, until hopefully a dev has the same opinion and then it might get discussed properly. It's almost like it's useless to come up with an idea for something because the internal forum is for the decision making and nobody knows what's being discussed there.

[STiFU]

28 minutes ago, datiswous said:

I actually for quite some time have been wondering what the internal forum is for.. I get a feeling that the normal forum discussions aren't really decision making, this is just giving opinions, until hopefully a dev has the same opinion and then it might get discussed properly. It's almost like it's useless to come up with an idea for something because the internal forum is for the decision making and nobody knows what's being discussed there.

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:

1. Is it in line with the existing vision / look & feel of TDM?
2. 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. 

[nbohr1more]

I guess I'll chime in here for clarity.

When the TDM Dev Build thread is active:

This is when big changes and contributions are supposed to be welcome.

When we are in "Beta Testing" it is supposed to be a code freeze period where only regression fixes are applied.

Sometimes a fix or improvement that shouldn't be in a beta phase gets added anyway if it is seen as exceptionally beneficial, but every time this is done it can potentially extend the beta testing for another 2 weeks or more and during that additional 2 weeks even more fixes and improvements are proposed by eager contributors which can potentially lead to a never ending beta.

I am not particularly bothered by a long dev build phase, nor a long beta and am inclined to wait a long time until new official releases are available. Players, on the other hand, generally aren't keen on using Dev Builds so we need to stop at some point and christen something as official if only for the sake of getting more feedback in case regressions slipped through Dev or Beta testing.

Let's be clear though, neither TDM 2.10 or 2.11b7 are "unplayable garbage". Enhancements are fantastic but if 2.11 doesn't include every improvement you can conjure it will still be better than 2.10 which is already an excellent TDM version.

I am still in favor of most or all of your improvements making it into 2.11 but we have to follow the process and need to have agreement from the team about what happens next.

If you disagree with the way that we rollout "dev > beta > release" cycles and want to offer your fixes before they go into TDM official release, I suggest you consider creating a fork project.

You can call it "The Darker Mod" , "Better Dark Mod Enhanced", etc, any of the monikers you typically see on enhancement projects on Moddb. If your fork becomes popular then it may be the main one that players use sorta like how Debian Linux is the core project but most people use Ubuntu or Linux Mint. ( If you made such a fork, I would probably ask that you integrate my fresnel shader mod into it.   )

[wesp5]

7 hours ago, nbohr1more said:

If you disagree with the way that we rollout "dev > beta > release" cycles and want to offer your fixes before they go into TDM official release, I suggest you consider creating a fork project.

The TDM community is much too small to support multiple versions. For example, snatchers modpack hasn't even reached 100 downloads on ModDB yet and my own patch is still under 700 after some time...

[snatcher]

I think I have 10 or so loyal customers

I get a little disappointed when I think of the tens of thousands of skilled individuals modding other games... so much potential out there. Something is off with TDM.

[Dragofer]

My own take on the beta process is that devs on one side commit to adding and improving features, but also to ensuring that the new releases are, as far as reasonably achievable, free of bugs and that the new features aren't broken on release. To balance that we have a general policy to freeze the code when the beta starts, where code changes should primarily be fixes to issues detected in the beta. Exceptions are made on a semi-regular basis for changes that go further if they can be justified. That's mainly the case when there's still enough time left in the beta to get the changes properly tested and reviewed, or the risk of breakage is low i.e. because you're adding, but not changing things.

For example, I worked extensively on assets this release cycle and didn't manage to get all the work done before the beta, so I was still busy until about the middle of the beta phase. However, I prioritised my work so that asset changes were ready ahead of the beta, while asset additions (which won't break anything) were made during the beta. I also treaded particularly carefully when adding the new assets to compensate for their shorter beta testing time.

I might not have been around as much lately, but I only heard of Daft Mugi's slew of patches when we were discussing whether the next beta build should be the release candidate, which gets released as-is if no significant issues are reported. At that point any changes will either prolong the beta testing phase, or carry the risk of not working as intended. The plan was to reach this point at the end of january (if this was not prominently communicated somewhere it was a mistake).

Personally I definitely see the value in trying to accommodate as many of these changes as possible because they make TDM more attractive to Thief players, Daft Mugi is even standing ready to introduce them to the TTLG community, and it looks like they're fairly simple changes. However, prolonging the beta comes with its own drawbacks. One is that players and mappers are delayed in getting access to all the other new features. Another is that the beta phase is a relatively draining part of the release cycle for the devs because new projects are mostly on hold while the focus is on getting to a stable build. One of the ideas behind dev builds was to shorten the beta phase by spreading out the testing.

Ultimately, we've designated Stgatilov as the project lead so it's his task to call the shots on how to balance these demands.

[wesp5]

2 hours ago, snatcher said:

I think of the tens of thousands of skilled individuals modding other games... so much potential out there. Something is off with TDM.

I don't need thousands of people modding. The result are games like Skyrim, where you need hundreds of mods to play in the first place ;). But I am disappointed in the low download numbers for even the core TDM on ModDB. Maybe most people use the included updater, but they must have downloaded the base package first some time ago. So are there any hints about how many people play TDM? Like how many downloads are there for a new fan mission once it is released? This might also be interesting as an internal rating in the download list on which missions are the most favorite ones...

Edited January 27, 2023 by wesp5

[datiswous]

A possible idea is to start the new dev at the moment the 2.11 beta is started. Meaning there's always a dev version active. In this case the dev could just be tdm dev and have no version nr. and the beta is taken from a set of improvements.

Edited January 27, 2023 by datiswous

[datiswous]

14 hours ago, STiFU said:

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?

You can't really compare an open source modding comunity with a company like Apple. Although maybe you're saying we aren't really a comunity project. Fair enough.

I don't think it's neceserry to have a hidden forum for devs (just make it read only for regular users, but at least we can follow your internal discussions), except if there are things in it that need to be hidden to normal users. I guess that is the case then. No hard feelings, just an observation. It would be nice though if it stays seperate and devs would not link to it in regular forum posts. And maybe some of the decissionmaking should be posted about outside the internal section?

14 hours ago, STiFU said:

the team has to agree on that.

Btw. of which members does the team consist currently? I see a lot of (I think) inactive members with dev status. Originally The team page adressed this, but it is not updated anymore (no idea why) and usually if somebody says something about that, it is ignored.

[Dragofer]

5 hours ago, datiswous said:

I don't think it's neceserry to have a hidden forum for devs (just make it read only for regular users, but at least we can follow your internal discussions), except if there are things in it that need to be hidden to normal users. I guess that is the case then. No hard feelings, just an observation. It would be nice though if it stays seperate and devs would not link to it in regular forum posts. And maybe some of the decissionmaking should be posted about outside the internal section?

I think the reason the dev forums exist is to provide a place where the implementation of features can be discussed without getting mixed up with other debates when someone believes what the devs are doing is wrong. We often post public discussion threads for features with subjective elements like the frob outline, because community feedback is very important. But there will always be vocal defenders with strong views for or against certain features, or how exactly it should be implemented in their opinion. At some point a decision has to be made and be carried through, which is what the dev forums are for. Almost all of the threads are very technical, basically explaining and discussing recent or potential code changes with other devs.

6 hours ago, datiswous said:

Btw. of which members does the team consist currently? I see a lot of (I think) inactive members with dev status. Originally The team page adressed this, but it is not updated anymore (no idea why) and usually if somebody says something about that, it is ignored.

Its hard to say. Its a hobby the devs do in their spare time, so people come and go when they're in the mood and when they have the time. The team page is mostly accurate except for some relatively newer additions like myself.

[Daft Mugi]

In a private message on Monday (2022-01-16), I asked about some patches. Then, I was asked why I waited until the second half of beta testing. My reply was "(1) I recently shared some config with Thief players and some expressed interest in TDM. So, I decided to write a guide. (2) I've been beta testing a mission, so I've uncovered these recently. (3) I don't know the beta release schedule, so I don't know where we are in the process."

In a private message on Tuesday (2022-01-24), I was asked when I would be done with my patches for 2.11. I gave a list, and there was no definitive communication from the dev team that they would not be considered for 2.11. Just that patches would need to stop soon, because the dev team was deciding when to end beta testing. It seemed that I was given the go ahead. I didn't want to hold up the beta's (unknown) schedule anymore, so I put in extra time and effort to get all of my patches in no later than the next day (Wednesday) to give the dev team time.

In a private message on Wednesday (2022-01-25), I told a developer, "I've submitted all the patches that I've planned: 6241, 6231, 5892. I'm ready for feedback and fixing any issues with those patches. That'll be it from me for 2.11." I was given some feedback about (5892), and there was no mention that my patches would be excluded from 2.11.

23 hours ago, STiFU said:

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.

This week's work getting into the next beta was going to be my personal triumph and moment to be proud of, because my hard work was going to be done for 2.11. My patches were already submitted, after all. Now, it's ending in a bust.

After my post yesterday, I found out that one of my patches that had already been accepted in SVN for both code and assets will be reverted and postponed until 2.12. No reason given. I had checked SVN to make sure it was applied correctly and made sure the core assets were correct. I've been playing with the latest SVN code and haven't encountered any issues with that patch. Now, I don't know the state of that code. (As an aside, I don't have read access to the assets SVN, so I had to request the changed files from a dev.) The patch is for (6242). That patch fixes a bug that can be read about on (thread). Does the dev team think those players are going to be happy that this patch was reverted and won't be available for an entire year? I fixed that for the players, not myself.

For (5892), a feature requested by Bikerdude. This was a reason given for not allowing mantle while carrying a body:

Quote

[...] let's say that only one mission is impacted but the mission author is one of our most prominent contributors. Allowing their mission to be broken by this change could cause other less prominent mission authors to lose trust in the project.

On Saturday (2022-01-21), the "tdm_mantle_while_shouldering" cvar was accepted and merged into SVN. Bikerdude replied:

Quote

Thanks for sorting this chaps, it's been a minor frustration for years.

Now, if I'm understanding right, that cvar will be removed and not included in 2.11.

Bikerdude is one of the most prominent mission authors, is he not?

Now, Bikerdude's feature is being taken away. A less prominent contributor, myself, is getting his contributions reverted.

It's a shame, because my fixes and suggestions mostly come from listening to the community and dev feedback. Submitting patches is a lot of effort, and I could keep those changes to myself instead. My work is for the players, not myself. Usually, I don't propose something or act on something unless I see other players having the same issue as I've experienced. I think TDM is mostly fine as is. It's not like I'm suggesting new arrows, how doors work, rewriting AI, or something like that.

I'm at a tipping point of losing trust in this project, because this situation is fixable. Miscommunication happens. How it's handled matters. I did my best to communicate and hold true to no more patches after this week. Also, the dev team could have told me something like "any patches submitted after X date will not be considered until after the beta cycle." From my point of view, the dev team suddenly changed course from Tuesday's "deciding when to end beta testing" to Thursday's "still unknown but sooner than before, I guess?", and the proposed solution from the dev team is "Tough. Deal with it." or "Don't like it? Fork it." instead of "Let's do one additional beta release" to get everything worked out (whether or not patches get included). I think one more beta release to get these completed or decided on is fair, because that's what the agreement seemed to be, as vague as it was. I'm doing this for free as well, and it sure doesn't feel good to see my work handled in this manner.

[peter_spy]

Even if you take a few factors out of the equation (making a change for literally one FM author and possibly "some players"), you implemented a change in player character movement model / added new gameplay rule – and you're surprised it wasn't implemented during public beta testing of new release...

Not to mention that situations like that (with the code) happen all the time, in both amateur and professional setting. E.g. Lately I was working on a solution for one of our modules not working correctly on Mac. I spent the whole day researching the topic, finding and testing the workaround, but ultimately my PR was declined. We found out that the actual problem was with borked installation process for one of our dependencies. Well... I could have spent that day on something else

Edited January 27, 2023 by peter_spy

[STiFU]

@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.

[datiswous]

2 hours ago, STiFU said:

but at the moment, I am really sick with a nasty cold

Gute Besserung

[stgatilov]

@Daft Mugi, I am sorry to cause the confusion.

I thought I made it clear when you came with the first pack of 5 patches, that such generic changes currently get into release only as an exception, but apparently it was not clear.
You are right: I should have been more strict and rejected all the generic changes since at least the New Year. Making exceptions on subjective basis makes things look unfair and can offend people.

The current idea is to make the next beta release a "release candidate", and if nothing bad happens, then make it the final release. We are already beta-testing it for 2 months.
Looking at the previous beta 2.10, it started 10 days later than this year. Also, it lasted so long exactly because something bad happened in February: some people reported driver-dependent graphical issues.

Considering 12 months between subsequent releases, we spend 1/6 of astronomic time in beta phase. And it is tough for developers, because they have to stop normal development during this time. For instance, I'd really want to go on and nuke the old/new backend division due to how much pain it has caused thus far, but I have to wait until 2.11 is out. Or I want to implement a better AI visibility check but it also has to wait.
Now imagine that some people want to reduce time interval between releases, for instance to half a year (I recall we have summer release a few years ago). It means 1/3 of our time we'll have to restrain from changes!

You should understand that in case of TDM, official releases are rare because how hard it is to test the game. If you want people to see your changes fast, now there are development builds for that. If you want to make something into official release, be ready that your changes will wait for months before that.

Here is what happens to your changes now:

• Everything that is in the latest beta stays there.
• 6241, 6231 --- will get into 2.11.
• 6242 --- will not get into release.
• 5892 --- cvar will get into release, but the following conditions will not.

P.S. I must say that I personally would be greatly disappointed if you leave TDM because of this.