[ Closed ] X-Life ver 1.0 (rc1, r1, ++) (Page 10 of 28)

cmckjodi wrote:

Hi so just trying to understand X Life a little better. Ok so as of now a " Verified airport" is one that is on the airport map page and X life will load it's own traffic to those airports when the program is started. So how does one use an airport that is Not verified? For instance I loaded an airport that I made ATC routes for that checked out ok in WED, the planes appeared but there was no traffic movement. Is X-life very strict how taxi routes are created? Perhaps my pushbacks from gates were not created properly for X- life to use? I'm just not sure. Also when I tried to file a flight plan X life would not allow the un verified airport. Seems as like there are some limitations to X life or it's more about me not knowing more about the program which is probably more to the point. Is there a user manual available? That is something that's really needed here. Any advice from experienced users is welcome!

Unverified airports work just fine if the ATC Taxi Routes are well done!
The Ramp-ATC Route connections and the Route-Runway connections are the most critical. Follow the rules IN DETAIL!
You will get it to work. It took me a long time but KBOS traffic and ATC is now working perfectly (except that the FM car is sometimes doing strange things - I need to refine the routes even more) and it's not on the verified list.

bujablaster wrote:

pic wrote:

Hi..yes, remove WT plugin. And yes, XL will crash if you use an airport not in XL. (it does for me too)

That's strange. My XP never crashed when i tried to activate it on airport without ATC routes data. It simply didn't turn on any traffic, but definitely not crashing (same behavior with last beta versions and actual RC 1.01r of XL). It must be some another plugin interfering with XL.

Well, that was with a way earlier beta. I just stopped using airports not in the data base all the way to this latest release (habits hard to break!)..soooo, since everyone is saying it works, I'll start loosening up on that! Good to know..thanks a bunch!

Ver 1.1 beta 3 posted. Try to fix some kinds of CTDs, improve radio freq digits pronounce, back a319-320 and 737 to traffic.

Thanks for all your comments! Will continue..

captbullett wrote:

J.A.Romanov wrote:

Ver 1.1 beta 3 posted. Try to fix some kinds of CTDs, improve radio freq digits pronounce, back a319-320 and 737 to traffic.

Thanks for all your comments! Will continue..

Good day,
not geting a good download on this version on a mac
B.

Same here. .zip file has a problem and will not unzip

I do not think it is impossible, if you get help from the community, and develop tools for this, it will work.

First step is to have a major system for centers, which you can build and fragment on. It is up to Romanov which level to start on. Let us say he starts from a state of 1 (which in this example is number 1), and the other states may be filled in by users, almost in the same way as airports are updated at the current state:

State 1. One center for whole of the world with a default frequency, stretching from GND to UNLIMITED altitude.
State 2. One center for every country, defined by a polygon, and with a custom lower and upper limit.
State 3. Segments of centers in a country, with custom lower and upper limits.
(State 4. TMA <- approach, departure, radar)
(State 5. CTR <- tower)

NOTE: airspaces may overlap in a a 2D view, but they should not overlap in 3D space (i.e. airspaces may have the same polygon and position, but at different lower and upper limits, not intersecting each other; TWR below TMA, TMA below CENTER, CENTER below another CENTER and so on).

If there is no state 5 airspace at the position of aircraft, use state 4 airspace, if there is no state 4 airspace, use state 3 airspace, and so on until default state 1 airspace. Of course we could simulate uncontrolled airspace, so we need to be able to setup rules if an aircraft is i.e. below the altitude/flightlevel of a state 2, 3, 4 or 5 airspace. This is only possible if any of this airspaces is defined.

State 2 and 3 airspaces (centers in this case, needs to manually made my the community). The state 4 and 5 airspaces (TMA and CTR) can be retrieved from www.openaip.net, and covers most of Europe and North America.

The requirements for everything to work is to:
1. Make the plugin able to read the data from openaip format (which is open  and easy to parse I think). Also the plugin needs to combine this data with user set of frequencies for TMA and CTR:s.
Because it seems openaip does not support frequencies (I guess), X-Life may modify the openaip data for its own best by just adding a slot for frequency, or pair an openaip file with its own frequency file.

2. A tool for the community which can load and save openaip data, where users may
* read TMA, CTR and CENTER airspaces graphically
* edit TMA and CTR airspace frequencies
* edit/create CENTER airspaces as polygons, and set its frequencies and lower and upper limits.
* maybe able to also create TMA and CTR airspaces with polygons if the area is not covered by openaip

