EuroScope v3.2.4

Support Controller Software
1

Hi,

I finally published a new release of EuroScope: v3.2.4.

This version contains lots of refactoring code. It might happen to be less bug free.
Please return in new topics if you find something that worked in prior version but not any more.
I also would like to as the plug-in developers to run a deeper than average test. The API is the same, but the underlying functions are modified.

Gergely.

4 Likes
2

Hi Gergely,

Thanks for the update! Can you clarify what the new shift change function does and how it works? Our own vACC plugin which runs fine on 3.2.3 causes ES to freeze in the new version, is there a list of plugin functions that have been modified so we can narrow down our testing?

3

Hello Gergely,

Thank you for the update and I love the idea behind the new shift change!
Do you think it would be possible to also swap the active controller to observer after the change has taken place? It would be very good if the outgoing controller could monitor the situation for a bit after he has been replaced to ensure that everything went smoothly.

4

If I understood the documentation correctly, this should be possible with the hot shift change scenario, where the leaving controller will select an observer call sign for his next login.

6

The problem is that the outgoing controller will loose the “active controller” screen

7

Federico,

There is no intentional change in the plug-in. But I tested different plug-ins and not all worked at once. Do you have a chance to debug it with the developer? Or I can also run a test in my environment if you send me the plug-in.

Gergely.

8

After reconnecting as observer you can just right click on the controller list and ask to see the screen as you were online:
image

1 Like
9

How difficult would it be to get a proper planner/coordinator position with this great step forward?

1 Like
10

What else exactly would this need in addition?

11

same level access to the same position by two different people, in a nutshell.
A planner/coordinator sees exactly the same, and can do exactly the same as the radar/executive controller. This goes for inputs, calls, system coordination, anything, I guess apart from PMs

1 Like
12

I think this will not be possible with the current system architecture (tracking can only be done by one client, coordinations are sent from one to another client) and would require significant changes to the code.

13

Thanks Gergely.
Oh, sorry, Jonas

14

So…updated to 3.2.4, completely broke ES. Nothing worked. Deleted and reinstalled 3.2.3 and still nothing works.
Can’t get anything other than a black screen at any airport.

15

What if they can see the exact same thing, but

  • Inputs by the planner are received as coordination requests by the executive (little change as this is a normal coordination request: external party to tracker of the flight)
  • (VCCS) Calls can be made client side, even as an OBS (no change)
  • System coordination is received by the planning controller, not executative*
  • …

*Basically, the coordination requests are received by the planner. And the planner can pass them to the exec by starting another coordination request, if needed (item 1).

When a coordination request is initiated EuroScope…:

  1. Uses the controller ID to get the position’s name

  2. Either, identifies an active planner for this position (This would need some uniformity in naming. E.g.: "_PLAN (if allowed))

  3. Or, the coordination is sent to the controller from step 1

E.g: A coordination request is initiated from EHAA_W_CTR for a certain flight tracked by EBBU_W_CTR. Before sending the requests, it checks if EBBU_W_PLAN is online. If so, sends it to that controller, if not, it gets sent to EBBU_W_CTR

16

It is already possible with the planner having one connection in parallell with the executive controller (with preferably a similar login callsign, observing to have lower priority than exec in priority, and priming the same frequency to be able to use AFV), and another instance which is connected as proxy to the executive controller via hamachi for example, which then is used as main instance, which makes both E and P see all the same coordinations, freq messages etc. Works well enough for me.

17

that’s an unauthorized and CoC breaking way of doing it, so a native solution would be welcome

18

I am the developer :sweat_smile: I’ve done a little more digging and it appears that the thread detaching has stopped working. I use std::thread::detach for much of the functionality of the plugin that needs to run asynchronously to prevent ES from freezing. I can send you the plugin if you’d like, let me know what you need and how you would like me to send it to you.

19

Oh that’s interesting. What part of it?

If you mean A8, I guess it could be argued both ways. There isn’t really a double connection in terms of one CID directly connected twice to the network. I find it hard to enforce/prohibit something that has no way of being traced by SUPs. Of course I could also understand that the opposite could be argued. Or maybe you are referring to another paragraph?

20

A3 is the problematic one for that use case.

21

That I can understand, would that not have to be updated/changed no matter how a planner functionality is used/implemented?

If a planner needs to forward approval requests to the exec and is not able to intervene directly on most issues, I see very little point in having a planner online to help. Maybe others see it otherwise.