OpenTTD

Tasklist

FS#1674 - Account is debited for no-op station build command

Attached to Project: OpenTTD
Opened by sigra (sigra) - Monday, 21 January 2008, 00:14 GMT
Type Bug
Category Core
Status Closed
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version trunk
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Revision 11934. Build a 1x1 station on a tile. Issue a command to build an identical station on the same location. This should be a no-op but the account is debited as if a new station tile was actually built (£427 with current game data in year 1927).
This task depends upon

Closed by  Peter Nelson (peter1138)
Wednesday, 19 March 2008, 16:21 GMT
Reason for closing:  Not a bug
Additional comments about closing:  By design
Comment by Remko Bijker (Rubidium) - Monday, 21 January 2008, 06:06 GMT
It is meant to be that way, otherwise you can't upgrade your NewGRF stations. Checking whether a station is changing during the (re)build is impossible due to various complexities and random numbers send into the NewGRF. Making OpenTTD behave differently by for example not letting you pay when 'nothing' happens for sure means that there are still cases where nothing happens and you have to pay, which would be inconsistent and seen as a bug. The way it works now is imo more consistent.
Comment by sigra (sigra) - Monday, 28 January 2008, 12:14 GMT
> Checking whether a station is changing during the (re)build is impossible due to various complexities and random numbers send into the NewGRF.

That a bug is complex to fix does not change the fact that it is a bug.


> Making OpenTTD behave differently by for example not letting you pay when 'nothing' happens for sure means that there are still cases where nothing happens and you have to pay, which would be inconsistent and seen as a bug. The way it works now is imo more consistent.

Have you actually looked how it behaves now? From what you just said it does not seem so. I did and here is what I found:

Build a rail on an existing: no cost (message: "Can't build railway track here...n...already built")
Build signal on existing: no cost (only configures the existing signal)
Build train depot on existing: no cost (message: "Can't build train depot here...nBuilding must be demolished first")
Build rail bridge on existing: no cost (message: "Can't build bridge here...nMust demolish bridge first")
Build rail tunnel on existing: no cost (message: "Can't build tunnel here...nMust demolish tunnel first")
Build road on existing: no cost (message: "Can't build road here...")
Build road vehicle depot on existing: no cost (message: "Can't build road vehicle depot here...nBuilding must be demolished first")
Build bus station on existing: no cost (message: "Can't build bus station here...nMust demolish bus station first")
Build lorry station on existing: no cost (message: "Can't build lorry station here...nMust demolish lorry station first")
Build road bridge on existing: no cost (message: "Can't build bridge here...nMust demolish bridge first")
Build road tunnel on existing: no cost (message: "Can't build tunnel here...nMust demolish tunnel first")
Build canal on existing: no cost (message: "Can't build canals here...n...already built")
Build locks on existing: no cost (message: "Can't build locks here...nBuilding must be demolished first")
Build ship depot on existing: no cost (message: "Can't build ship depot here...n...must be built on water")
Build dock on existing: no cost (message: "Can't build dock here...nMust demolish dock frist")
Build boy on existing: no cost (message: "Can't place boy here...n...site unsuitable")
Build airport on existing: no cost (message: "Can't build airport here...nMust demolish airport first")
Lower land at sealevel: no cost (message: "Cant't lower land here...nAlready at sealevel")
Purchase land that one already owns: no cost (message: "Can't purcahse this land area...n...you already own it!")
Plant tree on a tile full of trees: no cost (message: "Can't plant tree here...n...tree already here")
Build rail station on existing: ¡¡¡COST!!!

What do you think is so consistent about that???
Comment by Remko Bijker (Rubidium) - Monday, 28 January 2008, 13:05 GMT
None of the above, except rail stations, can be upgraded to another type. So the rail stations are already conceptually different than any of the others you have mentioned.

About the 'impossible': it is technically impossible for 'us' to know whether a station changed because a NewGRF might (or might not) use the building date to determine the looks. If the looks of a station change you should pay for it; if it doesn't you might not want to pay for it. It is impossible to determine consistently whether this actually happens because of other things can influence the looks ok a station (for example the number of passengers/cargo).
Comment by sigra (sigra) - Monday, 28 January 2008, 14:23 GMT
> None of the above, except rail stations, can be upgraded to another type. So the rail stations are already conceptually different than any of the others you have mentioned.

Last time I checked rails could also be upgraded to another type.


> About the 'impossible': it is technically impossible for 'us' to know whether a station changed because a NewGRF might (or might not) use the building date to determine the looks. If the looks of a station change you should pay for it; if it doesn't you might not want to pay for it. It is impossible to determine consistently whether this actually happens because of other things can influence the looks ok a station (for example the number of passengers/cargo).

