The goal with the filter is to avoid on-ground clutter on radar scopes. The issue is that helicopters can easily go down to less than 50-40kts, and setting the filter to anything less than this starts introducing ground clutter again. So to avoid the helicopter to disappear, you need to clutter your scope which is unwanted.
At work, things on the airport are filtered out on ground, but targets beyond a mile or so are not no matter their height (though on-ground usually blocks even SSR and they disappear anyway, so an on-ground flag filter for ES would be +95% realistic in that way comparing it to my workplace).
AFAIK, the ground filter never worked the way itâs intended, or Iâm misunderstanding how it should work or be set up.
For example, all of these aircraft are just sitting at the gate, not moving, with their transponder on, yet theyâre all showing, despite the filter set to 50kts. For some reason, setting the altitude to 0 also removes everyone from my Departure list. Not sure why that is, and if itâs intended behaviour?
Changing the altitude back to my regular 1250 (highest AD elevation in my FIR is 1234ft AMSL), and I get the Departure list back, but theyâre still visible.
In order for the aircraft to actually be decluttered, I have to set a general filter to not display aircraft below a certain altitude, but then the problem is that I donât see ANYONE (except Assumed or On Contact traffic) below that altitude, regardless of how fast theyâre flying, which can be a problem to pick up low flying departures, arrivals or VFR flights, in my case anything below 1300ft.
I donât have a screenshot right now, but surrounding FIRs have airports that are higher than my filter of 1300ft, and any aircraft on the ground there will still show up as normal, creating one big blob of tags.
What is exactly the role of the %localappdata%\VirtualStore\Program Files (x86)\EuroScope folder? I see that files are created/duplicated where although they already exist in the %appdata%\EuroScope folder, namely:
ipaddr.txt
version.txt
euroscope_sector_providers.txt
SectorFileProviderDescriptor.txt
This is even more confusing as my actual installation folder is C:\Program Files (x86)\EuroScope 3.2a.
I also see that the playback logs are saved in %localappdata%\VirtualStore when the path there is set to c:. So somehow EuroScope treats/redirects c:\ to this VirtualStore folder. The same thing happens then for sector file provider.
The displayed path in the dialog shows C:\Program Files (x86)\EuroScope while they are actually saved into %localappdata%\VirtualStore\Program Files (x86)\EuroScope. This results in the well known âNeither SCT nor SCT2 file is found after extracting the 7zâ. My best guess is that the SCT2 file is attempted to be saved in the actual program files folder, where the application does not have write access and therefore cannot actually save the file there. All the other files from the zip are extracted in the VirtualStore folder.
Can we get clarity please on which files should be stored where? Is the use of this VirtualStore folder a thing nowadays (Iâve not seen any other applications using it), similar as to changing the data folder to the users appdata (Roaming) folder?
Then, there is no need for the altitude filtering in the display settings dialog.
It might not be obvious, so grouping this option together with the ground filter criteria in a future version could probably avoid these kind of issues.
Perhaps EuroScope could even use the âon groundâ flag from FSD data as the primary source for determining if an aircraft is on ground or not, and only use the altitude/GS values for clients not reporting the ground status?
While that does indeed work, it creates another issue, again because it is a catch-all option, as it will also override those aircraft that actually do have their transponder on, which is a problem when looking at our surface movement radar. (SMR)
If this would not be a general option, but one tied specifically to the ASRs, then yes, this would be a functional and great option, but as is, itâs not, unfortunately.
But how would you know if a client will report âon groundâ if he doesnât at a specific moment? I agree though that it could be an additional option offered in the settings to be recognized by the controller client.
Looks like you are using vSMR, correct? Itâs probably not designed to be used in a mode together with radar stations, or you are missing a specific plugin setting. Youâll need to clarify this with the plugin developer. We currently use GRP and this works without any issues in this regard.
Well, for every new aircraft the altitude/GS method would be used until the client started reporting the on ground flag, and from there on assume that the client keeps reporting it. Depending on whether the on ground flag can be trusted blindly, altitude/GS/other checks could still be run in the background to override the flag if necessary. It might be a good idea to ask pilot client developers about their experiences with the flag and how theyâve handled determining the âon groundâ state.
It can be maybe solved by adding a new kind of volume in the see file. So we can create a volume from 0 to airport alt + 50 around the airport. If the track is in the volume, with a speed below X kts, the track is on the ground. This way itâs completely controlled in EuroScope and it doesnât rely on some kind of flag from the pilot client.
It could be one solution, and having airport elevation data available would also enable more accurate vertical path calculation for high altitude airports, but unless the ground flag is unreliable, using it would be a simple and accurate solution without any manual work needed to create volumes and process all aircraft position packets against them.
Is 3.2.10 the big release possibly planned for Q4 or it will be a smaller release to address the 3.2.9 issues?
We are still debating wheter we should recommend 3.2.3 or 3.2.9 to our controllers. If 3.2.10 would be released before VATSIM drops the older clients, it would make our decision easier
Thereâs a bunch of Hungary related files that canât be deleted, otherwise it opens the installer instead. These are cluttering and taking up space unnecessarily and a user should be able to delete them if they so wish. Namely, Hungary, Scenario, Settings folders and Hungarian Matias.prf These are all files that will never be opened, unless I guess someone wants to control in Hungary.
I constantly have an issue where Iâm unable to write â:â in the command/chat window on proxy instances, also â:â and all the text after it gets removed if it is included in a text alias.
Very strange problem indeed⊠Anyone else had this?
I think this doesnât work in the primary instance neither. I remember that â:â is used as a kind of separator, which is why it cannot be used in messages and will be removed/replaced by applications before they send this to the network. This is also why you will see URLs in controller infos oder pilot remarks looking like this: âhttps //vatsim.netâ.
