Board index FlightGear Support Tools OpenRadar

Preview version on the way

OpenRadar is a standalone radar screen which connects to the FlightGear multiplayer servers. It is currently being developed.

Re: Preview version on the way

Postby a-v-o » Tue Sep 20, 2016 8:50 pm

jomo wrote in Tue Sep 20, 2016 10:12 am:I was using the new Version now in 8 sessions and [...]

Thanks for giving it a try and your feedback.

jomo wrote in Tue Sep 20, 2016 10:12 am:I just would suggest to input all data that get defined inside the ATC-FlightPlan [...] direct as initial values into the "tartget-fields" of the strip

In the flightplan dialog there are current flight assignments mixed with data of the flightplan. A flightplan should be created before departure and should be valid for the whole flight, so that no change should be necessary by the ATC. On the other hand assignments (for altitude, heading, speed) are done during the flight by the ATC and can be changed on the flightstrip.

jomo wrote in Tue Sep 20, 2016 10:12 am:and cancel the target field AFTER the target has reached those values (first time).

I don't know what you mean. Can you give an example?

jomo wrote in Tue Sep 20, 2016 10:12 am:Values I especially miss are: Assigned rw, planned cruising alt, direct hdg to destination.

Image
You can see the assigned runway RW33 (assign it with double-click onto runway label in the runways panel), cruising alt FL320 is shown in the middle and heading to destination 192° is shown on the rightmost side after the destination airport.

I plan to implement user-defined flightstrips, so that you can create your own flightstrip layout, e.g. a ground controller can have fields for apron or parking position or whatever he wants to note on his flightstrip and without having fields like assigned altitude, current altitude and vertical speed on the flightstrip.
a-v-o
 
Posts: 32
Joined: Wed Jan 20, 2016 1:34 am

Re: Preview version on the way

Postby a-v-o » Tue Sep 20, 2016 10:13 pm

jomo wrote in Tue Sep 20, 2016 10:12 am:Thus we may need a standard setting which must be able be reset the standard setting (at installation) with one Click (for sure without reinstalling!)! So everybody can fool around with those options - and recover whenever lost in the jungle! (Pls. consider: There are lots of ATC not being trained as Software specialists).

Actually there are 2 hard-coded (standard) settings that you can apply with 3 mouse-clicks: example and traditional. So everyone can indeed fool around and set it back to these hard-coded settings.
There's no problem to implement standard settings which offers beginners a helpful flightstrips-bay. Suggestions about sections and rules are welcome.

jomo wrote in Tue Sep 20, 2016 10:12 am:
    Displaying in "example" mode, I could only see a few sections (depending on how may targets are in the area). And I could not move the List up down to see them all - there always remained about 1/3 of room for the "empty click-area" to call up settings.

Can you provide a screenshot?
The whole flightstrips-bay should be filled and a scrollbar should appear when there are more flightstrips.

jomo wrote in Tue Sep 20, 2016 10:12 am:
    In general: For me I do not see a usage of this mode when working as a single ATC - It is practically not possible to keep a constant watch on all traffic!

As the name says: it's an example to demonstrate what is possible, not what is best choice to use. Though my personal settings are close to the example, because I often do have sudden appearing other local ATCs and can then easily separate "my contacts" from the other ATC's contacts. But see it as an example for demonstration and let's discuss about standard settings for a single ATC which will be usable for beginners, too.

jomo wrote in Tue Sep 20, 2016 10:12 am:But I was not able to change e.g. the colours of the targets in their different columns.

Actually colors are hard-coded. It is on my ToDo list to have something like a color manager to customize colors.

jomo wrote in Tue Sep 20, 2016 10:12 am:May be we need more infos on what "Condition(s)" are available - and how to pick them.

There's a complete list of conditions with explanations on this wiki page:
http://wiki.flightgear.org/OpenRadar:_Flightstrips-Bay
Changing colors would rather be a subject of actions, but it isn't implemented, though I thought about it.

