Transport Tycoon Forums

Posted: **21 Jul 2011 00:00**

As much as I appreciate the hard work of the developers there is something that I find disturbing. The new versions [OT 1.1.1] have unnecessary restrictions on freedom. Moreover, these restrictions are the sort to be found in the output of one of my least favorite companies. Every upgrade of their product restricts freedom of the user and imposes the will of the developers. I am not accusing the TTDevelopers of anything other than adherance to a culture that is less free.

Example #1: Why insist on multiple clicks when only one is necessary and when only one has been the requirement in the past. To load a game you click on the game, then you need to click on Load game. Why?

Example #2: Modifying a scenario or the GRFs selected for the scenario are prohibited [though one can spend some time and frustration getting around this]. Why would someone post a scenario or GRF freely and publicly and expect to control what is done with it?

This reminds me all to well of the modus operandi of the company few love and many would love to escape.
Again, I appreciate the work of all of the developers, my problem is with what I see as a societal problem, i.e. imposition of restrictions on freedom for no sound reason. I hope that the developers will take this into consideration when continuing with their fantastic work.

: The company that distrusts and always seeks to restrict the users even when that is unnecessary.; Unfree Flag.png (23.56 KiB) Viewed 12264 times

Posted: **21 Jul 2011 00:17**

jmc47ott wrote: Example #1: Why insist on multiple clicks when only one is necessary and when only one has been the requirement in the past. To load a game you click on the game, then you need to click on Load game. Why?

Example #2: Modifying a scenario or the GRFs selected for the scenario are prohibited [though one can spend some time and frustration getting around this]. Why would someone post a scenario or GRF freely and publicly and expect to control what is done with it?

ad 1) Having a savegame preview is IMHO a nice feature when you have more than two savegames. With my list of savegames from 5 years, I surely don't know anymore what the game from 3 years ago was about. Did you try double click?

ad 2) That's a bug fix, not an unnecessary restriction. Modifications of NewGRFs on running games by unaware users like you cause more or less subtle bugs. The only save action is to configure NewGRFs prior to map creation. There are literally zillions of threads in this forum which discuss it at great length and explain it in more detail. Even a sticky... which obviously are never read.

Also, you're posting in the wrong section. Both has nothing to do with NewGRF programming

Posted: **21 Jul 2011 00:37**

jmc47ott wrote:Example #2: Modifying a scenario or the GRFs selected for the scenario are prohibited [though one can spend some time and frustration getting around this]. Why would someone post a scenario or GRF freely and publicly and expect to control what is done with it? ...for no sound reason.

There is a sound reason as to why this was done. Changing NewGrfs in a saved game (a scenario is treated by the code the same as a saved game) can cause all sorts of instabilities in that game resulting in unsolvable bug reports. I am sure you have read this in the many threads that have discussed this topic. What part of it have you not understood?

Just so you understand my point of view on this topic. I tend to change NewGrfs in saved games every now and again but I do so cautiously. If it is a vehicle NewGrf I am sure that there are no vehicles in my game that such a change might effect. If it is a cosmetic NewGrf (one that only changes the appearance of things) I might do so more freely provided that I have done the due diligence involved and I am relatively sure that no major corruption will occur. In either case I would never report any resulting corruption as a bug because I am aware of the problem, I have read the threads, and (more importantly) I have read the big red warning that pops up in game when such changes are made. Of course I have been around this game (and this forum) for quite some time now so my knowledge is a bit more in depth than someone who has just picked up the game for the first time. Those that are new to the game are those that are most likely to make such bug reports without any regard for the warning they were issued. To save the developers time and effort (which they would rather spend improving the game than chasing down futile bug reports) is the primary reason this change was made.

Posted: **21 Jul 2011 05:14**

I totally agree that OpenTTD is limiting the freedoms of the user quite drastically compared to Transport Tycoon Deluxe.

For example:
1) you can't make a level crossing red infinitely when there is no vehicle on it anymore.
2) you can't crash vehicles of your opponent.
3) you can't do network play under DOS.
4) you can't build buoys on the northern most corner.
5) you can't get cheap water clearing by building a ship depot.
6) you can't take over ownership of a road by build a rail over it.
7) you can't get into loads of debt by getting loads of money.
8) you can't use the old train path finder.
9) you can't use the old AI.
10) you can't make money by building very long bridges.
11) you can't play the game anymore with a very small amount of memory.
12) you can't automatically stay in 2090 forever anymore.
13) you can't start a scenario with your own (NewGRF) settings anymore.