As an alternative to option 1, is to make everything out from scratch and X-Life using its own format.

An important note here, some manually action is required here to align the borders of centers between FIR:s, i.e. let us say user A creates a CENTER airspace for Sweden FIR, while user B is using creates a CENTER airspace for Norway, the border between these two FIR:s needs to be aligned with each other.

Vantskruv wrote:

I do not think it is impossible, if you get help from the community, and develop tools for this, it will work.

First step is to have a major system for centers, which you can build and fragment on. It is up to Romanov which level to start on. Let us say he starts from a state of 1 (which in this example is number 1), and the other states may be filled in by users, almost in the same way as airports are updated at the current state:

State 1. One center for whole of the world with a default frequency, stretching from GND to UNLIMITED altitude.
State 2. One center for every country, defined by a polygon, and with a custom lower and upper limit.
State 3. Segments of centers in a country, with custom lower and upper limits.
(State 4. TMA <- approach, departure, radar)
(State 5. CTR <- tower)

NOTE: airspaces may overlap in a a 2D view, but they should not overlap in 3D space (i.e. airspaces may have the same polygon and position, but at different lower and upper limits, not intersecting each other; TWR below TMA, TMA below CENTER, CENTER below another CENTER and so on).

If there is no state 5 airspace at the position of aircraft, use state 4 airspace, if there is no state 4 airspace, use state 3 airspace, and so on until default state 1 airspace. Of course we could simulate uncontrolled airspace, so we need to be able to setup rules if an aircraft is i.e. below the altitude/flightlevel of a state 2, 3, 4 or 5 airspace. This is only possible if any of this airspaces is defined.

State 2 and 3 airspaces (centers in this case, needs to manually made my the community). The state 4 and 5 airspaces (TMA and CTR) can be retrieved from www.openaip.net, and covers most of Europe and North America.

The requirements for everything to work is to:
1. Make the plugin able to read the data from openaip format (which is open  and easy to parse I think). Also the plugin needs to combine this data with user set of frequencies for TMA and CTR:s.
Because it seems openaip does not support frequencies (I guess), X-Life may modify the openaip data for its own best by just adding a slot for frequency, or pair an openaip file with its own frequency file.

2. A tool for the community which can load and save openaip data, where users may
* read TMA, CTR and CENTER airspaces graphically
* edit TMA and CTR airspace frequencies
* edit/create CENTER airspaces as polygons, and set its frequencies and lower and upper limits.
* maybe able to also create TMA and CTR airspaces with polygons if the area is not covered by openaip

As an alternative to option 1, is to make everything out from scratch and X-Life using its own format.

An important note here, some manually action is required here to align the borders of centers between FIR:s, i.e. let us say user A creates a CENTER airspace for Sweden FIR, while user B is using creates a CENTER airspace for Norway, the border between these two FIR:s needs to be aligned with each other.

Like this idea. We can simplify it, and still have a real effect. I think, at first we should go to airliners. This is in Europe and the rest of the world more easy, because these zones are clear. Once, XL is stable, we (Romanov ) could work on VFR rules. Here is the work.

Cheers
Thomas

Test flight LICC-LGAV
JAR A320 2.6.1
X-life 1.1b2
SMP Latest + RWC
FM car
on my iMac27 OSX 10.9.5

No crash

LICC: great airport, busy air and ground traffic. FM car working well

LGAV: Nice airport, traffic OK, but

just before landing another AI aircraft on hold short stays green and entering runway

Calling FM car it appears far away from taxi way

I wonder how and why XL is programmed to advice nearly every time parking lots that are outside of terminals !?

Question to JAR: reporting such occurrences, du you need also the log.txt?  Are images useful for you?

Addition: Using XL v.1.1b3.  I made a second test flight LICC/LGAV because of recording failure. this time I looked for a while on the LGAV scenery and traffic. It turned out that taxiways are not marked properly or that aircraft are moving off these ways. Airplanes take-off also do not take place on the runways but beside them on the sand strip. Landings however happen correct almost in the middle of the runways.

Another important observation: take-off of bigger AI airliner seems to show double  aircraft simultaneously !!!

I am preparing a video about LX, ATC, traffic, take-off, Approach and landing, FM car. XL v.1.1b3