Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
DorpsGek opened this issue Jan 21, 2008 · 17 comments
Closed

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

DorpsGek opened this issue Jan 21, 2008 · 17 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

sigra opened the ticket and wrote:

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

Reported version: trunk
Operating system: All


This issue was imported from FlySpray: https://bugs.openttd.org/task/1674
@DorpsGek
Copy link
Member Author

Rubidium wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1674#comment3311

@DorpsGek
Copy link
Member Author

sigra wrote:

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???


This comment was imported from FlySpray: https://bugs.openttd.org/task/1674#comment3376

@DorpsGek
Copy link
Member Author

Rubidium wrote:

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


This comment was imported from FlySpray: https://bugs.openttd.org/task/1674#comment3377

@DorpsGek
Copy link
Member Author

sigra wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1674#comment3378

@DorpsGek
Copy link
Member Author

sigra wrote:

I tent to think of it in terms of model-view, see for example [http://en.wikipedia.org/wiki/Model-view]


This comment was imported from FlySpray: https://bugs.openttd.org/task/1674#comment3379

@DorpsGek
Copy link
Member Author

Rubidium wrote:

So repainting your house costs nothing? Can I have that too? Would be really nice to have!


This comment was imported from FlySpray: https://bugs.openttd.org/task/1674#comment3380

@DorpsGek
Copy link
Member Author

SmatZ wrote:

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)


This comment was imported from FlySpray: https://bugs.openttd.org/task/1674#comment3381

@DorpsGek
Copy link
Member Author

sigra wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1674#comment3382

@DorpsGek
Copy link
Member Author

sigra wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1674#comment3383

@DorpsGek
Copy link
Member Author

sigra wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1674#comment3384

@DorpsGek
Copy link
Member Author

SmatZ wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1674#comment3385

@DorpsGek
Copy link
Member Author

sigra wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1674#comment3386

@DorpsGek
Copy link
Member Author

sigra wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1674#comment3387

@DorpsGek
Copy link
Member Author

Rubidium wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1674#comment3388

@DorpsGek
Copy link
Member Author

sigra wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1674#comment3389

@DorpsGek
Copy link
Member Author

Belugas wrote:

Out of understanding, here are a few stations related grf specs.
Dunno if it will help the discussion

http://wiki.ttdpatch.net/tiki-index.php?page=Action0Stations

http://wiki.ttdpatch.net/tiki-index.php?page=Callbacks# Station_availability_callback_13_
http://wiki.ttdpatch.net/tiki-index.php?page=Callbacks# Station_sprite_layout_14_
http://wiki.ttdpatch.net/tiki-index.php?page=Callbacks# Custom_station_rating_calculation_145_


This comment was imported from FlySpray: https://bugs.openttd.org/task/1674#comment3390

@DorpsGek
Copy link
Member Author

peter1138 closed the ticket.

Reason for closing: Not a bug

By design


This comment was imported from FlySpray: https://bugs.openttd.org/task/1674

@DorpsGek DorpsGek added Core flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) labels Apr 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Development

No branches or pull requests

1 participant