I suggest that the look should just be ignored in the cost calculation. It is just a decoration. If the look is not part of the actual game logic calculations, it should not have any cost either. I see it as separate levels. One game logic level that includes all the calculations. Costs belong to that level. Then there is the presentation layer on top of that, adding all the eye candy. The game logic should affect how the game is presented, but the presentation should not affect the game logic.
Comment by sigra (sigra) - Monday, 28 January 2008, 14:25 GMT
I tent to think of it in terms of model-view, see for example [http://en.wikipedia.org/wiki/Model-view]
Comment by Remko Bijker (Rubidium) - Monday, 28 January 2008, 14:36 GMT
So repainting your house costs nothing? Can I have that too? Would be really nice to have!
Comment by Zdeněk Sojka (SmatZ) - Monday, 28 January 2008, 14:51 GMT
NewGRF do not affect only the look of a sprite, but also its behaviour.
Rebuilding a station tile may change some of its properties, probably even (easily visible) result of IsStationTileBlocked(). (I haven't checked that)

edit: of course it can - build a simple station, then overbuild it by some 'eye-candy' station tile (without track)
Comment by sigra (sigra) - Monday, 28 January 2008, 14:55 GMT
I will try to reason my way to a conclusion logically. The first question to answer is whether the look of stations belongs to the model or to the view. If the look of stations somehow affect other elements of the model, they should be part of the model. That would be the case if a better looking station would for example attract more passengers or make them pay more.

But that is not the case as far as I know. So if the look of stations is part of the model, they only have a disadvantage (the cost) and no advantage. So it would be irrational to use them. Therefore they fit badly into the model and should better be in the view layer.

And assuming that the look of stations is in the view layer, it should not influence the player's account, which is in the model.
Comment by sigra (sigra) - Monday, 28 January 2008, 15:15 GMT
Some additional clarification. A criterion for whether a feature should be in the model of a game is that it should provide an interesting strategic/tactic choice that the player should make. Examples are whether it pays off to build a certain rail type instead of another or whether stronger and more expensive engines are more profitable than weaker and cheaper. A cost with no advantage to it (in the model) does not provide such a choice. So such a feature does not belong in the model. It can very well be in the view though.
Comment by sigra (sigra) - Monday, 28 January 2008, 15:22 GMT
> Rebuilding a station tile may change some of its properties, probably even (easily visible) result of IsStationTileBlocked().

According to the principles stated above, the player should pay for the property changes that give him some advantage in the game.
Comment by Zdeněk Sojka (SmatZ) - Monday, 28 January 2008, 15:30 GMT
NewGRF is rather complex, and may become even more complex.

Behaviour of a tile may be affected by tiles around it (NewIndustries chopping trees around)
Also, behaviour is dependand on Random() calls.

It is impossible to tell what tiles (and how) can ever be affected by change of one station tile.
Comment by sigra (sigra) - Monday, 28 January 2008, 15:44 GMT
> It is impossible to tell what tiles (and how) can ever be affected by change of one station tile.

Keep in mind that the original report I posted was about the case where no properties change at all. At least no properties that the user is aware of. Maybe there is a hidden property (build date) that is changed and can have a huge impact on the gameplay in ways defined outside the game engine (in data files). Then it can of course be very complex to fix this. But to a user it appears as a bug and inconsistency nevertheless.
Comment by sigra (sigra) - Monday, 28 January 2008, 15:53 GMT
This is also a usability issue. Suppose that I am building a station by placing pieces that are 5 tiles long next to each other:
=====
=====
=====

Suppose that I want one platform to be extra long:
=====
=====
=======

I should be able to just use the 5x1 tool that I have active and offset it 2 tiles. But then I would have to pay for 5 tiles when I only build 2. So I would have to move the mouse to some dialog window and change the platform length to 2, move the mouse back to the map and place the station, then move the mouse again to reselect 5x1 and move the mouse back if I want to continue building 5x1 tracks. This really interrupts the workflow when building stuff.
Comment by Remko Bijker (Rubidium) - Monday, 28 January 2008, 16:08 GMT
Not to mention that the build date (and everything else) of a station might be used to determine the cargo payment.

Furthermore making a 3x4 station and then making one platform larger moves the building on the platform so in the case you extend it to 5 at least 4 of the 5 tiles are changed.
Comment by sigra (sigra) - Monday, 28 January 2008, 16:30 GMT
> Furthermore making a 3x4 station and then making one platform larger moves the building on the platform so in the case you extend it to 5 at least 4 of the 5 tiles are changed.

I suppose that this is just a visual effect that has no influence on the game.

If the build date of a station can be used to determine so much in the game, why not also make it determine the cost to build a new station on the same tile? Then it would be (almost) free to build a station on one that was just built. That could solve the issue.
Comment by Jean-Francois Claeys (Belugas) - Monday, 28 January 2008, 17:06 GMT

Loading...