jomo wrote in Tue Sep 20, 2016 10:12 am:During the sessions i noticed intermittently very long response-times. These are very very disturbing when you have many targets under control, some to be handed by keyboard and mouse - You then very often use mouse and/or keyboard and do not notice that the input intermittently is not taken, i.e. because those are locked for several seconds.

If input into a field of a flightstrip is not taken, then maybe you didn't confirm the value by hitting ENTER. If you just enter the digits 210 into the field to assign a new altitude, then it just shows the digits 210. After you hit ENTER, 210 is translated (locally) into FL210. FL210 is then put (locally) into the flightplan dialog data field. The flightplan dialog data is sent to the flightplan exchange server. Independently the flightstrips are updated in the update cycle which uses local flightplan dialog data. So local assignments should show up immediately: 210 is then replaced by FL210 in the edit field and a message is created in the chat edit field.

jomo wrote in Tue Sep 20, 2016 10:12 am:In addition I have the feeling that all the options are delaying the OR functions when there are may targets (more then 10 in the 100 mi area). Could it be that the program always has to go through all the tables to define the settings for each target? I believe at OR-start only 3 strings should be defined - containing all the options for the left/right positions of the target in the Bay. Thus the "BIG Option-tables" need to be searched only once at startup (or when options have been changed).

I'm not sure if I get you right here. The traditional layout has only 3 rules (or 4 if you added the neglect-rule). The example layout has like 20 rules. In each update cycle OR searches for each flightstrip the first matching rule, so for uncontrolled traffic there are at maximum 3 or 4 rules to check in the traditional layout and 20 rules to test in the example layout. There might be some optimization possible, but that requires some rework of OR.

jomo wrote in Tue Sep 20, 2016 10:12 am:To the documentation: I believe we are getting lost in the amount of documentation available for OR!

As OR changes, also the documentation should change. I don't think everybody must read e.g. the Feature Wishlist, but for those who think about a feature, they can see what is already thought or discussed.

jomo wrote in Tue Sep 20, 2016 10:12 am:I suggest to use the http://wiki.flightgear.org/OpenRadarGuide as the major description -- and link from there to all other Unique features (that still are needed) - so we have one starting point to study/search/include/verify/etc -- as well as for the knowledgeable people as well as for beginners. I tried to start to complete the "Related content" in the Guide - but will not have much time this year to do much more.

I thought is was intented and actually is like that. I didn't link to the pages flightstrip and flightstrips-bay to avoid confusion for beginners because this isn't part of the official version, even the preview version with this features isn't officially released.
a-v-o
 
Posts: 32
Joined: Wed Jan 20, 2016 1:34 am

Re: Preview version on the way

Postby jomo » Sun Sep 25, 2016 5:38 pm

if you did download the newest OR-version from https://sourceforge.net/projects/openra ... urce=files then notice that for adjusting the OR-Cam-views you do not use the "right mouse click" - but in future the "centre mouse-click".

Sorry a-v-o
I had no time yet to reinvestigate and prepare example-read-outs. Hopefully this week.
jomo / ATCjomo + EDDFjo + EDDFjo1 + EDDFjo2
ATC at EDDF Fr,Sa,Su,We from 20:00 to 24:00 CET/MEZ., see http://www.emmerich-j.de
User avatar
jomo
 
Posts: 1000
Joined: Thu Feb 12, 2009 7:46 pm
Location: Mainz, Germany
Callsign: jomo EDDFjo1+2
OS: UBUNTU 18.4

Re: Preview version on the way

Postby jomo » Thu Sep 29, 2016 9:54 am

