Patch: Close airports

[zombie]

Hi.

Does this patch work in conjunction with the infrastructure sharing patch?

Kind regards

Zombie

[planetmaker]

Does this patch work in conjunction with the infrastructure sharing patch?

Yes, it works very well. You may have to fix one or two simple lines in the source though where subsequent patching fails. Indeed I consider it a very good addition to IS as only with this patch you can upgrade your airports, should they be heavy-duty.

The latest wwottdgd patch has both working and I also put a diff with both of them combined.

[cirdan]

Patches against 0.6.1 and r13374.

[planetmaker]

Thanks mate! Good work

[planetmaker]

after some time, an update to trunk. Useful for upgrading larger airports - especially in conjunction with infrastructure sharing

[planetmaker]

another update to trunk

[LiOn]

close_airports_v6_r14423:
I hope it's not only me but there is an error when resizing the airport window.

[cirdan]

Try this one.

[XxInNOutxX]

can u update it to the latest trunk?

[cirdan]

The last version I posted (against r14432) still applies against trunk (r14536), with some small offsets which can be safely ignored, and it seems to work. Which problem are you having applying it?

[XxInNOutxX]

This is what i get when i tried to patch

[cirdan]

You seem to be using some program (TortoiseSVN?) I do not know about, so the following may not be completely accurate. Apparently, the patch cannot be applied due to a context mismatch; the error suggests that the line actually found in the file ("...UpdateStationAcceptance...") does not match the one in the patch ("...END_TILE_LOOP..."). However, the patch file, as downloaded, does not have any line containing "END_TILE_LOOP". Are you sure you are trying to apply the latest version of the patch?

[YukonRob]

I just tried this and it does not work with TortoiseSVN.
Firstly - It seems that the revision declaration in your patch is in a form of '2008-05-24 04:54:47.000000000 +0200' while Tortoise seems to need '(revision 14432)'. If I change the revision declaration style it at least dl's the proper revision and patches okay.
Secondly if I change the revision to a newer one (ie. 14536) it does not patch and errors with the same error as XxInNOutxX gets. It seems that there is a small change in the source code for station_cmd.cpp in which the ...END_TILE_LOOP... appears where your patch wants to put ...UpdateStationAcceptance... (opposite of what you stated).

[cirdan]

I just tried this and it does not work with TortoiseSVN.
Firstly - It seems that the revision declaration in your patch is in a form of '2008-05-24 04:54:47.000000000 +0200' while Tortoise seems to need '(revision 14432)'. If I change the revision declaration style it at least dl's the proper revision and patches okay.

That is because the patch does not have such a "revision declaration". It is a plain diff/patch file, as created by diff(1). I have heard that Tortoise does not have a working patch(1) implementation (it cannot apply generic patches), so that may be the root of the problem.

Secondly if I change the revision to a newer one (ie. 14536) it does not patch and errors with the same error as XxInNOutxX gets. It seems that there is a small change in the source code for station_cmd.cpp in which the ...END_TILE_LOOP... appears where your patch wants to put ...UpdateStationAcceptance... (opposite of what you stated).

All right, I have just downloaded r14536 and r14546 and I think I have found what is going wrong. The patch applies to both revisions, but with some offset. So I guess Tortoise is not clever enough to realise this and bails out due to a context mismatch, instead of finding the right context four lines below, as patch(1) does (and POSIX mandates).

I am attaching another patch against r14546, but the long-term solution would be to have proper patch support in Tortoise...

[Thief^]

Tortoise supports svn patches (retrieving the version the patch was made against and merging to your revision), and "generic" patches against the exact code you have (or possibly against the exact code in the revision you're modified from, not sure which). It won't correct for code changes if it is a "generic" patch and you are at a different revision. Best to generate the patches with "svn diff" instead of "diff" if you're working from the commandline.

[planetmaker]

A small update to this patch and a version bump to v7:

new FEATURE: close airport button only shows for stations which actually are an airport.

Diff to trunk r14640 is attached.

[cirdan]

new FEATURE: close airport button only shows for stations which actually are an airport.

We have already discussed this issue, and I still think that the right thing to do is to disable, not hide, the close button for airportless stations, just like the scheduled aircraft button (or the scheduled ships button for dockless stations, etc.). It's a matter of consistency.

Plus your patch triggers an assertion if an airport is added to a station while the station window is open.

[Thief^]

Why not extend it to "close station"?
Shouldn't be too hard to make trains, rvs and ships skip to their next order when they try to go to a closed station.

[cirdan]

...which is what aircraft don't do when an airport is closed with this patch.

I'm fine with this suggestion (adding a 'skip' status to stations so that vehicles skip them), but it is an entirely different thing from what this patch does. When an airport is closed, aircraft don't skip it; instead, they keep overflying it until reopened. This is, in my opinion, the right behaviour when you want to empty the airport to upgrade it. Having aircraft fly back to their origin (I don't use aircraft routes with more than two orders) won't do them any good, and it unnecessarily increases landing pressure on the other airport. It is better to have them ready to land as soon as the destination airport is reopened.

In a sense, airports are somewhat unlike other stations: Road vehicle stations and docks are never upgraded, and train stations are, but it can be done track by track (or even tile by tile), so you can wait until a platform is clear and then convert it, even if the station is extremely busy. An airport has to be demolished and rebuilt as a whole, which requires it to be empty, and that may be difficult or impossible to achieve with heavy traffic. This is the reason why this patch is necessary (or, at least, very useful) for airports but not for other station types.

[planetmaker]

new FEATURE: close airport button only shows for stations which actually are an airport.

We have already discussed this issue, and I still think that the right thing to do is to disable, not hide, the close button for airportless stations, just like the scheduled aircraft button (or the scheduled ships button for dockless stations, etc.). It's a matter of consistency.

Plus your patch triggers an assertion if an airport is added to a station while the station window is open.

Well, we recently had a discussion concerning that on IRC. There the majority held the view that the proper way is to hide it - why should every inner city bus stop have such HUGE close airport button? But actually it got proposed to tackle it in another way than I did it here: not introducing a 2nd widget list, but to simply hide the button from view (rather than disable). I guess that solution would also help to avoid the assert which you discovered. Thanks for that.