gks wrote:Your really optimist arent ya?
Bah,i dont know,im not a designer

Been there, argued this one dozens of times. I *do* know what Im talking about since Ive coded the new airport system.
A "build-your-own" system has the following serious flaws:
User Interface - you wont be able to just "drag-and-drop". There will be decisions to be made - like what entries onto a tile are permitted, what exits are permitted (remember that the current airport system can move pixel by pixel, not just tile by tile - and in 8 directions - arguably 9 if you include takeoff points). And somehow all this needs conveying in a simple clean way to the player.
Logic engine - if you restrict the whole system to tiles, then it is not as bad; but it still needs an engine that can detect potential locks and prevent them. Basic pathing is already built into the NewGRF_ports system - so aircraft should never cross a requested path (if properly encoded in .nfo). The logic engine would need to handle that and re-analyse the airport every time a piece is added.
Support - when problems crop up, many users badger the developers for a "fix", when the problem is really them and the nonsense airport design they have created. If such a system were introduced, then I bet none of the developers would want to support it; it might be a stock "if your self-designed airport is broken - that is your fault. Scrap it and try again."
Design efficiency - it is not the number of runways that make an airport efficient, but the speed of transfer in the runway-to-terminal, and terminal-to-takeoff taxiing. In the static designs within NewGRF_ports, I have heavily optimised these, and can get nearly the same throughput on a (new design) International (with 2 runways/6 terms), as an original Intercontinental with 4 runways & 8 terms. (I created the Intercon + Commuter btw). My brand new design "La Guardia" is a 2 runway airport in 26 tiles with 4 terms... and yet it is only just short of the throughput of a (current) International (49 tiles, 6 terms). My point being: without the programmed power of the state machine system, you will never get as efficient airports as you wont have access to some of the load balancing tricks that can be done in the FSM.
Added Value - bottom line is always whether the majority of users (ten+ thousands) will benefit from this, or whether it is just the plaything of a few (hundred). If only a few hundred, then the coding effort will not be worth it.
This idea is resurrected by somebody every couple of months... but nobody has coded anything into OTTD as a patch as yet. (There is a javascript proof-of-concept, which is nice, but even if coded into OTTD would still suffer from the GUI, Design Efficiency, and Support problems.)
Solve the first four, and maybe just maybe it will pass the Added Value test.