NewGRF (Air)ports - general discussion

[richk67]

havnt really read the whole of this topic, but the runway number should be 09 as its facing 090^o

North, ie. 00 is directly up the y-axis of the screen. Therefore the runway is at 45 degrees, which I represent as 04. (It may be 05, but Im not sure which way the rounding goes.)

[PhilSophus]

havnt really read the whole of this topic, but the runway number should be 09 as its facing 090^o

North, ie. 00 is directly up the y-axis of the screen. Therefore the runway is at 45 degrees, which I represent as 04. (It may be 05, but Im not sure which way the rounding goes.)

I think, it is 05, but runway numbering uses magnetic north, so the difference can easily be blamed on assuming OpenTTD's north to be true north The difference can easily go above 10° in temperate and some tropical zones and even more in arctic [1].


[1] http://commons.wikimedia.org/wiki/Image ... cchart.png

[Darkvater]

Can someone give me a quick recap of the status of this?

And also, richK, if you are around: what are your plans towards newgrf_ports? Continuing, backburner, ready to possibly hand over, that kind of stuff.

Cause I might have it a go as a warm-up excercise

[cmoiromain]

oh my god! a prophet is back!

[Zuu]

Nice to see you back

Among what has happened is Dimmies java application that is demonstrating one approach for modular airports:
http://www.tt-forums.net/viewtopic.php? ... rport+java

Not that modular airports has to be the answer. Then exactly the status of the work of richK, I'm not sure. Some work on sea airports I remember. But what I remember is very much in user perspective, and may be on a way to high level for you.

[Dimme]

Regarding modular airports, this thread in the graphics forum also contains some information among a lot of discussion, espescially about flight patterns and graphical solutions:
http://www.tt-forums.net/viewtopic.php?f=36&t=39443
A good coder is actually what we need now, I can only do java for now. I'll be happy to answer any questions

Whatever solution you want to work on, it would be great to have a larger variety of airports ingame!

[CommanderZ]

C++ is not that difficult as it is said to be. If you are good in Java, you can master C++ pretty quickly. And OTTD is a great place to learn a lot about it

[Dimme]

I know, I had a course in algorithms this fall (using python), and I'm taking a course in numerical physics the next semester, which uses c++ so I will learn it. Having had a little peek at the OTTD source, I certainly understand it. Maybe I will try to write some patch when I have the time (which is not too often), but modular airports is not the place to start for me, it's such a big project that we would like it to be working properly on the first attempt...

[nezzybaby]

Regarding learning new programming languages, generally speaking all languages are the same, all you need to learn is the different syntax. There are helpful guides all over the internet, but as long as you have done at least one algorithm course you should have no problems.

My advise would be to take a program you have written in java and try to recreate it in C++, you will already have more than enough knowledge of the algorithms and program structure, but this will help you learn the syntax.

I have done this with a program for drawing madelbrots, and have managed to translate it to about 15 different languages now. My proudest achievement was translating it to an excel spreadsheet. It's amazing just how much you can do with those macros

[CommanderZ]

Regarding learning new programming languages, generally speaking all languages are the same, all you need to learn is the different syntax. There are helpful guides all over the internet, but as long as you have done at least one algorithm course you should have no problems.

My advise would be to take a program you have written in java and try to recreate it in C++, you will already have more than enough knowledge of the algorithms and program structure, but this will help you learn the syntax.

I have done this with a program for drawing madelbrots, and have managed to translate it to about 15 different languages now. My proudest achievement was translating it to an excel spreadsheet. It's amazing just how much you can do with those macros

You must also know really a lot about OTTD internals to be able to do such project like modular xPorts

[richk67]

Can someone give me a quick recap of the status of this?

And also, richK, if you are around: what are your plans towards newgrf_ports? Continuing, backburner, ready to possibly hand over, that kind of stuff.

Cause I might have it a go as a warm-up excercise

AWESOME!!! THE MAN IS BACK

I have lots of ideas, thoughts, and would not mind picking it up again into the New Year (ie. Xmas hols onwards)... but... I have hit a MASSIVE roadblock on one major request from devs: to integrate my airport duplications of newstations functionality into a single entity with newstations.

It isnt that I dont want to do it... I do. But, I have tried several different ideas, and none worked. I tried OOing all the functions, but couldnt get past a linker error, etc. I desperately want to have the integration, so that I can just add animation by linking directly to the existing newstations functions. But I fear the integration process is rather beyond my skills (in non-.Net C++ ... I could do this in .Net fairly easily I think).

Anyway, I would be delighted to have assistance to get past this mental/skill roadblock.

The other key thing is to do with the effort/reward ratio... it was going to be a massive effort to get those bits of it sorted that the devs wanted, and yet I was never assured that even if I did complete it, that it would get included. This was ...err... somewhat de-motivational.