a-v-o wrote in Tue Sep 20, 2016 10:13 pm:
jomo wrote in Tue Sep 20, 2016 10:12 am:Thus we may need a standard setting which must be able be reset the standard setting (at installation) with one Click (for sure without reinstalling!)! So everybody can fool around with those options - and recover whenever lost in the jungle! (Pls. consider: There are lots of ATC not being trained as Software specialists).
Actually there are 2 hard-coded (standard) settings that you can apply with 3 mouse-clicks: example and traditional. So everyone can indeed fool around and set it back to these hard-coded settings. There's no problem to implement standard settings which offers beginners a helpful flightstrips-bay. Suggestions about sections and rules are welcome.
This touches our general disagreement: I cannot see any advantages in a "flightstrips-bay" that offers unique spaces for different ATC-taskes - when all those tasks must be performed by 1 ATC! During my work I constantly sort my targets according to the "priority to the poor ATC that has to handle them all - concurrently". There I use basically the prioritization within the 3 Lable-Columns to differentiate:
    * Left: Active under my Control (color blue), the closer the control (e.g. Reporting in, Approach, Final, Gnd)
    * Center: under my Ctrl - but NOT active = "Keep an eye on it". (e.g. taking a break, is heading towards me but not yet signed in, just passing through my area with my Radar Surveillance active, etc.)
    * Right: Nothing to do with me
Quite frankly I cannot image to handle multiple "Bays" with multiple left/centre/right positions/meanings - as a single ATC. I am not against having that opportunity for special events - but not as the major usage! So the major/basic OR should be privileged! Right now there is 1 Layout for "traditional" described - and 9 for "example". I would like to define more support for the "traditional" way, e.g. in regards to
    * color (maybe the most left "blue" should change to the now most right "green")
    * sorting automatic within those columns e.g. by distance, priority,
    * etc.
I have no idea if I can do something or how ..

a-v-o wrote in Tue Sep 20, 2016 10:13 pm:The whole flightstrips-bay should be filled and a scrollbar should appear when there are more flightstrips.
see picture http://www.emmerich-j.de/EDDF/Films/tem ... ble%20.png It ends at the border of radar-screen and is not expandable/moveable.

a-v-o wrote in Tue Sep 20, 2016 10:13 pm:
jomo wrote in Tue Sep 20, 2016 10:12 am:During the sessions i noticed intermittently very long response-times. These are very very disturbing when you have many targets under control, some to be handed by keyboard and mouse - You then very often use mouse and/or keyboard and do not notice that the input intermittently is not taken, i.e. because those are locked for several seconds.
If input into a field of a flightstrip is not taken, then maybe you didn't confirm the value by hitting ENTER. If you just enter the digits 210 into the field to assign a new altitude, then it just shows the digits 210. After you hit ENTER, 210 is translated (locally) into FL210. FL210 is then put (locally) into the flightplan dialog data field. The flightplan dialog data is sent to the flightplan exchange server. Independently the flightstrips are updated in the update cycle which uses local flightplan dialog data. So local assignments should show up immediately: 210 is then replaced by FL210 in the edit field and a message is created in the chat edit field.
I am not sure if that is the only cause - but if I handle e.g. 8 targets same time, then for sure I am not always checking if the entrance is taken. May be we could do that as done previously: All Inputs are take when the mouse-pointer exits the FlightStrip. Because then you can do multiple changes to one FlightStrip - and take them all at once. Hitting Enter is an extra, not needed action - and is often destroying the action-string if updating several data in 1 FlightStrip (e.g. hdg + alt + ++ - just by TABmovement).
Are you sure it is not (often) waiting for the acceptance from the server?