Posted: **21 Jul 2011 13:56**

Rubidium wrote:
9) you can't use the old AI.

I thought SimpleAI in the online content was the old AI. Is it just a clone?

Posted: **21 Jul 2011 14:05**

changing newgrf during play does do some nasty things sometimes.
but some other times it is harmless.

then comes the question, why not implement a simple option, that has a default OFF, to allow to change /add/remove newgrfs during game play.

actualy it should have a warning, in case this option is set to ON, showing that in many cases this will lead to bugs.
then everyone can be happy.

a simple solution for a complex problem.

Posted: **21 Jul 2011 14:08**

Leto wrote:I thought SimpleAI in the online content was the old AI. Is it just a clone?

No, it is just an AI that aims to recreate the 'old AI' behavior.
However, the old AI could cheat, and the current AIs cannot any more, so it is not a clone

Posted: **21 Jul 2011 14:09**

2457 wrote:changing newgrf during play does do some nasty things sometimes.
but some other times it is harmless.

then comes the question, why not implement a simple option, that has a default OFF, to allow to change /add/remove newgrfs during game play.

actualy it should have a warning, in case this option is set to ON, showing that in many cases this will lead to bugs.
then everyone can be happy.

This already exists:

Open the console by pressing the button to the left of the 1 key on your keyborad. It's a backtick on mine, I believe it's a ~ on American keyboads. Type in

Code: Select all

setting gui.scenario_developer on

This brings back the old NewGRF menu. When you try add or remove a NewGRF, you get a big red warning on top of that.

Posted: **21 Jul 2011 14:11**

2457 wrote:changing newgrf during play does do some nasty things sometimes.
but some other times it is harmless.

then comes the question, why not implement a simple option, that has a default OFF, to allow to change /add/remove newgrfs during game play.

We had this, and despite the red error window with an explanation that bad things may happen and not to report, we got many such false bug reports.

Maybe you are mature enough not to report such a case, but experience shows that many users do not understand such warnings.
As a result we had to switch to the extreme measure of disabling the feature.

Posted: **21 Jul 2011 15:45**

Leto wrote:I thought SimpleAI in the online content was the old AI. Is it just a clone?

Mission accomplished.

Posted: **22 Jul 2011 13:58**

Leto wrote: Open the console by pressing the button to the left of the 1 key on your keyborad. It's a backtick on mine, I believe it's a ~ on American keyboads. Type in
Code: Select all
setting gui.scenario_developer on
This brings back the old NewGRF menu. When you try add or remove a NewGRF, you get a big red warning on top of that.

I totally love the irony in this. First, OP compares openttd approach to that of employed in microsoft products, where freedom is taken from end user on a whim - and then the solution to the problem is just as "intuitive and user-friendly" as those solutions suggested for microsoft stuff (being all about changing obscure keys in the god forsaken corners of system registry and suchlike).

From a *nix user perspective the whole issue looks a bit weird from the start. You know, if you malform the command line with 'rm' in it, you can screw things over in quite a capital way - e.g. saying rm -rf ~/Documents/archives/ * - and yet I doubt that coreutils developers receive a ton of bugreports on missing ~ dirs. Similarly, I have yet to hear about rm being omitted from installation by default in any distro "due to possible erroneous actions of users". Heck, even --no-preserve-root can be circumvented in a quite obvious way.

I also tend to believe that issues arising from altering the GRF set on the fly are unlikely the reason for a considerable numbers of bug reports any way. Sure, that can happen, but I've been playing openttd for a couple of years now, and this only happened twice (you can count the time when I removed the NuTracks GRF on purpose just out of curiosity as the third case) - that is to say, one apparently needs to apply some diligent effort to actually break a game with GRFs.

In other words - Linux users take great pride in being able to shoot themselves in the leg whenever they feel like it and hold that freedom quite dear.

Posted: **22 Jul 2011 14:28**

Oh wow thank god for that little piece of code. is there any more useful code for editng other stuff?

Posted: **22 Jul 2011 14:52**

Jacko wrote:Oh wow thank god for that little piece of code. is there any more useful code for editng other stuff?

You mean you need to be able to shoot yourself in the foot even more easily?
Try messing with the path finder settings.

Posted: **22 Jul 2011 15:24**

No no no i made a post about this in another place about Newgrfs like this. besides, i save beforehand.

Posted: **22 Jul 2011 17:41**

HvS wrote:I also tend to believe that issues arising from altering the GRF set on the fly are unlikely the reason for a considerable numbers of bug reports any way.