So I would love to have a development partner on this; I have some really doozy features in now (like gradual flight paths, seaplane airports, terrain-sympathetic grass, etc.) and some great new fully working designs (LaGuardia, San Francisco), some advanced WIP airports (Munich, Schiphol), and some highly optimised versions of the normal airports. So yeah, I would love love love to get these in use in the community.

Pmail me for more info, and I will try to get onto the irc sometime soon.

Cheers, RichK

[PikkaBird]

Bump and an RFC: http://users.tt-forums.net/pikka/wiki/i ... umentation

I have a million things on my plate at the moment but this is still something I'm thinking a lot about. I still think the callback system would be both more flexible and much easier to implement...

I'll get an example airport posted when I get home this evening.

[frosch]

Cool, finally someone with actually a bit of newgrf knowledge deals with this

I can safely say that, as your specs are heading into the same direction as my attempt (about a year old) did
http://devs.openttd.org/~frosch/altnewairports.txt

Unfortunatelly I am not going to work on it though.

[SirXavius]

This is a good bump, PikkaBird. I learned something i didn't know reading this thread.

Interested in what you do here, as your work will have a direct effect on an upcoming project of mine (which is why i tried to get your help! ). Keep us updated!

[PikkaBird]

Ehhhhhhh... *head spins*... I'm not sure if I'm a genius or an idiot.

I've added some example code to the wiki page. It took me the best part of a day, and in hindsight I might have started with a slightly simpler airport. But at least it shows that the concept of a callback-based state machine is sound.

Any comments or questions are welcome; I'm sure that there are errors in my code (it's impossible to write something like this and get all the bugs out without testing). It may also be that certain details of style may need to be altered to make the system work with OTTD code. But those are minor details.

[zombie]

Hi PikkaBird.

Can I test your airport with the recent version of the NewGRF_ports branch or do I need any special version of OpenTTD?

Kind regards

Zombie

[Zuu]

Hi PikkaBird.

Can I test your airport with the recent version of the NewGRF_ports branch or do I need any special version of OpenTTD

If you read in the wiki and possible also what PikkaBird have written you'll know that PikkaBird has "only" made a proposal for a callback based NewGRF_ports implementation which has yet to be implemented by someone (or a group of people).

So you can't test it right now. Only read it and be amazed.

[Dimme]

Ehhhhhhh... *head spins*... I'm not sure if I'm a genius or an idiot.

I've added some example code to the wiki page. It took me the best part of a day, and in hindsight I might have started with a slightly simpler airport. But at least it shows that the concept of a callback-based state machine is sound.

Any comments or questions are welcome; I'm sure that there are errors in my code (it's impossible to write something like this and get all the bugs out without testing). It may also be that certain details of style may need to be altered to make the system work with OTTD code. But those are minor details.

I have a small question: if you order planes to go 6-1-2 in your example airport, will they then make a 90 degree turn? Is it necessary to have more nodes in order to make sure they only do 45 degree turns, or is there some built-in restriction to plane movement.

Nice work btw

[PikkaBird]

Is it necessary to have more nodes in order to make sure they only do 45 degree turns, or is there some built-in restriction to plane movement.

Yes, either more nodes would be required to pretty things up, or (my preferred option ) there would be some built-in limits to aircraft turning, both in the air and on the ground.

The code I posted was really just a proof of concept. No doubt if it were actually implemented some tweaking would be required.

[Dimme]

Your example airport, and especially the way you use two nodes to handle the hangar, has inspired me a little. WARNING: some technical details here, I don't care to explain everything -see the thread in my sig.

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. Here is an attempt to solve that problem:

Incredibly lousy attempt to draw an airport tile

tile.png (5.08 KiB) Viewed 3534 times

This is a tarmac tile on the airport. Aircraft can move to it, and reserve it, using node 2. Nodes 1 and 3 also belong to this tile, all tiles need up to 3 nodes (depending on how they border other tiles, for most tiles, 1 node is enough, but 2 will also be quite common). Node 1 is used to reserve movement from this tile to the one to the lower left, so no aircraft will take the opposite trip at the same time. Node 3 works similarily to the upper right.

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

For runways, one node per tile is enough, and helipads and gates only need one each.
Flight patterns in the general case was solved in the thread below
http://www.tt-forums.net/viewtopic.php? ... 3&start=40
In the general case, with only 45 degree turns, the number of nodes for the flight pattern is 8, plus 2 times the number of runways

So AFAIK, the only problem that remains in porting it, is that in my system it is not always possible to order aircraft to the hangar. The general problem is equivalent to the following:

hangarproblem.png (7.36 KiB) Viewed 3542 times

The plane marked 1, is ordered to hangar. That is of course quite impossible. The solution is to let it first finish its movement to the gate, and then order it to the hangar (in this very special case it will need to wait a while, but this is a really inefficient airport) but that must then be supported in some way.

Are anyone helpful enough to try to understand this? I'm not quite sure I got the concept right as I don't know nfo.