Jump to content

You're browsing the 2004-2023 VATSIM Forums archive. All content is preserved in a read-only fashion.
For the latest forum posts, please visit https://forum.vatsim.net.

Need to find something? Use the Google search below.

ES v3.0a bug(s)


Radomir Vencek 947557
 Share

Recommended Posts

Radomir Vencek 947557
Posted
Posted

Hello Gergely,

first of all - really Great Job! Congratulations!

 

Unfortunately from time to time one finds some issues Here is one:

This bug is there from the beginning and I thought it will be identified and fixed in version 3.0. Because it was still there I tried to identify source of the problem and fouond it. So:

 

The bug is: If I load different 'all settings' file or make any similar configuration change:

- all aircrafts move from their correct position to one point (from e.g. 14.35/50.10 to 14/50) - all positions decimal parts are lost

- I lose all decimal parts of frequencies configured in my possitions list

- it damages also some other values in the configuration file

- and there will be probably other issues related to configurations related to non-integer numbers

And at this point it's completely impossible to control the traffic (only switch to procedural ) I must restart the ES to make it woirking again - till next configuration change. I must protect the configuration file by 'read-only' flag to avoid permanent fixing the file.

Reason:

- I'm using Czech windows with Czech national settings. It means local number formatitng, date/time formatting, currency... The important here is the number format where the comma is used in number formatting of decimal numbers (while English verions use dot here). The result is that your software when calling system format functions get result with comma separated decimal part where only the integer part of the number is used. The result are then the symptoms described above. E.g. in the configuration file I found for LKPR_TWR position value 118,000 instead of 118.100.

When I change this number formatting character to dot, the program behaviour is correct.

Conclusion: local/national number formatting should not impact internal ES number formatting.

 

Can you take a look at it, please?

 

Rada

Link to comment
Share on other sites

Todor Atanasov 878664
Posted
Posted

My settings is comma too and I don't that problem. It may be something different. Gergely will say.

Link to comment
Share on other sites

Gergely Csernak
Posted
Posted

Radomir,

 

I myself use Hungarian settings where the decimal symbol is ',' and not '.'. EuroScope writes and loads all numbers using '.'-s and never ','-s. As Todor I have never had similar issue. Can you confirm that all workd just fine until you change something in the settings. And only from that second EuroScope forgets to interpret all '.' as decimal symbol. Is that correct?

Gergely.

EuroScope developer

Link to comment
Share on other sites

Radomir Vencek 947557
Posted
Posted

Hi Gergely,

 

hmmm, it's strange... anyway - when I switched from comma to dot the problem has been resolved and I have no problem since this time.

 

This is example of the 'all settings' cfg. file:

- correct

AG:LKMT_TWR:120.800:194.213.194.20:LKMT_TWR

AG:LKMT_APP:125.100:194.213.194.20:LKMT_APP

AG:LKKV_APP:119.950:194.213.194.20:LKKV_APP

AG:LKKV_TWR:121.220:194.213.194.20:LKKV_TWR

- after save I find following damaged data stored:

AG:LKMT_TWR:120,000:194.213.194.20:LKMT_TWR

AG:LKMT_APP:125,000:194.213.194.20:LKMT_APP

AG:LKKV_APP:119,000:194.213.194.20:LKKV_APP

AG:LKKV_TWR:121,000:194.213.194.20:LKKV_TWR

The same way are damaged all other floating point settings:

Airports:symbol:8421504:1.0:0:0 vs. Airports:symbol:8421504:1,0:0:0

etc.

 

Main issue - moving all aircrafts to rounded position

- correct positions:

img-ok.jpg

- after configuration reload:

img-bad.jpg

(see the dots remaining after previous FDX position)

 

Rada

Link to comment
Share on other sites

Gergely Csernak
Posted
Posted

Rada,

 

Thanks for the update. At least we have a work around about this issue. Even I still have no idea why the standard functions work differently there.

Gergely.

EuroScope developer

Link to comment
Share on other sites

Todor Atanasov 878664
Posted
Posted

Gergely as ES work with .NET, the problem may be in it. Radomir try to download .NET again, fresh new copy, not update.

Link to comment
Share on other sites

Gergely Csernak
Posted
Posted

Todor,

 

Negative. ES does not use .NET at all. It is based on MFC and Windows API, nothing else. Only the installer is built with VisualStudio and it needs .NET framework.

Gergely.

EuroScope developer

Link to comment
Share on other sites

Todor Atanasov 878664
Posted
Posted
Link to comment
Share on other sites

  • 4 weeks later...
Stephen Odgaard
Posted
Posted

Gergely,

 

Heres one for you.

When performing playback with a slave session connected to the "master", the slave still shows the current time, and not the playback time.

 

Regards

 

Stephen

BR

Stephen Slot Odgaard
VATSCA C3 Member since 2004

P3D v 5: Jeehell A320, Skalarki...
MSFS w FlyByWire A320 mod, VR Reverb G2

Link to comment
Share on other sites

Gergely Csernak
Posted
Posted

Stephen,

 

Right. The time information is not propagated via the proxy connection. Actually the second client have no idea at all if it is a real session or a playback. To be honest there are other places too where the playback time is not used correctly. E.g. the estimated time over a point or over a COPX always uses the actual time, not the simulated one.

 

I will take a look if it is possible to propagate the time with a reasonable code.

Gergely.

EuroScope developer

Link to comment
Share on other sites

 Share