So what about the dozens of people going "I downloaded the England and Wales scenario, but there are no trains available"?

Posted: **22 Jul 2011 18:01**

HvS wrote: I also tend to believe that issues arising from altering the GRF set on the fly are unlikely the reason for a considerable numbers of bug reports any way.

Good. So you'll handle all those bug reports:

100000 users * 10% modifying newgrfs * 1% reporting the error = 100 reports. Thus every week one or two such report. Now assume that the crash reason is not quite obvious, thus you'll have to look at the issue, ask back because only 20% supply all needed info in the first place, thus one, two hours spent EVERY week on ... nothing. Which was about right before we disabled it.

Posted: **22 Jul 2011 18:02**

@HvS:
Your *nix comparison is not valid.
The OpenTTD ingame console gives you the same freedom as a *nix console. The OpenTTD GUI hides troublesome functions from the user just like every *nix GUI.
The OpenTTD console is nothing magical, it has commands to list available settings, and also some help on the commands, thus not on every setting. If the OpenTTD console is magic to you, then it is just as magic as a *nix console is to a GUI-focused user.

Also please let me tell you some history of this process.
In the old days you could freely change NewGRFs in game. At the same time OpenTTD had a lot of unreproducible crash bugs, of which noone knew what happened.

Then in OpenTTD 0.7 we (everyone shall praise smatz!) added a (from a developer point of view) great feature: The gamelog. It logged all changes to settings a player made to a game. This was the key that actually allowed us to find reasons for lots of "bugs": Players changing NewGRFs all the time, resulting in totally broken games. Before gamelog we spent hours of exploring the issues, what might have happened, and without no actual result. Compare that with the obvious messing of a player replacing road vehicles with trams on roads without tram tracks by changing NewGRFs in game.

So at this point we were able to close a lot of bug reports by just taking a short look at the gamelog. We closed tons of bug reports with a small note about changing NewGRFs being the cause, and that the player shall read the red warning before doing stuff. However, over time everyone got tired with always explaining the stuff, as players complained back "what red error message?". Some players became rude, and the developers became rude as well after closing the third bug in two days about someone refusing to have seen a red warning (despite of he must have clicked it away at least 5 times).

Then in 1.1 we finally disabled changing NewGRF for the default user. You can very well compare this with Windows hiding stuff from the average user while still allowing to activate it via some hidden registry, if you really need to. The same reasoning applies to various Linux distributions hiding the console from the user. Another example are operating systems disabling logging in as superuser and instead offering some "sudo" way to execute single commands as superuser.

So far we are quite happy with the result. The number of bugs due to changing NewGRFs has certainly decreased. Instead we have lots of forum posts about how to change NewGRF. The amount of them feels about equal to the number of bug reports we had before. Anyway, on the forums are more people who can answer (or flame) these questions, and the developers do not have to deal with them. (sorry moderators

)

And btw. Albert's previous post about "pathfinder settings" is quite valid. I cannot imagine any setting being more hidden than the pathfinder settings. Still we regulary (*) get bug reports about trains waiting at signals or not finding the path. Luckily these bugs usually come with a savegame (at least after asking back, that a screenshot is not enough), from which you can easily tell that pathfinder settings were modified.

(*) About one every six months or so, so nothing we get too worried about. But still...

Posted: **22 Jul 2011 19:01**

So what about the dozens of people going "I downloaded the England and Wales scenario, but there are no trains available"?

I thought that problem had been fixed? If there are people still reporting that, please do tell.

Posted: **22 Jul 2011 21:34**

planetmaker wrote:
HvS wrote: I also tend to believe that issues arising from altering the GRF set on the fly are unlikely the reason for a considerable numbers of bug reports any way.
Good. So you'll handle all those bug reports:

100000 users * 10% modifying newgrfs * 1% reporting the error = 100 reports. Thus every week one or two such report. Now assume that the crash reason is not quite obvious, thus you'll have to look at the issue, ask back because only 20% supply all needed info in the first place, thus one, two hours spent EVERY week on ... nothing. Which was about right before we disabled it.

Well, everything is cognized in comparison. What are the other general reasons for a bugreport, and how many of those do you receive?

Posted: **22 Jul 2011 22:04**

frosch wrote:@HvS:
If the OpenTTD console is magic to you, then it is just as magic as a *nix console is to a GUI-focused user.

