MW4 stops after 3 images

[InFINNity-Deck]

Hi Michel,

just tested the latest version. I use a 57 point model, but each time when I start it it stops after 3 images and 4 slews. The image viewer shows image-0002.fits.

I have uploaded the log file, there may be multiple starts in it.

kind regards, Nicolàs

mw4-2020-05-30.log

[InFINNity-Deck]

I forgot to close MW4 before sending the log file, here is the complete one:

mw4-2020-05-30.log

[mworion]

Hi Nicolas,

For some reasons, the dome did not connect. I added robustness feature against unconnected ASCOM devices, but this would not change the fact. I will do a message, that is is a connection missing.

Did you experience that the mount status button in the main window was red ?

Michel

Am 30.05.2020 um 23:48 schrieb InFINNity-Deck notifications@github.com:

I forgot to close MW4 before sending the log file, here is the complete one:

mw4-2020-05-30.log https://github.com/mworion/MountWizzard4/files/4706605/mw4-2020-05-30.log — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mworion/MountWizzard4/issues/40#issuecomment-636389579, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSTMFGFFQ6QKOB3EIEMZ33RUF5MTANCNFSM4NO3VSTQ.

[InFINNity-Deck]

Hi Michel,

I have noticed that at start-up MW4 rarely automatically detects the dome. Most times I have to go to settinges->devices and re-connect by going into the ASCOM set-up and press OK again. With SGP I never lost connection with the dome, so it does work reliable.

There were no red buttons when it stopped. I ran the model again just now and noticed that it stops because MW4 thinks that the dome is still slewing, see attached screen dump (I also added the log, as you will see the first run it had not found the dome, so I needed to reconnect and restart).

Nicolàs

mw4-2020-05-31.log

[mworion]

Hi Nicolas,

I put a retry for ASCOM connection in for next beta. Now I'm recalling why I didn't want to go back to ASCOM. But anyway ASCOM is back in and I have to deal with it.

But this said, I addressed the startup. What you are saying, that the ASCOM connection is lost during model run right? I currently see no exception for this. The missing connect at the beginning is in the log.

I put some more logging in, If you don't mind, you could give it a try: v0.150.25b1

[InFINNity-Deck]

Hi Michel,

the updater does not find the new version, "Requirement already satisfied, skipping upgrade: " it says for all items. Sadly enough there is no native driver for LesveDomeNet...

Nicolàs

Op 31-5-2020 om 16:38 schreef Michael:

Hi Nicolas,

I put a retry for ASCOM connection in for next beta. Now I'm recalling why I didn't want to go back to ASCOM. But anyway ASCOM is back in and I have to deal with it.

But this said, I addressed the startup. What you are saying, that the ASCOM connection is lost during model run right? I currently see no exception for this. The missing connect at the beginning is in the log.

I put some more logging in, If you don't mind, you could give it a try: v0.150.25b1

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mworion/MountWizzard4/issues/40#issuecomment-636479983, or unsubscribe https://github.com/notifications/unsubscribe-auth/APY5XLM3VHTVQLD7YWCMZ2LRUJTXLANCNFSM4NO3VSTQ.

-- Deze e-mail is gecontroleerd op virussen door AVG. http://www.avg.com

[mworion]

Nicolas, If I upload beta version, the PyPi platform might take longer get it into effect if they have load problems (at least that was my understanding). Version should be now available. Michel

[InFINNity-Deck]

Just an update for visitors: Michel and I have been in contact extensively in the past week by direct e-mail and he has made several huge improvements (thank you for that, Michel!). The ASCOM connection has much improved, a lateral offset has been added for side-by-side set-ups, and MW4 now finishes its runs correctly. Michel and I are now writing and testing an improved version of the underlying maths for the dome-azimuth calculations.

[InFINNity-Deck]

Hi Michel,

could you please confirm you received my e-mail of 4 June with the dome-control algorithms?

Nicolàs

[mworion]

Hi Nicolas,

yes, I received it. I'm currently in the time I have on cleaning up things before moving to the dome issue. Too much open point which I'm closing now. Does it make sense to continue on the dome part in issue #46 ?

I had a quick look into. The routine I did for the dome is straight forward 3D geometry and regular transformations. That's easy. Difficulties are like you said: pier side, signs, references for measurement.

