Transport Tycoon Forums

Inspired by OGFX+ Aitrports NewGRF (http://www.tt-forums.net/viewtopic.php?f=26&t=47475) .
Allows building of seaplane airports without the need for "pause+build water tiles objects" hack.

Features:

• Seaplane airport class in build airport UI
• Build seaplane airport on water
• Restore water tiles after demolition

Known problems (things I don't know how to fix):

• Building of seaplane airports on canals of competitors is allowed
• Seaplane airport pevents flooding
• Seaplane airport class visible in build airport UI even when no seaplane airports are loaded

Not tested

• Network play

Not implemented (so far)

• Aircraft class seaplane
• Pathfinding (to prevent pathfinder to try landing regular airplane on seaplane airport and vice versa
• ...

To define a seaplane airport in NewGRF set Action 0 property 12 to 01.

Has anybody tried this ?

I've tried it and no bugs so far!

I have decided to continue work on this patch. To declare airport as suitable for seaplanes, I have defined AirportClassID "APC_SEA", since only seaplanes will be able to land on this type of airport. The problem is, there is no direct way to set AirportClassID from NewGRF. I have researched several options how set class. I need opinion on what to choose.

Property 0x12 for Action0 - class override.
This option adds new propery to Action0 for airports. The value will be byte and same as one of AirportClassID.

• Pros:
• Easy to implement (in fact it is already implemented in first version of this patch)
• Class override may be used in other NewGRFs
• Allows seaplane version for any airport/heliport

• Cons:
• NewGRFs declaring seaplane airport would need special version for openttd witout this patch (beacuse of unknown property error)
• NMLC would need patching to allow this property

TTDPAirportType misuse(?)
This option misuses TTDPAirportType to hold information about seaplane acceptance with either defining new TTDPAirportType or somehow encode seaplane acceptance information in in (ex, first bit as flag). I was not able to find what TTDPAirportType is used for, so mangling with this may have weird consequences or is obsolete (PM me if you know).

• Pros:
• NewGRF stays compatible with unpatched game
• No need for NMLC patch
• Allows seaplane version for any airport/heliport

• Cons:
• Hacky solution
• I don't know consequences of mangling with this property.

Hardcoding new basic AirportType to be overriden
This option creates new default airport, which could be overriden by NewGRF to create seaplane airport

• Pros:
• No need for NMLC patch to add support (class provided by setting "override" do correct value)

• Cons:
• NewGRFs declaring seaplane airport would need special version for openttd witout this patch
• Would allow only one airport layout
• Would need workaround to hide the seaplane airport if not present in NewGRF

EDIT: changed NLM to NLMC to prevent confusion between NewGRF source files and NML as language

Don't worry about existing NewGRFs and move on. Old seaplane airport will remain a "normal airport" which only fakes it's a seaplane and that's really OK because you are not making any further "harm". Also don't worry about NewGRFs which "work with patch but not in vanilla". Nobody won't create a real vehicle set that works only with a patch .

1 and 3 would have to be done both and 2 breaks stuff. Anyway, none of the options seems feasible. I think that NewGRF creators should be able to add as many seaplane airports as they want, not just override existing ones. You should probably define a new airport property - "flags". One (and only, yet) flag would be "this is a seaplane airport".

adf88 wrote:Don't worry about existing NewGRFs and move on.

I don't think adding any of these options would affect old NewGRFs in any way. By "patching NML", I was referring to language, not to source code of older NewGRFs. It should be "patching NMLC"/"patching NML compiler". My bad.

adf88 wrote:You should probably define a new airport property - "flags".

I think this is like my option 1, but it would allow further flags in future without breaking anything. It still has a problem of unknown property and need to patch NMLC to allow it add this property to NewGRF. Maybe treat "Unknown property" when loading NewGRF as a warning and not as fatal error in vanilla would help.

adf88 wrote:I think that NewGRF creators should be able to add as many seaplane airports as they want, not just override existing ones.

Option 1 allows new airports. The property in NML is called "override" but it effectively clones the airport and the properties are set for the clone.

Anyway, so far I have implemented option 1 in my patch.

All seaplane airports no matter how big are in tab "Seaplne airports" in GUI. (May change in future).

For airplanes I have added new property PROP_AIRCRAFT_LAND_SURFACE which is flags for which surfaces the aircraft can land on (ALS_SOLID, ALS_WATER). If no landing surface is set, then ALS_SOLID is added to aircraft for backwards compatibility. This allows for creation of seaplanes, amphibious planes even water landing and amphibios helicopters.

Roslav wrote:

adf88 wrote:Don't worry about existing NewGRFs and move on.

I don't think adding any of these options would affect old NewGRFs in any way. By "patching NML", I was referring to language, not to source code of older NewGRFs. It should be "patching NMLC"/"patching NML compiler". My bad.

I was trying to say ht you shouldn't bother on how current "Seaplane Airport" is implemented. Just forget about this GRF.

Roslav wrote:It still has a problem of unknown property and need to patch NMLC to allow it add this property to NewGRF. Maybe treat "Unknown property" when loading NewGRF as a warning and not as fatal error in vanilla would help.

This is not a problem as I explained before. If you have a GRF meant for a patched OpenTTD, then that GRF is not meant for vanilla.

Roslav wrote:Option 1 allows new airports. The property in NML is called "override" but it effectively clones the airport and the properties are set for the clone.

Yes, it would allows to override the airport, but it wouldn't allow to put X different seaplane airports into single GRF, or to create an alternative seaplane airport and keep the original one.