OpenTTD does require the user to know the parameters he wishes to change beforehand, from other sources - at least I don't know about methods to get man page on parameters in the game console - which parameters are endemic and cannot be guessed using prior knowledge of other games. For me, _this_ may be called somewhat of a magic, as opposed to a shell relying on UNIX principles.

frosch wrote: Also please let me tell you some history of this process.
In the old days you could freely change NewGRFs in game. At the same time OpenTTD had a lot of unreproducible crash bugs, of which noone knew what happened.

Then in OpenTTD 0.7 we (everyone shall praise smatz!) added a (from a developer point of view) great feature: The gamelog. It logged all changes to settings a player made to a game. This was the key that actually allowed us to find reasons for lots of "bugs": Players changing NewGRFs all the time, resulting in totally broken games. Before gamelog we spent hours of exploring the issues, what might have happened, and without no actual result. Compare that with the obvious messing of a player replacing road vehicles with trams on roads without tram tracks by changing NewGRFs in game.

So at this point we were able to close a lot of bug reports by just taking a short look at the gamelog. We closed tons of bug reports with a small note about changing NewGRFs being the cause, and that the player shall read the red warning before doing stuff. However, over time everyone got tired with always explaining the stuff, as players complained back "what red error message?". Some players became rude, and the developers became rude as well after closing the third bug in two days about someone refusing to have seen a red warning (despite of he must have clicked it away at least 5 times).

[...]

So far we are quite happy with the result. The number of bugs due to changing NewGRFs has certainly decreased. Instead we have lots of forum posts about how to change NewGRF. The amount of them feels about equal to the number of bug reports we had before. Anyway, on the forums are more people who can answer (or flame) these questions, and the developers do not have to deal with them. (sorry moderators )

Well, theoretically, I can see another solution to the issue: make submitting the game log mandatory when reporting a bug (no valid log - cannot submit a bug). Parse the log and reject the report if the log shows that the user has "hot-swapped" GRFs in game. Optional message "try to reproduce a bug without changing GRFs". Ignore those "some players": that "became rude" - they won't start a campagin telling people how bad OpenTTD is, so there will be no harm. If someone would really need to complain about the "bug" on the forum - there are more than enough volunteers here to sort things out in one way or another.

frosch wrote: And btw. Albert's previous post about "pathfinder settings" is quite valid. I cannot imagine any setting being more hidden than the pathfinder settings. Still we regulary (*) get bug reports about trains waiting at signals or not finding the path. Luckily these bugs usually come with a savegame (at least after asking back, that a screenshot is not enough), from which you can easily tell that pathfinder settings were modified.
(*) About one every six months or so, so nothing we get too worried about. But still...

Let me share my personal opinion with you: if the game went wrong, it is in all certainty me, the user, who is the cause. E.g. I removed the track while building for a moment - a train got lost, ignored the pre-signal and stuck. Placed a regular path signal instead of one-way PBS, a train standing in a jam tried reversed and stopped waiting for the path to clear - my fault. And so on. I have yet to see a train behave in a weird way on its own given the tracks and signalling are set properly. In my opinion thus, OpenTTD is quite a solid game. Of course, you can as well attribute my stance to the fact that I bloody love this game and it is my favorite one, and the opinion on wrongness of the removal of said option in question to the fact that I am a devoted Linux user and want to do whatever I please - at the same time not blaming others when it was clearly me who screwed things over.

Transport Tycoon Forums

Unfreedom is a problem in the world creeping even here

Unfreedom is a problem in the world creeping even here

Re: Unfreedom is a problem in the world creeping even here

Re: Unfreedom is a problem in the world creeping even here

Re: Unfreedom is a problem in the world creeping even here

Re: Unfreedom is a problem in the world creeping even here

Re: Unfreedom is a problem in the world creeping even here

Re: Unfreedom is a problem in the world creeping even here

Re: Unfreedom is a problem in the world creeping even here

Re: Unfreedom is a problem in the world creeping even here

Re: Unfreedom is a problem in the world creeping even here

Re: Unfreedom is a problem in the world creeping even here

Re: Unfreedom is a problem in the world creeping even here

Re: Unfreedom is a problem in the world creeping even here

Re: Unfreedom is a problem in the world creeping even here

Re: Unfreedom is a problem in the world creeping even here

Re: Unfreedom is a problem in the world creeping even here

Re: Unfreedom is a problem in the world creeping even here

Re: Unfreedom is a problem in the world creeping even here

Re: Unfreedom is a problem in the world creeping even here

Re: Unfreedom is a problem in the world creeping even here