If you feel comfortable with stability, we could close that point. BTW. as tests numbers are increasing I have to optimize it on GitHub actions as the run now for 15 min. And I would like to add full applications test as well. Especially for the usage of ASCOM.

Michel

[InFINNity-Deck]

Hi Michel,

I think issue #46 is not really an issue, but a nice-to-have implementation.

Implementing the algorithms I provided day before yesterday are of greater importance as they solve the general pointing accuracy of the dome azimuth, especially at low altitudes and correct dome radii. The tests I did using my algorithms always resulted in almost exact dome behaviour (i.e. within the slewing accuracy of the LesveDomeNet controller) and even at sub 1 degree altitude points (that is where the current MW4 algorithm produces erratic azimuths up to 180° in the wrong direction).

I tested my own algorithm by slewing the mount using the mount's Goto Alt/Azi option and slewing the dome using SGP's Dome Goto option (using the dome azimuths calculated by my algorithm).

With MW4 I just did another test with four cardinal points at 1° altitude. MW4 was set-up with correct offsets to the base of the mount (0.01m east, 0.00m north, 0.08m up) and correct radius of the dome (1.50m):

Target Altitude [°] | Target Azimuth [°] | MW4 dome azimuth [°] | dome azimuth according to my algorithm [°] 1 | 0 | 27.40 | 17.12 1 | 90 | 114.20 | 100.92 1 | 180 | 149.70 | 161.50 1 | 270 | 251.80 | 266.46

The MW4 azimuths were taken from the MW4 log file. As you can see slewing errors up to 15 degrees occur. In practise this means that the telescope is pointing at and against the side of the slit (left side for north and east targets, west side for south and west). Only when entering a radius of 3m I get a workable solution, but even then the dome's azimuth is clearly incorrectly calculated.

Although MW-users will hardly ever create models with points this low, they may wish to be able to steer the dome in that direction for other purposes (azimuth verifications, start of satellite tracking, etc). Besides, it looks much better if dome-control is correct. ;-)

I am currently preparing a publication on the algorithms I sent you, will send you a sneak-preview outside this platform once ready (today or tomorrow).

Nicolàs

[mworion]

Hi Nicolas,

That’s great to her. What I would like to do to compare it with my implementation. This is my next step to learn, where I made some faults.

If you don’t mind, I attached the geometry calc in python (but it’s really good described and it’s mostly vector math. If you see some mistakes, please let me know.

Thanks for the help.

Michel

Am 06.06.2020 um 16:07 schrieb InFINNity-Deck notifications@github.com:

Hi Michel,

I think issue #46 https://github.com/mworion/MountWizzard4/issues/46 is not really an issue, but a nice-to-have implementation.

Implementing the algorithms I provided day before yesterday are of greater importance as they solve the general pointing accuracy of the dome azimuth, especially at low altitudes and correct dome radii. The tests I did using my algorithms always resulted in almost exact dome behaviour (i.e. within the slewing accuracy of the LesveDomeNet controller) and even at sub 1 degree altitude points (that is where the current MW4 algorithm produces erratic azimuths up to 180° in the wrong direction).

I tested my own algorithm by slewing the mount using the Goto Alt/Azi option and slewing the dome using SGP's Dome Goto option (using the dome azimuths calculated by my algorithm).

With MW4 I just did another test with four cardinal points at 1° altitude. MW4 was set-up with correct offsets to the base of the mount (0.01m east, 0.00m north, 0.08m up) and correct radius of the dome (1.50m):

Target Altitude [°] | Target Azimuth [°] | MW4 dome azimuth [°] | dome azimuth according to my algorithm [°] 1 | 0 | 27.40 | 17.12 1 | 90 | 114.20 | 100.92 1 | 180 | 149.70 | 161.50 1 | 270 | 251.80 | 266.46

The MW4 azimuths were taken from the MW4 log file. As you can see slewing errors up to 15 degrees occur. In practise this means that the telescope is pointing at and against the side of the slit (left side for north and east targets, west side for south and west). Only when entering a radius of 3m I get a workable solution, but even then the dome's azimuth is clearly incorrectly calculated.

Although MW-users will hardly ever create models with points this low, they may wish to be able to steer the dome in that direction for other purposes (azimuth verifications, start of satellite tracking, etc). Besides, it looks much better if dome-control is correct. ;-)

