NewGRF (Air)ports - general discussion

[richk67]

For runways, one node per tile is enough

I'd say one bit for the entire runway is enough.

Dimme is sort of right. You have many points along a runway - taxi points, landing point(s), landing stop point(s), takeoff point(s), etc. My implementation actually works on the X,Y location in pixel terms, so you can have as many points as pixels. I often use fractional positions to make the movement look smoother. Big blocks are so clunky.

In terms of blocks, you need to unreserve the blocks necessary to ensure smooth movement. When you start having crossing runways, you have to control the block segments very carefully. Single block runways are horrendously inefficient - real airports dont do it; you can have an aircraft proceed onto the runway immediately after the inbound has cleared, whether for takeoff or to taxi to a more distant destination.

My SanFrancisco working newgrf (no proposal or paper theory here) has 4 runways in 2 pairs in a cross formation. You can have parallel landings and parallel takeoffs happening moments after each other. Its rather doozy...

BTW this airport supports short takeoffs - a short-capable aircraft takes off about 1.5 tiles earlier than a "heavy". It also has an irregular shape - no rectangles here, and the internal "grass" tile reacts to the underlying terrain. In snow, the inner triangle is snow, in temperate grass, etc. Yes, that too can be done by VarAction twiddles, but this is an actual nearly ready-now implementation, rather than myth-ware.

[richk67]

Mods. Close thread, please.

NewGRF_ports is over.

If discussion is wanted of Pikka's proposals, then he can create his own thread.

[Dimme]

Alberth once suggested me to try to convert my attempt on modular airports into a program to generate airport NewGRFs. At that time, I had no idea whatsoever how that could be done -my system needs some special reservation of movement from one tile/node to another.

The main reasons to propose that were a) we don't need both NewGRF airports and modular airports (I still believe that although I must admit I like the modular airports more from a construction point of view), b) given the amount of manual work it is to make a state machine, it would be easier if a computer can give a hand (ie let the computer handle the details of numbering states, bits, etc), or even solve the whole thing in a few seconds to minutes.

My main motivation to even look at this, is that NewGRF airports is discussed more than modular airports, and no work has been done to modular airports. I find making modular airports from scratch by far the best option, as that gives options to the player, not
some few GRF coders. I'm not sure I believe all the objections that it will be so hard to implement, I am an amateur coder, but still I managed to get the test app work. It can of course be made to support NewGRF in a similar way to newstations, graphics wise. It can also support a lot more than my small test app shows, such as multiple length runways, crossing runways, diagonal runways, diagonal taxiways, deiceing, lots of various modules, airships, seaplane airports and even with some extra work ports if that is wanted. Restrictions can be imposed on a per module basis. In any case, the first implementation can hold only what is necessary to make it work. There are some restrictions, but they cannot be compared to the restriction of having to place a whole airport as one module, IMO.

