Beta testing 2.07-hotfix

[stgatilov]

I think we can leave the cvar as it is now.

 

I'm afraid with the current pace of changes config reset is necessary after every TDM update to avoid issues.

It is not clear if tdm_update should remove it automatically, because it may contain something player wants to save.

One example is custom key bindings, although in the current SVN they are stored in a separate file (meaning that starting from 2.08, config reset will not destroy key bindings).

 

One possible approach is to rename darkmod.cfg into darkmod_old1.cfg, darkmod_old1.cfg into darkmod_old2.cfg, etc every time tdm_update is run.

This way player will not loose information completely, but is forced to config reset by default.

[peter_spy]

Deleting a cfg when having graphics problems, so TDM can generate one from scratch is one of the standard things to do. So it's rather a poorly reported problem. The main downside is that all keybinds are deleted too, but you can store them in autocommands.cfg, so they always overwrite the default configuration.

[wesp5]

One possible approach is to rename darkmod.cfg into darkmod_old1.cfg, darkmod_old1.cfg into darkmod_old2.cfg, etc every time tdm_update is run.

This way player will not loose information completely, but is forced to config reset by default.

This sounds like a good solution! Also even if Judith thinks removing the cfg is a standard approach, this suggestion was made only after a long time in which the problem persisted and after it finally actually happened to a developer .

[peter_spy]

It's not my opinion, you can find that in Troubleshooting sections of TDM wiki. And deleting a cfg won't be a problem when keybinds are moved to separate file, which is already in plans for the next versions.

[stgatilov]

this suggestion was made only after a long time in which the problem persisted and after it finally actually happened to a developer .

The problem was finally diagnosed by developer only because one of the victims posted config file

I believe a lot of problems would be diagnosed faster if reporters attached all the typically needed information.

 

And deleting a cfg won't be a problem when keybinds are moved to separate file, which is already in plans for the next versions.

4797 already done: the bright future will start somewhere at 2.08-to-2.09 update

 

[peter_spy]

People should now some basic procedures to go through before reporting a problem. E.g. if you have graphics problem, first do this and this. Then try this as well. It's there in the wiki, although it might not be easily accessible. And in general, so called super users and technical users are much better testers, since they have some knowledge of how the systems work, and they do enough of research by themselves first, to pinpoint the problem before they start bothering developers.

[wesp5]

People should now some basic procedures to go through before reporting a problem. E.g. if you have graphics problem, first do this and this.

Sorry, but I don't search through a wiki for a game everytime I have a small problem like this. Also it seems the thing was diagnosed correctly almost two weeks ago because I did upload my cfg, only I was busy playing other games and never looked into the bugtracker in all that time! It's solved now anyway .

Edited May 12, 2019 by wesp5

[peter_spy]

You say you didn't have time to take a look at the wiki / do the research, and yet you had time to report it. No one forces you to do the testing, but if you decide to do so, take some time to gather information first. Otherwise it's like saying "hey guys, something doesn't work!" You don't need bug tracker to do that

[stgatilov]

Oh, please, don't be so strict!

Any bug report or feedback is welcome!

I only wanted to spread the word about that wiki article: posting the link in appropriate conditions is the only way to make it known over time.

In fact, the article was not even present at the time this bug was initially reported

[peter_spy]

Oh no, I don't mean to discourage anyone from testing, but there's a huge difference between any feedback and quality feedback – and that's dev's time. This is even more important in non-professional environment, since everyone here does it in their free time, so any effort not to waste it is very, very appreciated. Bugtracker is more for developers, so they can easily move through a logically structured documentation about problems and their causes. If you don't have time to contribute towards that, it's fine, you can always mention your problems casually in the forums, and at some point someone else will document it properly

[Anderson]

Oh no, I don't mean to discourage anyone from testing, but there's a huge difference between any feedback and quality feedback – and that's dev's time. This is even more important in non-professional environment, since everyone here does it in their free time, so any effort not to waste it is very, very appreciated. Bugtracker is more for developers, so they can easily move through a logically structured documentation about problems and their causes. If you don't have time to contribute towards that, it's fine, you can always mention your problems casually in the forums, and at some point someone else will document it properly

At a first glance someone's going to have to take a look either at the forum or the bug tracker. Prioritized bugs/suggestions are already marked and if there are no animators/coders - Rome won't be build in a night. Nothing won't change much. It will be delayed anyway.

[peter_spy]

I think you misunderstood that a little. It's not about the delay between reporting an issue and the dev response time. It's about pinpointing the cause of the issue yourself, as much as you can, so dev investigation takes as little time as possible. If you don't have time or knowledge to do this, you can casually do this via forums, and someone will deal with it, sooner or later.

 

If you want to use the bugtracker, you'll be more helpful if you do some digging yourself. Bugtracker also serves as a knowledge base, so devs can look how a problem was solved in the past. It's a more useful resource when issues are concise and to the point.

[Anderson]

 

If you want to use the bugtracker, you'll be more helpful if you do some digging yourself. Bugtracker also serves as a knowledge base, so devs can look how a problem was solved in the past. It's a more useful resource when issues are concise and to the point.

Very true, both the forums and the bug tracker's active contributors know each other so they can additionally see where to pay attention. Right now both allow casual users to use them, it's ok.

[Ladro]

On 3/19/2019 at 11:33 AM, freyk said:

just a small change, to keep it simple.

 

I found that the link with tdm_mirros.txt it's dead.