Hello,
I’m testing the sweatbox simulator in the new version at the moment and I found the following bugs:
For departing or climbing traffic, the REQALT is used as RFL. This means that for example all traffic that has: REQALT:KONAN:29000 will have 29000 as RFL in the flightplan in stead of the RFL in the $FP line ($FPBAW720:*A:I:A319/L:446:EGLL:1915:1915:39000:LSZH:…) FL390 in this case. So this also means that all traffic that is programmed to depart from a controlled airport with an initial climb, let’s say 4000ft will have a RFL for the complete flight of 4000ft.
For instances connected via proxy, the active sectors are not active on the proxy instance so the sector states of the flights are not displayed. All traffic is displayed in unconcerned or assumed (if assumed on the main instance)
The AUTO Accept function doesn’t seems to function anymore.
In the end, it appears the issue was caused by Windows User Access Control. I’m not sure why the new ES version required a different user access initially, but it all works fine after a clean reinstall
Gergely, thanks for the great effort you put into EuroScope!
One observation i made: while testing i noticed that with this new version of EuroScope, if the DisplayTypeNeedRadarContent flag is set to 0, Display Settings like Features and Freetext will not be saved in the ASR anymore, instead it always reverts to a blank Screen. Is this intended behaviour? I was able to get the required behaviour by changing this Flag to 1 but that then caused new unwanted behaviour which required further workarounds, in order to hide Standard ES Tags and Targets ie. in the GroundRadar plugin ASRs. Ideally it would be possible to have the flag have the original behaviour (hiding default ES radar elements - tags and targets, while still saving Display Settings to the ASR) or alternatively having another flag that does this.
Another observation i made is that the scope becomes pretty much unusable in this version after a short amount of time (~20minutes). I get heavy lags in the approach view, whenever i scroll or pan. This issue does not exist in 3.2a(r33). I cannot tell in which version this starts as i didn’t test all of them, but it seems Euroscope struggles with lots of features being displayed. If i switch to the ground view for a random airport, the lags are gone until i switch back to approach view.
edit: I was able to mitigate the Lag by Disabling certain point-rich features such as the country borders and lake contours. however this doesn’t seem to be a practical solution as parts of those features (namely country borders) can not be simply omitted in the sector file.
Thanks Gergely for the update! I’ve not tested in detail yet, but found some difference to previous versions.
Some minor observations for connecting dialog:
Spelling issue for all new shiftchange button “chnage” >> “change”
Proposed log file location is now “C:\EuroScope[date].txt”, before there was only one back slash. Not sure if this is relevant. On my computer, the are not stored at the proposed location, but in %localappdata%\VirtualStore. Is this intended? And could this kind of disagreement between the displayed and the actual location be changed?
The version displayed in the windows application list is “3.2.5”, when it probably should be 3.2.4.
I receive an error message “unknown issue” if I want to close ES and the loaded ASR has some entries listed which can no longer be found in the current SCT file (this can easily happen after the SCT is updated). Although the entries are displayed to be removed, this will not happen after you confirm to do so. Instead an error message is displayed and ES will abort the shutdown. If I save the ASR manually before I close ES, then there is no problem. The similar dialogs raised for changes setting files seem not to create any issue.
I see that the ATIS maker URL and VCCS mini control position is stored in the prf file. Is there a specific reason why these are not in a settings file?
Another report. The EOBT item is creating weird outputs when connected as an observer. Many times are shown a value like “0000”, “2000”, “3000” or “4000”, which does not correspond in any way with the value provided in the flight plan.
Some additional thoughts on these two settings.
Regarding the TeamSpeakVccs items: These are currently saved to the prf file, different than any other position data. Where a specific setting category exists, the position and visibility flag is saved in the corresponding category. Otherwise, the screen setting file is used. My proposal would be to move all the X/Y and visibility flag items to the screen setting category, thus allowing to separate computer-specific parameters (positions are dependend on screen size, so might be the visibility) and the list item/functions. The latter might be updated now and then by sector file providers, while screen paramters and list/positions and visibility is specific for each instance/computer. So separating them in different setting categories would make it easier to merge “global” and “local” setting parameters.
About the ATIS maker URL: the parameter m_VoiceAtisBuilderUrl is probably no longer used as far I was able to evaluate. I’m not sure which file is the best place to save the ATIS URLs. But I would remove those settings which are no longer used.
And can we get finally an Developer library updated? Drawing HDG tool, access to messages (i.e. sending it via plugin, as I suggested somewhere in the email), VCCS config/API (so we can rewrite the buggy VCCS panel by ourselves), more mouse/keyboard hooks/keystrokes accessibility, access to VATSIM Velocity datapackage (so SRA/PAR radars plugin can get updates as it should be, i.e. 2-3 times/sec), not to mention that developers have to do pretty long workarounds in certain things (as we do not have an access to message loop). I understand the need and willingness to have other versions of the plugins compatible, but mostly it’s just about to recompile them.
Regarding current version:
ES is getting strongly lagging in this version, making it unusable.
In the new version there are some preparations that makes it possible to extend the API. But I would like to make it stable first, then extend the API.
The LAG-ing is reported by many of you. Does anyone have a chance to provide me a LOG or a scenario file that causes ES to LAG. I need something like that for debugging and profiling.
Is it normal that it logs easily 2 dozen entries per a second? I was only online as observer, the reaction times for scrolling and panning kept rising during the recording. I couldn’t try working the tags due OBS, but the rest of the behaviour is the exact same.
I will keep it running for another while, so if you need even more logfile, let me know.
Seems i cannot upload textfiles here, so: Duttcloud ← thats the log file (~3.5MB)
Thank you. I downloaded it, but no LAG so far.
Do you happen to have the problem while you are playing it back?
Can you send me your setup (SCT/ESE/ASR)?
Do you have any plug-in loaded?
The several dozen entries per second is not a big thing. At the very beginning you must have far more.
Yes, but it doesn’t depend on that. I have the problem, even if i remain unconnected and just move the screen around (Pan and Zoom). It starts out with a slight lag and get’s worse over time.
This is with the sectorfile from LSAS · vACC Switzerland AIRAC Downloads - i can make you a Private Message with the requested files in, but it will look pretty damaged without the plugins.
Yes, but i unloaded them all to test, and the issue persisted.
As stated above, i was able to mitigate the issue when disabling the country borders and water features in the Display settings (Geo). So to me, it seems to have to do with those point-rich features, as the two mentioned features have lots of points defining the country and water-body borders. As soon as i disable those, even leaving all the other Display features enabled, the Lag is gone.
I will send you a private message with a link to the pure SCT/ESE/ASR - i was able to reproduce the issue in the APP.asr, but i think it’s also with CTR.
I (and others as well) also experience crashes with our setup. For me, it usually starts lagging and eventually crashes. I found that there is a crash dump available for one of these (I was controlling with my main instance on 3.2.3, the crashing instance was the proxy on version 3.2.4 - took the wrong shortcut when starting the proxy, but this really also happens when having both instances on the same version).