I have read the proposal by richk67, and he uses bits to denote tile reservations. Pikkabird probably also has such a notion (I didn't read it).

The extensive use of nodes may of course be an issue if there is a tight limit on the number of nodes.

I'd say that is a second problem to solve after showing that such a conversion can be done. No doubt smart tricks can be found to reduce the number of bits you need (eg compare your solution with the solution coded by Pikkabird, and see why he needs less. Then see how you can put such knowledge into the generation algorithm).

For runways, one node per tile is enough

I'd say one bit for the entire runway is enough.

As Richk said, one bit for the runway for locking it is possible, I was talking mainly about movement. Having more than one per tile makes sense.

It also makes sense that Pikkas approach will be very complicated on large airports, you won't need many airports to reach the same amount of code lines as you need to make modular airports (if that is a relevant comment). Complexity is also huge problem for NewGRF coders, my guess is only a few will try.

About the number of nodes, I think I read somewhere that in NewGRF ports there is a restriction somewhere. Maybe it was on the number of lockable areas. Not sure though.

Mods. Close thread, please.

NewGRF_ports is over.

If discussion is wanted of Pikka's proposals, then he can create his own thread.

Please...

If you are angry with the devs, don't attack the whole forum!

Regards

Dimme

[richk67]

Please...

If you are angry with the devs, don't attack the whole forum!

Regards

Dimme

Im not attacking the whole forum. Discussion of other schemes is irrelevant to NewGRF_ports. They can start their own threads.

Development of NewGRF_ports is over and done. Since there is no way that the devs would ever accept this work (even though it was requested by the Lead Coder at the time - who BTW had actually read, understood, and approved of the spec...), there is no point doing one more second of work on it.

frosch and co can have their VarAction2 nightmare, and watch the speed at which new (debugged) airports appear. Personally I predict they will catch up with my code by about 2012. Enjoy it if it ever comes.

As the driving coder behind NewGRF_ports, its my development. Its not wanted. No point continuing any debate. Other discussions can start their own threads.

[orudge]

Its not wanted.

Well, I've no idea what the difference is between your implemented solution and Pikka's proposal, since I'm not a NewGRF expert and have no time just now to investigate either of them, but NewGRF_ports was something I was quite interested in during its development, and it does look like a rather good system. I personally don't see why it can't be used, and would be quite keen for it to be integrated into the main OpenTTD trunk. I can't particularly help with that, I'm afraid, but I daresay there are more people than just me who don't want your code to go to waste.

[maquinista]

Development of NewGRF_ports is over and done. Since there is no way that the devs would ever accept this work (even though it was requested by the Lead Coder at the time - who BTW had actually read, understood, and approved of the spec...), there is no point doing one more second of work on it.

frosch and co can have their VarAction2 nightmare, and watch the speed at which new (debugged) airports appear. Personally I predict they will catch up with my code by about 2012. Enjoy it if it ever comes.

As the driving coder behind NewGRF_ports, its my development. Its not wanted. No point continuing any debate. Other discussions can start their own threads.

It's not true, I want it. I think that your code can be a great improvement to OpenTTD.

Can I download a compiled version? I have seen lots of screenshots, but... I would like to see it at work.

[TrueBrain]

As requested by topic starter: topic closed.

[orudge]

I do think, though, that if anybody else wants to show support for this project, they should do so (feel free to PM me), and if constructive debate can be had, I will reopen this topic.

[Born Acorn]

These posts have been split from the original thread to allow further discussion of this to continue.

Discussion of the old thread or the last page of discussion there should not be continued here unless you feel your posts from the last thread are relevant, in which case I can attempt a merge.

[Born Acorn]

Pikka's suggestions and following meaningful discussion have been split to here.

[maquinista]

I have two questions about this (air)ports system.
When would It be ready? Will it allow seaports?

IMHO I think that It would be better implement the richk67's code now, than wait for a new code for the future. New GRF airports would be a very interesting feature for 0.8 release.

[pavel1269]

My opinion is to use richk's proposal. His code, and if something is defined in callback, it will be used. If not, then it will use that ... default movement? ....

[Yexo]

I have two questions about this (air)ports system.
When would It be ready? Will it allow seaports?

1. When it's done.
2. Most likely it will in some way.

IMHO I think that It would be better implement the richk67's code now, than wait for a new code for the future. New GRF airports would be a very interesting feature for 0.8 release.

Yes, if it was finished. However, it's not, and finishing it may take a lot of time (no idea how much). On the other hand, implementing a new system may take more time, but if that allows the required flexibility, that's the better option.

My opinion is to use richk's proposal. His code, and if something is defined in callback, it will be used. If not, then it will use that ... default movement? ....

Did you read both proposals? Do you have any idea what the differences are? If not, please don't reply anymore.

[richk67]

My opinion is to use richk's proposal. His code, and if something is defined in callback, it will be used. If not, then it will use that ... default movement? ....

Did you read both proposals? Do you have any idea what the differences are? If not, please don't reply anymore.

Ahh... good to see that arrogance in the dev team is alive and well.

He put a question mark on the end... meaning not sure. Fair enough. No need to condescend him about it.

To answer Macquinistas questions - 1) never. NewGRF_ports is 100% dead. When will a Pikka-esque system be ready? Given the complexity of doing state machines the VarAction2 way, I reckon months just to create working debugged state machines for the *existing* current airports. As for the actual total rewrite of aircraft motion that it would require... who knows. Debugging that? Name a figure... a big one. Add in the "developer taking a break" time, and other delays... 2-3 years I think is a reasonable estimate.

2) It was always the intention to extend the use of NewGRF ports to seaports once airports was in trunk. Ships would sail freely between ports, but once the state machine entry point was reached, it would enter the port state machine and maneuver in exactly the same way (with full code re-use) as aircraft on an airport. After that, the intention was to apply the same principal to road transport - bus stations, lorry parks, with full loading bay handling etc. The concept is quite transferrable.

How close was it? With a good current dev to bring it up to date and assist on the integration task, I estimate 1 man week to complete the final hooks for newgrf vars etc. and callback support. It was always intended, but not the first thing to do - the first thing is to get the aircraft flying with their current capabilities - something it did fully.

Aircraft flew and maneuvered better than the current system, but newgrf-freaks just want things done the newgrf way.

Off you go guys...

[maquinista]

I have two questions about this (air)ports system.
When would It be ready? Will it allow seaports?

1. When it's done.

But this would mean one or two years!

I think that It would be a very long waiting for a free software project. Sometimes things doesn't go well, and these one or two years can become in lots of years.

A example of this problem is GIMP. When people ask for 16 bpp/channel support, developers says that It will come with GEGL (a graphics library), but... GEGL is a very complex project, and It has been lots of years under development (maybe 8 years). I think that developers didn't know that GEGL would take too many years. This is the GEGL developer's list. There are messages from 6 years ago.

I think that adding this support 8-10 years ago could be be better. Maybe this would mean more coding effort, but... It would attract new contributors to GIMP (donations, developers, users...).

Currently, GIMP has started to use GEGL code, but there isn't support for 16 bits images yet. Also, the next release (2. wont support it. I don't know if 16 bpp will be supported, or It will be in a forever-WIP stage of development.

[fonso]

About the turning degree thing:

At least some aircrafts can turn on the spot while taxiing. I've seen it at the old airport of Berlin-Tempelhof. The taxiway met the runway a few Meters from the runway's end. The runway was just long enough for the larger planes taking off there. In order to get the last bit of it for accelerating they actually went back on the runway. At the end they turned by 180 degrees without any wheel leaving the tarmac. Yes, that does look funny, but obviously it's possible. And I don't think Tempelhof's runway was particularly wide in comparison to others.

So, if I may talk about realism without getting shot ... there is no need to limit aircrafts in turning while taxiing.

[Born Acorn]

Re-merged on request of authors.