Jump to content

Jonas Kuster

Supervisors
  • Content Count

    340
  • Joined

  • Last visited

  • Days Won

    2

Jonas Kuster last won the day on June 5

Jonas Kuster had the most liked content!

Community Reputation

10 Good

About Jonas Kuster

  • Birthday 07/06/1989

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Well, that's the same as right click in the COPX list. But I would like to have an option to correctly identify the waypoints where coordination is needed and where it is not.
  2. I'm aware, thanks. I need to assume this has been broken at some time during development. Because otherwise there wouldn't be a reason for an option "Allow direct beyond COPX point". This at least to me suggests that otherwise direct up to the COPX are allowed.
  3. I'm not 100% sure about my issue, but wanted to bring this for discussion with other members having knowledge about ES plugin coding, so you may verify my observations. When using the OpenPopupEdit function while coding a plugin, the FunctionId given is called twice afterwards. I tried debugging, but couldn't find the reason/source for the double call. It seems the OnFunctionCall catches the id twice and therefore executes also the statements twice then. I'm changing the flight plan and calling the flight plan amend function afterwards. May this lead to OnFunctionCall juming into again?
  4. I was looking into implementing MSAW areas. However, I had to realise that such areas do interfere with aircraft on approach, as they usually descend below the MSAW. Instead of cutting holes into MSAW areas (where flights not on an approach are still subject to MSAW alerts), I would propose that the warning logic to be adapted to suppress MSAW warnings whenever an aircraft has a CFL 1 or 2, which corresponds to APP or VAPP. Has anyone experience with MSAW areas? Would you support my idea?
  5. I might be missing something quite essential, but I remember times when there were possibilities to define a COPX beyond the own sector boundary and I was able to provide a direct to any flight up to this point. Now this point, despite the intended COPX rule is captured, is marked already to be subject to coordination (marked with the ID of the next sectors controller). I would expect this point (as it is the agreed COPX) NOT to be subject to coordination as proposed by ES. Am I wrong? How do you manage to implement COPX outside of the transferring sector? PS: I'm aware of the option
  6. This is not related to ES, but a known and repeated issue from the AFV server. If you experience such cases, advise in the appropriate channels. Most effectively might be through the #software-support channel on Discord.
  7. There seems to be no function implemented to change these settings via a plugin.
  8. Hello Gergely Would it be possible to offer a differentation for the plugin library to identify whether entries from the SIDSTARS section are actually SIDs or STARs, similar to options already existing for airports and runways? My proposal would be to made this available through the already existing function IsElementActive, where the bool Departure could be used (SID=true, STAR=false). Kind regards Jonas
  9. Hello Gergely I've had reported a number of cases where the route drawing was not following according the flight plan. I was able to identify the issue related to specific waypoints in these routes, that exist multiple times (same navaid name at different locations around the world). The relevant files here are obviously the isec and the airway data file. Using the search function, I can observe that from waypoints used multiple times, only the first one will be known to ES. Now for the route drawing, it seems that not only the airway data file is used (which has both airway and waypoint
  10. Exactly where you are looking for. But remember this specific one is a function, not an item. So you will find it only in the left /right button lists.
  11. Thanks Olli! There should actually be a pull request waiting for your repo where I've already proposed such a change.
  12. Ryan, I think you need to be more specific. I see the ground layout and the lists, and the inset window. So, what is wrong exactly? Or what would you expect differently?
  13. It is with great pleasure that I can officially announce the plugin CCAMS to the community and the users of EuroScope. As you are probably aware, the management of squawks in general, and particularly of code 1000, is implemented in EuroScope on a local level only. There is no exchange/verficiation of used squawk further than your visibility range. In addition, the handling of squawk 1000 depends on the legacy FAA flight plan format, which does not contain accurate information about the transponder type. Already a few years ago, @Pierre Ferran presented his plugin ModeS, which was later o
  14. https://www.euroscope.hu/documents/EuroScopePlugInDevelopment.doc
  15. And there is no limitation in using a 5 for the 3rd decimal from the FSD protocol?
×
×
  • Create New...