a-v-o wrote in Tue Sep 20, 2016 10:13 pm:
jomo wrote in Tue Sep 20, 2016 10:12 am:I suggest to use the http://wiki.flightgear.org/OpenRadarGuide as the major description -- and link from there to all other Unique features (that still are needed) - so we have one starting point to study/search/include/verify/etc -- as well as for the knowledgeable people as well as for beginners. I tried to start to complete the "Related content" in the Guide - but will not have much time this year to do much more.
I thought is was intented and actually is like that. I didn't link to the pages flightstrip and flightstrips-bay to avoid confusion for beginners because this isn't part of the official version, even the preview version with this features isn't officially released.
Well - the problem is the other way around: I guess nobody starts with "Flightstrips-Bay" - at least I tell everybody to start with the "OpenRadarGuide". In that is also a section http://wiki.flightgear.org/OpenRadarGui ... ip_Manager and also a http://wiki.flightgear.org/OpenRadarGui ... Management . Those descriptions and pictures are not showing any more what they will see on the screen when working with OR!
jomo / ATCjomo + EDDFjo + EDDFjo1 + EDDFjo2
ATC at EDDF Fr,Sa,Su,We from 20:00 to 24:00 CET/MEZ., see http://www.emmerich-j.de
User avatar
jomo
 
Posts: 1000
Joined: Thu Feb 12, 2009 7:46 pm
Location: Mainz, Germany
Callsign: jomo EDDFjo1+2
OS: UBUNTU 18.4

Re: Preview version on the way

Postby a-v-o » Thu Sep 29, 2016 12:03 pm

jomo wrote in Thu Sep 29, 2016 9:54 am:This touches our general disagreement: I cannot see any advantages in a "flightstrips-bay" that offers unique spaces for different ATC-taskes - when all those tasks must be performed by 1 ATC!

Actually this is, well, I won't name it a disagreement but more different experiences: There are sometimes other ATCs at my airport or in my radar range, so I do share tasks with other ATCs.
On the other hand I experienced aircrafts being parked at my airport or other ground vehicles like FollowMe, motor cycles etc. And I want them separate from the regular ground activities.
Then there are sometimes copilots or passengers. Have you ever controlled a passenger? I want to have those "co-flights" separate from the regular flights.
In KSFO you can often find a carrier. Not a problem in EDDF I guess. But near the coast there might appear a carrier.
Then there are some helicopters, balloons or blimbs which should be handled different from planes.
This is some of the diversity I realized during my ATC sessions.

So your conclusion is correct: The traditional layout seems to be best suitable for you. And that's the layout that is default after downloading and installing. Noone is forced to use different sections or any of these features.

jomo wrote in Thu Sep 29, 2016 9:54 am:I would like to define more support for the "traditional" way, e.g. in regards to
* color (maybe the most left "blue" should change to the now most right "green")
* sorting automatic within those columns e.g. by distance, priority,
* etc.

For color see a previous post. I either didn't like them, so I changed them for my personal version in code. Actually I use the color of the contact in the radar screen to show me the altitude. Examples: If a contact is red then it is (almost) down to the ground. If there are 2 contacts with the same color near to each other, then this is (or might become) a conflict situation.

