![]() If you mean that the patch blindly upgrades an airport without checking whether there are aircraft on it or not, this is not the case. I am not sure I understand what you mean by "assumes the airport is empty". This patch assumes the airport is empty.That means a decision needs to be made first which of both proposals is better. In the NewGRF airports proposal, a different way described to upgrade. I don't see a convincing reason to not allow closing of other types of station, even if they are easier to modify while in use. The 'close airports' patch to me does not go far enough. That however means that the 'close airports' patch needs to be added to trunk before this one can be considered. Adding the 'close airports' patch #1497 would give the user a more useful way. As such, the current patch does not provide an upgrade path for a user. This patch assumes the airport is empty. However, I can see some other potential problems. Unfortunately, I am not enough familiar with airport buy/sell code to decide about your patch at code level. I do understand that the three issues aim for different things (otherwise I'd merged them). My main motivation for posting issue #1292 in both your issues is to make sure all related issues can be found easily. This comment was imported from FlySpray: In fact, this patch brings airports in line with road and rail stations, which can already be overbuilt in the current code (this makes me wonder if airports are so special that they do not deserve this feature.).Īnyway, now that someone is actually looking at this, can I please have this patch reviewed? I am providing an up-to-date patch which should apply against current trunk, and I can also provide the same patch split into three smaller patches if desired (this is the way I maintain it). But this patch addresses the second part, removing and rebuilding the station, by making the operation atomic and more UI-friendly (fewer clicks, less hassle). The first part is where airport closure or out-of-service stations help, to tell vehicles to "stay away" from the station (temporarily or permanently) so that they do not interfere. Think of it as follows: To upgrade a station (road, rail or airport-docks are different since ships do not enter the dock tiles), first you must ensure that there are no vehicles on the station, then you do the actual replacing. This patch, on the other hand, addresses a different problem, namely that of atomically overbuilding an (empty) airport, and has nothing to do with routing vehicles and the like. #1497 is indeed similar to (or a particular case of) #1292. I think you have posted the same comment in #1497 and here without noting the difference. airport-upgrade-r11637.patch (8.32 KiB)Įrr, sorry, no, this patch is completely independent of #1292.Together they make upgrading an airport really easy. Of course, this patch is most useful coupled with the close-airport patch. This patch addresses the following feature request: Requirements for the airport remain the same, except that the 2-airports-per-town rule is not checked if replacing an airport. Also, town authority ratings are checked before execution starts, so you won't find you've removed an airport and then you can't build the new one, nor rebuild the old one. Being an atomical operation means that there will be no "window of opportunity" between removing the old airport and placing the new one, so the town can't suddenly build a road or, worse, a building in the area in the interim. You just select the new airport and build it over the old one. First of all, it simplifies upgrading airports (replacing an airport type with another one, usually bigger). When doing so, the old airport is destroyed and the new one is built in an atomical way. The patch allows an airport to be built over another one, much like it can already be done with railroad stations. I would like to submit my upgrade-airport patch for inclusion in trunk.
0 Comments
Leave a Reply. |