I am currently preparing a publication on the algorithms I sent you, will send you a sneak-preview outside this platform once ready (today or tomorrow).

Nicolàs

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mworion/MountWizzard4/issues/40#issuecomment-640066560, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSTMFAK6OFLVA7XUTWQUWDRVJETJANCNFSM4NO3VSTQ.

[InFINNity-Deck]

Hi Michel,

no problem to check your code, but the attachment is missing...

Nicolàs

Op 6-6-2020 om 16:46 schreef Michael:

Hi Nicolas,

That’s great to her. What I would like to do to compare it with my implementation. This is my next step to learn, where I made some faults.

If you don’t mind, I attached the geometry calc in python (but it’s really good described and it’s mostly vector math. If you see some mistakes, please let me know.

Thanks for the help.

Michel

Am 06.06.2020 um 16:07 schrieb InFINNity-Deck notifications@github.com:

Hi Michel,

I think issue #46 https://github.com/mworion/MountWizzard4/issues/46 is not really an issue, but a nice-to-have implementation.

Implementing the algorithms I provided day before yesterday are of greater importance as they solve the general pointing accuracy of the dome azimuth, especially at low altitudes and correct dome radii. The tests I did using my algorithms always resulted in almost exact dome behaviour (i.e. within the slewing accuracy of the LesveDomeNet controller) and even at sub 1 degree altitude points (that is where the current MW4 algorithm produces erratic azimuths up to 180° in the wrong direction).

I tested my own algorithm by slewing the mount using the Goto Alt/Azi option and slewing the dome using SGP's Dome Goto option (using the dome azimuths calculated by my algorithm).

With MW4 I just did another test with four cardinal points at 1° altitude. MW4 was set-up with correct offsets to the base of the mount (0.01m east, 0.00m north, 0.08m up) and correct radius of the dome (1.50m):

Target Altitude [°] | Target Azimuth [°] | MW4 dome azimuth [°] | dome azimuth according to my algorithm [°] 1 | 0 | 27.40 | 17.12 1 | 90 | 114.20 | 100.92 1 | 180 | 149.70 | 161.50 1 | 270 | 251.80 | 266.46

The MW4 azimuths were taken from the MW4 log file. As you can see slewing errors up to 15 degrees occur. In practise this means that the telescope is pointing at and against the side of the slit (left side for north and east targets, west side for south and west). Only when entering a radius of 3m I get a workable solution, but even then the dome's azimuth is clearly incorrectly calculated.

Although MW-users will hardly ever create models with points this low, they may wish to be able to steer the dome in that direction for other purposes (azimuth verifications, start of satellite tracking, etc). Besides, it looks much better if dome-control is correct. ;-)

I am currently preparing a publication on the algorithms I sent you, will send you a sneak-preview outside this platform once ready (today or tomorrow).

Nicolàs

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mworion/MountWizzard4/issues/40#issuecomment-640066560, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSTMFAK6OFLVA7XUTWQUWDRVJETJANCNFSM4NO3VSTQ.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mworion/MountWizzard4/issues/40#issuecomment-640072240, or unsubscribe https://github.com/notifications/unsubscribe-auth/APY5XLJ7FKZP45ZP7HVO6WDRVJJCZANCNFSM4NO3VSTQ.

-- Deze e-mail is gecontroleerd op virussen door AVG. http://www.avg.com

[InFINNity-Deck]

Hi Michel,

thanks for the attachments. I have sent a new version of my algorithm that follows the MW4 Cartesian coordinates convention.

Nicolàs

[InFINNity-Deck]

Hi Michel,

I found one major factor that causes the up to 15 degrees slew errors: it is the GEM-offset, see attached image of the original screen:

In packages like SGP the offsets have to be entered from the dome's centre and from the mount's centre of rotation. Earlier I made the mistake by doing the same for MW when it comes to providing the offset from dome to mount (I gave then to the RA/DEC axis intersection as I did in SGP, whereas I should have provided them to the mount's base as the rest is calculated by MW based on the connected mount). Reading your Python code I found this offGemPlate variable that was set to 0.233m for the GM3000. So instead of entering 0.42m for my actual GEM-offset I now entered (0.42 - 0.23) = 0.19m GEM-offset and now it is bang-on in the centre of the slit at the four cardinal points at 1 degree altitude.

What still goes wrong is using sub 1 degree altitude points. In those cases the rear intersection point is calculated (the one at the camera side) instead of the forward one (the one at the objective side).

Nicolàs

[mworion]

Nicolas, thanks for this observation. Now we should (and please a proposal from your side as I'm too much into my code) define, what a user normally (without any special explanation) would use and set as geometry parameters. I will adjust my code accordingly. Michel

[mworion]

The last observation is easy to explain: I choose the point which hits the sphere at the highest level. If the mount looks down, It's the rear end. I have to change that.

[InFINNity-Deck]

Ok, but if I use points at 0.05 degrees altitude it goes wrong as well.

Another thing is that I did above test with version 25b6. I just upgraded to 26b7 and pointing is off again. I tried it with both a positive and a negative LAT-offset, but that made no difference. So what did you change between 25b6 and 25b7?

Nicolàs

[InFINNity-Deck]

Nicolas, thanks for this observation. Now we should (and please a proposal from your side as I'm too much into my code) define, what a user normally (without any special explanation) would use and set as geometry parameters. I will adjust my code accordingly. Michel

Well, it does not matter too much as long as it is clear from the image on the set-up page. If the values you have predefined in the software are correct for all 10Micron models, then the GEM-offset could be changed into "Additional GEM-offset" with the image next to it modified to clearly indicate where that offset resides. I fear, however, that that still may be confusing, so perhaps it is better to let the user provide the actual GEM-offset, as that is a known figure to every GEM-owner. You could then use your predefined offset to check if the entered value makes any sense (the actual GEM-offset should after all be at least a few centimetres larger than the figure you hardcoded). On the other hand, if you wish to be in line with other software packages, I would remove all the predefined offsets and let the user supply the offsets to point A and the actual GEM-offset A-B.

Of course this means that you will have to kill one of your darlings... :-(

Nicolàs

PS: Once you decided, I will provide an updated image :-)

[mworion]

I definitively would like to in line with the known packages. That was the reason internally calculating with this difference, but offering only the A-B measurement to the user. I wonder why you had to calculate the difference yourself as MW4 only asks for full GEM delta. So there is more to correct on my side. The values to be entered have to be 0.42m.

[InFINNity-Deck]

Ok, I tested 0.42m with version 26b7, but it is way off again....

Nicolàs

[mworion]

Still working on that issue. There were hardly any changes. But still there has to be a mismatch in there. Right now I try to get with your excel (thanks for that) some points.

One question: how is your definition of azimuth counting in the dome? It seems that I calculate the angle clockwise, so 90 degree is dome slit = azimuth in east.

Michel

[mworion]

Another point to your observation having an angle 0.05 in altitude and getting the wrong direction: that might be due to the refraction correction in the mount. When I switch it on / off the apparent coordinates lead to a lower / higher point. I will change the azimuth solution selection to a comparison which of the solutions is closer to the azimuth of the mount. This will be correct in all conditions.

Michel

[InFINNity-Deck]

One question: how is your definition of azimuth counting in the dome? It seems that I calculate the angle clockwise, so 90 degree is dome slit = azimuth in east. That is correct: north = 0°, east = 90°, etc., so clockwise from north.

Nicolàs

[mworion]

Nicolas,

First I made a mistake in shifting arctan in the right quadrant before extending it from -pi..pi to 0 ..2pi.

Second question in your excel chart: when looking north (first point in excel) and having pier side east, than the Ota is on the left (west side) of the mount looking east (per definition). If so, the resulting azimuth of the dome has to be(due the the geometry) on the upmost north east side, meaning that azimuth would be about 350 degrees or so. Does this make sense for you ?

Michel

[InFINNity-Deck]

At the first point (alt/azi 0°/0°) my Ota is hanging on the east side of the pier and by that is the lowest telescope in the array. The resulting azimuth in my sheet is thus correct, but I did not check whether the mount calls this east or west (east was a tricky assumption), I need to check that (will do so in a moment).

Nicolàs

[InFINNity-Deck]

hmmm, it is called West for the first point..., so I will have to adapt my algorithm for that.

Nicolàs

[InFINNity-Deck]

Ran some more tests using 25b7 (25b8 is available, but does not yet install): north & east: mount reports pierside = west south & west: mount reports pierside = east

GEM-offset still needs correction, so (0.42-0.23)=0.19m results in good azimuths LAT-offset is positive for my set-up (azimuths are not spot-on when inverting the sign)

Nicolàs

[mworion]

Nicolas, coming closer. I will release a next beta for better testing soon. The choice of which solution to take is quite simple: it the on, the Ota looks to. As I have vectors, no issues with that. I Meade all corrections according to our results so far to get this new baseline.

GEM I checked. To the LAT definition: if the mount is pointing north if the OTA used for modeling is on the east from the center it's negativ, if it's west from the center it's positive.

My guess is that you are doing modeling with the refactor sitting beside the meade (not on top!), it would be east of center an than negative.

Michel

[mworion]

Uploaded 0.150.25b9

[InFINNity-Deck]

Ok, just installed and tested it:

• GEM offset still needs correction for the built-in value of 0.233m;
• LAT-offset does not work at all;

I tried a LAT-offset of +0.15m, -0.50m and +0.50m, so the latter two should make a difference of 1m perpendicular to the equatorial plane when slewing east, which is 70cm in the horizontal plane. With all settings the dome arrived at exactly the same spot.

The GEM offset of 19cm works, but should of course be 0.42m.

Data from the log-file:

Delta's with GEM-offset @ 0.42m, LAT offset @ +0.15m: north: -28.0°, so azimuth 28.0° (should be 18.34°)

Delta's with GEM-offset @ 0.19m, LAT offset @ +0.15m: north: -18.0°, so azimuth 18.0° (should be 18.34°, so pretty close) east: -10.7°, so azimuth 100.7° (should be 93.50°)

Delta's with GEM-offset @ 0.19m, LAT offset @ +0.50m: north: -18.0°, so azimuth 18.0° (should be 22.04°) east: -10.7°, so azimuth 100.7° (should be 82.09°)

Delta's with GEM-offset @ 0.19m, LAT offset @ -0.50m: north: -18.0°, so azimuth 18.0° (should be 16.66°) east: -10.7°, so azimuth 100.7° (should be 108.77°)

As you can see LAT-offset does nothing, I think you are rotating/translating into the wrong direction, so that the LAT-offset is displaced along the optical axis of the telescope. In my algorithm I calculate the perpendicular vector (by taking the cross product) of the vector towards the celestial object and the vector towards the GEM-offset.

Nicolàs

[mworion]

I found a silly fault. As I added the lateral translation, I increased the vector numbers for all calculations afterwards except one. So all calculations were without LAT.

I made a quick bug fix. Hopefully it does the trick. If not I need a pause to reflect, what I'm doing and how.

I left the 3D window in the beta 0.150.25b10. There you could see nicely, when you change geometry, how it behaves. You could open the 3d test window with the button under settings / mount

Michel

[InFINNity-Deck]

Hi Michel,

I just downloaded it, will test this evening. I started the 3D window while the mount is parked and it looks like this:

That top view does not seem right, is it? When parked the RA axis should be pointing north-south, but it looks like south-east - north-west. Also the LAT-offset should point east, but it is at an angle as well. Only the last line (the optical axis) seems correct.

Nicolàs

PS: I always park with the mount pointing direction Polaris. The 3D window looks the same when I unpark it.

[InFINNity-Deck]

Hi Michel,

good en less good news...

• Good news: it is spot-on! I tested it with 4 cardinal points @ 1degree altitude and 8 points @ 45 degrees altitude, 4 of which were cardinal points again, the other four in between, so at 45, 135, 225, and 315 degrees azimuth.
• Less good news: I still need to supply the GEM-offset corrected for the 0.233m mount geometry, so I have been running this test with 0.19m 'GEM-offset' (better to call it "Additional GEM-offset").

I can also confirm that the LAT-offset works fine now and that entering a positive figure for it in the GUI, produces the offset that is shown in the InFINNity Deck image. I have tested it with positive and negative values and it clearly makes a difference between correct and incorrect dome-azimuths.

The 3D window behaved very well when I restarted again this evening, but after parking it looked odd again. During the tests it behaved very well.

So now the only thing left for you to decide in this respect is what to do with the GEM-offset:

• leave it how it is now and modify the image to show what should be entered (and call that entry on the dome-TAB "Additional GEM-offset");
• leave the image how it is and modify MW4 not to use the preset GEM-offset.

The former makes MW4 very consistent, as all the mount's dimensions come from the program, which is easy to explain, but it should be very clearly stated that it is not a GEM-offset, but an addition to it. The latter is less confusing, but means we need to test again, but that is no problem.

I have no preference.

Nicolàs

[mworion]

Hi Nicolas,

First of all many thanks for all your work and help. I did an update for the 3d window (I could make a quick release of it. And I tried to reproduce it with my mount. Something looks different. You also could resize the window and could change the views with the mouse in the grid. If you do too much, there might be a hang. I didn’t want to put too much work into the rendering. v0.150.25b12

I made a video, where you can see the change of the settings and the behavior of the mount. Actually it is in park position, which is pointing to Polaris, too.

https://www.dropbox.com/s/ikyn1dzr471bc7l/Bildschirmvideo%20aufnehmen%202020-06-07%20um%2021.34.07.mov?dl=0 https://www.dropbox.com/s/ikyn1dzr471bc7l/Bildschirmvideo%20aufnehmen%202020-06-07%20um%2021.34.07.mov?dl=0

If you like, I’ll do the beta now, but continue to work tomorrow.

Michel

Am 07.06.2020 um 21:01 schrieb InFINNity-Deck notifications@github.com:

Hi Michel,

good en less good news...

Good news: it is spot-on! I tested it with 4 cardinal points @ 1degree altitude and 8 points @ 45 degrees altitude, 4 of which were cardinal points again, the other four in between, so at 45, 135, 225, and 315 degrees azimuth. Less good news: I still need to supply the GEM-offset corrected for the 0.233m mount geometry, so I have been running this test with 0.19m 'GEM-offset' (better to call it "Additional GEM-offset"). I can also confirm that the LAT-offset works fine now and that entering a positive figure for it in the GUI, produces the offset that is shown in the InFINNity Deck image. I have tested it with positive and negative values and it clearly makes a difference between correct and incorrect dome-azimuths.

The 3D window behaved very well when I restarted again this evening, but after parking it looked odd again. During the tests it behaved very well.

So now the only thing left for you to decide in this respect is what to do with the GEM-offset:

leave it how it is now and modify the image to show what should be entered (and call that entry on the dome-TAB "Additional GEM-offset"); leave the image how it is and modify MW4 not to use the preset GEM-offset. The former makes MW4 very consistent, as all the mount's dimensions come from the program, which is easy to explain. The latter is less confusing, unless it is very clearly stated that it is not a GEM-offset, but an addition to it. Choosing this option means we need to test again, but that is no problem.

I have no preference.

Nicolàs

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mworion/MountWizzard4/issues/40#issuecomment-640264013, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSTMFGY3EHDKAL2C6SK75LRVPPZ3ANCNFSM4NO3VSTQ.

[InFINNity-Deck]

Hi Michel,

no hurry, MW4 is working fine now, while the weather will be too lousy for the coming days to do a real test. Please let me know once you decided what to do with the GEM-offset (so whether or not you would like to receive a new image).

Thank you for al the work and quick responses, it felt like good teamwork! If you ever need a dome-tester again, you know where to find me. ;-)

cheers, Nicolàs

[mworion]

Thanks Nicolas,

as soon as you have some practical experiences. please let me know. I leave this point open until final clearance about geometry and documentation works.

Michel

[mworion]

Hi Nicolas, finally I watched the problem. The calculation go GEM and all the stuff was OK, the only point was the sequence of the initialization of the geometry values and the dome settings. The letter took place before the mount initialization was done and got overwritten. So if you test the settings now after MW4 start without changing the GEM value, you will see the fault. And therefore you adjusted the value. If you change this value after MW4 only once during this lifecycle, it would be OK without your correction. I changed this and it will be corrected in 0.150.25. So there is no reason not to go for the standard GEM values. Michel

[InFINNity-Deck]

Hi Michel,

thanks, good to hear, looking forward to the next edition.

Nicolàs