Image
In this example from the wiki-page you can see "sort by distance" (for more information: http://wiki.flightgear.org/OpenRadar:_Flightstrips-Bay#Configure_a_section)

jomo wrote in Thu Sep 29, 2016 9:54 am:see picture http://www.emmerich-j.de/EDDF/Films/tem ... ble%20.png It ends at the border of radar-screen and is not expandable/moveable.

OK, you found the "bug": There are 3 values in conflict with each other: 1. the maximum width of the flightstrips-bay, 2. a fixed width for the spacer for each column and 3. the minimum width of a flightstrip required to show all labels and fields.
The flightstrips-bay is still at the width of a 3 column design. But as "Ground" section has 5 columns, Java produces an error when a flightstrip is in this section.
Actually I don't know how I can calculate the minimum required width of a flightstrip for different operating systems and fonts. But I keep that problem in mind.

Simple solution: Just increase the width of the flightstrips-bay by dragging the vertical white bar to the left. The layout will restore immediately. A 3 column layout like traditional won't have this problem.

jomo wrote in Thu Sep 29, 2016 9:54 am:May be we could do that as done previously: All Inputs are take when the mouse-pointer exits the FlightStrip. Because then you can do multiple changes to one FlightStrip - and take them all at once. Hitting Enter is an extra, not needed action - and is often destroying the action-string if updating several data in 1 FlightStrip (e.g. hdg + alt + ++ - just by TABmovement).

There is no previously as you couldn't enter anything on the previous flightstrips.
It was/is a dialog which you leave when clicking outside the window or when you hit enter in e.g. remarks.
Have you tried TAB movement? It opens the context menu.
With the first ENTER you tell the program that you've finished your entry and it creates a chat message for you (which you can edit as the keyboard focus is moved to the chat edit field). With a second ENTER you can send this message.
So you type FL200 [ENTER] [ENTER] and the following text message will be sent:
Example: D-1234: Climb and maintain FL200

jomo wrote in Thu Sep 29, 2016 9:54 am:Are you sure it is not (often) waiting for the acceptance from the server?

When you see the created chat message, then you know that you hit ENTER.

jomo wrote in Thu Sep 29, 2016 9:54 am:[...]start with the "OpenRadarGuide". In that is also a section http://wiki.flightgear.org/OpenRadarGui ... ip_Manager and also a http://wiki.flightgear.org/OpenRadarGui ... Management . Those descriptions and pictures are not showing any more what they will see on the screen when working with OR!

The version you are testing is a preview version not the official release, so those descriptions and pictures are still valid for the official release.
For the preview release there are the informations and links in this thread.
When the preview release becomes the official release after being accepted by the ATC community, then we can remove/replace the outdated informations and pictures.
One step after the other
a-v-o
 
Posts: 32
Joined: Wed Jan 20, 2016 1:34 am

Re: Preview version on the way

Postby jomo » Fri Sep 30, 2016 6:18 am

a-v-o wrote in Thu Sep 29, 2016 12:03 pm:Actually this is, well, I won't name it a disagreement but more different experiences.

Yes it looks like that.
My main concern is enhancing the use of MUMBLE and FlightPlans. If you look in MPmap or the http://h2281805.stratoserver.net/FgFpServer/ you might notice that you mostly see several ATC's active throught central Europe - mostly not in the 100mi range. So for communicating with other ATCs I am pretty satisfied with the transferring-actions within the FlightPlan handling (mouse-center-click on target - select "H/O to"). Being at about 50% usage of "mumble" the typing is seen more and more "as a pain in the a...". So my priorities are:
    * major Data entered into the ATC-FP (even if imported from Lennys FP) must show up in the FlightStrip. Thus the first and major entrance of the FlightStrip is the ATC-FlightPlan (center-mouseclick onto target)
    * advise to targets via radio must be "easely" xferred into the FlightStrip (best automatic with speaking --> to type) (I accept, that is just a dream right now!)
    * also all mouse-click-date must be inserted (e.g. Runway from active runway list)
    *etc.
In general that means: I do not see the FlightStrip and/or FlightStrip-Bay as the major Input- and/or Communication tool - but as a collector for all data-exchange with the targets - in whatever way the data were exchanged!

Just to avoid confusion: With "done as previously" I mean e.g. the changes done in the ATC-FP screen. Which I still see as mandatory - because as of today you definitely need some additional infos there - not all are provided on the Strip!

a-v-o wrote in Thu Sep 29, 2016 12:03 pm:The version you are testing is a preview version not the official release, so those descriptions and pictures are still valid for the official release.
What do I tell someone who wants to start with OpenRadar (or reload it) where to find the OldVersion for download?
jomo / ATCjomo + EDDFjo + EDDFjo1 + EDDFjo2
ATC at EDDF Fr,Sa,Su,We from 20:00 to 24:00 CET/MEZ., see http://www.emmerich-j.de
User avatar
jomo
 
Posts: 1000
Joined: Thu Feb 12, 2009 7:46 pm
Location: Mainz, Germany
Callsign: jomo EDDFjo1+2
OS: UBUNTU 18.4

Re: Preview version on the way

Postby a-v-o » Fri Sep 30, 2016 10:51 am

jomo wrote in Fri Sep 30, 2016 6:18 am:What do I tell someone who wants to start with OpenRadar (or reload it) where to find the OldVersion for download?

I had a closer look at the "Files" at SourceForge:
With the "Download" button on the "Summary" page you get the latest release which is from 2016-08-24.
On page "Files" it is named "Next release".
The older version from 2016-04-13 is named "Latest release".

I didn't notice that the Preview version (2016-08-24 Next release) was already available for download. In this case you're right that the documentation should be updated.
a-v-o
 
Posts: 32
Joined: Wed Jan 20, 2016 1:34 am

Re: Preview version on the way

Postby jomo » Sat Oct 08, 2016 9:35 am

I am now trying to define a "personal" layout using the latest OR-release (OR.jar 20160924) and FlightStrips-Bay and found some Problems and NiceToHave's:

*Problems:
    ** since working with this new version of OR (including Strip-Bay) I mostly get at least 1 Mouse-Hang during those 4 h events. i.e. OR does not react onto mouse actions any more, like: clicking, moving, scrolling, etc. The mouse still works on all other programs/windows - but I am not even able to close the OR-Window! I have to "kill" the java and restart OR.
    See e.g. film http://www.emmerich-j.de/EDDF/Films/201 ... 049-62.ogv starting at ~23:43 UTC: You see me trying to produce mouse actions
    and Log http://www.emmerich-j.de/EDDF/Films/ope ... 161007.log

    My "impression" is: That happens when the sky is crowded with targets - and maybe one typed order to target 1 was not yet completed while already sending out the next order (or just do next mouse-click). As I said before: I believe there are some runtime-problems.

    Notice also that after restart I had to enlarge the radarsubwindow again.
    ** When will it be possible to also save the radar size (needed on Unix for displaying the Bay?
    ** If a customer has set Sqw and you use "Simulation Data Mode" then you will not see the Target-ID. I then used "RevSqw" to be able to see the Target-ID on the radar-screen -- that does not work any more.
    ** save/load of the layouts should work like standard. e.g. when saving ask for a name and when loading show list of the available *.xml(s). Now it is a problem if you need to redo your once defined settings again and again whenever you operate on a different airport or wanting different layouts for different events, etc.

*NiceToHaves
    ** The ORCam Positions are shown on the Radar like usual Targets - showing the position is nice - but please without the FlightTag! The Tags are very confusing if the airport is busy - you always try to find out what that target is and what it is supposed to do! (Yes, that is a problem (for me only?) if you are busy and just noticing a new target (after you used ORCam!) and now try to remember what that target is doing. (Yes - I know I am old etc. - but you try it when at the same time you give orders to another target on Mumble!). I help me right now by neglecting them and put them manually into my own "Neglect section!" - there should be somewhat automatically!
    ** With a DoubleMouseClick left/right the Flight-Stripes move only one step right/left. In a longer list that is very confusing because that stripe will then not just be moved 1 step left/right - but also resorted (vertically) in the list - so for a second "MoveClick" you first have to search for that target again (and hope you still remember what target you are working with and where it could be now!).
    ** Input-Fields in the Stripes should be locked if that target is not under Your control! Otherwise it happens (like stupid me) that you get into trouble with other ATC's!

In general that Bay works pretty good - after you spent at least 2 days in learning how to do it! I am still not sure that there will be many ATC's studying "How" in order to do their own things. The more important it is to define some "layout.xmls" that can be distributed and used by many ATCs.
Anyhow: Thanks for the work
jomo / ATCjomo + EDDFjo + EDDFjo1 + EDDFjo2
ATC at EDDF Fr,Sa,Su,We from 20:00 to 24:00 CET/MEZ., see http://www.emmerich-j.de
User avatar
jomo
 
Posts: 1000
Joined: Thu Feb 12, 2009 7:46 pm
Location: Mainz, Germany
Callsign: jomo EDDFjo1+2
OS: UBUNTU 18.4

Previous

Return to OpenRadar

Who is online

Users browsing this forum: No registered users and 3 guests