CumulusX! multiplayer questions

[JamesAllen 0]

Hi Peter at al.

I am a member of the UK VGA (UK Virtual Gliding Association) and have been conducting some multiplayer experiments with other members using CumulusX! "MP Soaring Clock".

My current, albeit limited understanding, of the pseudo-random generation of thermals in CumulusX! is that the random generation of thermals is seeded from a combination of landclass, mesh, certain weather conditions, and date/time. Also of course the CumulusX! settings must be identical. Most of these requirements we found to be relatively easy to control and match between participants except for time across multiple time zones. We are currently working on ways to minimise the time difference, but this effort may be wasted if this not the issue, or if we are never going to be able to achieve the level of accuracy needed with FSX running on different PCs across multiple time zones.

So my questions are:

1. Assuming time difference is a significant issue in a CumulusX! multiplayer environment, how accurate must the time synchronisation between players be for players to have a reasonable expectation of being able to find thermals in the same place at the same time and with the same characteristics? That is, are we talking a difference of less than seconds, minutes or hours?

2. Also, in view of the fact that the following clocks can get out of alignment if you are not careful, is the reference time for CumulusX! seeding of thermals taken from:

a: the system (real-world) UTC clock?

b: the FSX virtual GMT clock?

c: the FSX virtual Local Time clock?

d: or some combination of these?

Regards,

-James

[Peter Lürkens 30]

... how accurate must the time synchronisation between players be for players to have a reasonable expectation ...

.... is the reference time for CumulusX! seeding of thermals taken from:

a: the system (real-world) UTC clock?

b: the FSX virtual GMT clock?

c: the FSX virtual Local Time clock?

d: or some combination of these?

Hi James,

easy answer. The thermal scheme requires a minute accurate alignment of the clocks, and it is a combination of b: and c:. Timing of a n individual thermal is handled by Zulu time, while sun irradiation on thermal triggers and the decision on appearance is done with local time.

However, there is a very easy method for synchronization as long as the computers have a valid GMT time source. If you have a properly configured XP, Vista or Win7 and internet connection this is the case most of the time. In this case just issue the command "CumulusX! Soaring Clock" from the CumulusX! add-on menu in FSX. You should a agree on one of the time schedules beforehand. This syncs your FSX session with GMT time such, that you always land in the indicated time window which is in the second half of the day. In addition, it adjusts the date to some reasonable soaring season (depnding on your hemisphere). Most of the time this should be sufficient to start a synced session.

After that the time is no more touched, so there is no "wrap around".

Cheers,

Peter

[Bulau 0]

Maybe I will have to test this Soaring Clock.

We have been doing FSX multiplayer DirectIP, and all players just loading the same .FLT, .WX as the host when joining. I thought that was sufficient to guarantee everybody's clocks synchronized with the host for CumulusX! purposes, however we have still noticed occasionally, seeing each other thermalling where there is no cloud. I thought that might be due to late joining, but shouldn't FSX take care of that?

[sf4JC 1]

I think I've noticed on occasion, and I think I've read somewhere that the time zones in Microsoft Flight Simulators haven't always been accurate. So if I were to start the sim in my local time, and then move to your location, it may be off by an hour or so from your local time.

Scott

[Peter Lürkens 30]

We have been doing FSX multiplayer DirectIP, and all players just loading the same .FLT, .WX as the host when joining.

.... however we have still noticed occasionally, seeing each other thermalling where there is no cloud ...

Hi,

there is no need for extra sync in FSX MP. Weather and time/date are always set by the host, equal for all participants. Also flight loading is not necessary for the clients (except from flightplans, plane selection). The difference you saw might be from differences at scenery/mesh/landclass at the participants. Late joining shouldn't be the reason. If any initially, it should sort out after a few minutes.

Cheers,

Peter

[JamesAllen 0]

Thanks Peter,

That was the answer that I was hoping for. If the requirement had been seconds or less we would have had a major issue in getting all players into time sync. The use of the two virtual clocks explains why we failed on our first test. On the first test we had trouble getting our respective FSX clocks aligned with both virtual GMT and virtual Local Time simultaneously. Even when we had local time synchronised between players to within about 8 seconds of each other the virtual GMT clocks were up to 2 hours different. At the time we didn't understand what was causing this, nor how to fix it.

We have now worked out a method to align both virtual clocks in FSX with the correct time offset for the location venue. There will still be an overall time difference of around 5 to 10 seconds between players after the GMT adjustment procedure which we believe may be due to scenery load times and differences in time taken to manually set the clocks. The difference will be more for players with slow PCs. We believe that we can improve on the overall time difference between players by carrying out the adjustment procedure twice because the scenery load time is often much less on the second adjustment and thus the difference between players ends up being less as well. Unfortunately, we cannot do much about the scenery load times on different PCs after activating the MP Soaring Clock, but hopefully after the MP Soaring Clock adjustment the time difference will still be within a minute.

Now that we know how to align the virtual GMT and virtual Local Time in FSX and that the target time difference is 1 minute, we will give it another try with a greater degree of confidence that we have an achievable target.

Regards,

-James

[JamesAllen 0]

Scott,

Try this method to get your FSX virtual and FSX GMT clocks back into proper alignment, it seems to work for me (if anyone knows of a better way please let me know).

1. Open the saved flight or a Free Flight at the target location

2. Select World->Time and Season... in the FSX menu bar

3. Click on the "Reset" button to reset to your local time, but more importantly it will set the minutes and seconds close to the correct values for virtual GMT.

4. Now click on the hours of virtual GMT to select this - then adjust up or down to match the current hour for real-world UTC (Zulu time) - you will need to get this from another source such as the Internet. You may need to change the FSX virtual date as well if that is different to the real-world date of the target location. Also leave the virtual Local time alone even though it is now wrong.

5. Click on "OK" and the scenery should now re-load with (almost) correct local time for the chosen venue and virtual GMT should now have the correct offset to this time.

6 . If you want to be more accurate, repeat stages 2 to 5 again because the scenery will load much quicker the second time and the virtual time might then be closer to real time at the task location.

Cheers,

-James

[JamesAllen 0]

Scott,

This is a correction to my last reply:

I just ran a test of this procedure and found that adjusting the GMT hours up down doesn't seem to affect the date even if you roll the time through midnight - so you needn't be concerned about that. However, you may have to adjust the virtual date if it is different to the real-world time at the target location in step 4.

I have now corrected the procedure in previous reply - I hope!!

Cheers,

-James

[sf4JC 1]

Yea, usually what I do is, give a website that gives a time, and everybody in FSX needs to sync to it since those in FS2004 will be at the right time by the time FSHost sets for them. Or at least I hope I've always done it right. Now I'm going to have to do some testing this week to make sure I get FSHost time synced with the website time correctly.

Scott

[JamesAllen 0]

Hi Peter et al,

I probably should have mentioned in my first post that we are not using FSX Multi-player mode - we use VATSIM in the UKVGA for our weekly group launch events.

Now that we know that CumulusX! uses the FSX virtual clock for seeding thermal generation we decided to try another test and concentrate on getting the virtual clocks as closely as we could. Unfortunately our second multi-player test was mostly a failure, although two members of our test team did find some common thermals, but we believe that this was just a coincidence. One of the two testers that did find some common thermals with one of our team of three, had his FSX crash after we had synchronised our clocks. He then had to restart FSX and try to get his virtual clocks aligned with the real-world time again and then try to catch up with the other two of us that had already launched our gliders. So it is very unlikely that he could have had an identical thermal distribution with one of us. We were prevented from rechecking clock sync at this stage because first my FSX crashed and then our tester who had previously crashed FSX crashed again!

We were expecting to see some short term differences due the slight miss-alignment of our virtual local time clocks affecting the beginning and end of the life cycles of the thermals. However, in all of our testing we have not been able to find any evidence, other than that strange incident mentioned above, of the existence of a common thermal environment. We have used flight tests and image snapshots from the cockpit and plan view. After the final attempt we made to synchronise our clocks we took some more plan view snapshots over the airfield, Unfortunately we only got two images because our third tester had his FSX crash yet again. However, in the two images taken we saw the best result of them all with 5 matching thermals with only two additional thermals in one image, so we immediately launched for a flight test but could not find any common thermals during that flight. Our testing hasn't been a total waste of time though, because throughout the testing we have all been enjoying some of the best thermals conditions ever experienced in FSX.

For our testing we were using saved flights and weather. The weather was set to force CumulusX! to produce blue thermals with zero wind and no clouds defined. We also made sure that all external weather sources were not activated. We selected a venue for the testing where all of the testers had default Microsoft scenery, mesh and land classes. We used a CumulusX! settings file to make sure they were the same on all testers' PCs. Moreover, we manually checked the weather and CumulusX! settings to make sure that they were all the same.

Then we synchronised our FSX virtual GMT and virtual Local Time clocks using the method shown in a previous post of mine on this topic. After the second pass of this procedure our times were within approximately 13 seconds of each other. We could not get them much closer than that because one member of the test team was using solid state disks, which meant that his scenery loaded much quicker than the others so his clock always restarted sooner after being reset.

After activating the the CumulusX! MP Soaring Clock the difference between our respective FSX virtual clocks grew to 24 seconds - again due mostly to the scenery load times, although communication delay and human reaction times would have had an influence as well.

As things stand, we are not sure if our failure is because our clock synchronisation is not accurate enough, or if we need to be looking for some other difference(s) in environmental influences on thermal generation that we may have overlooked. We would like to try another test, but I have some more questions based on the failures we have experienced so far.

1. At what point in time does CumulusX! sample the FSX virtual GMT clock. Is as soon as we activate the MP Soaring Clock and before the scenery reloads, or is it after the scenery loads and the virtual clocks are restarted?

2. Even though we believe that we all have the same scenery, terrain mesh and land classes, are there any FSX graphics settings, such as mesh complexity etc., that might we may also need to make the same for all participants in a multi-player session?

3. Is there any good reason why CumulusX! could not be changed to use the system GMT time to seed the pseudo-random distribution of nominal thermals? Using the system GMT (real-world) would surely be more likely to more accurately in sync between participants provided their PCs were synchronised to a reliable source. And then CumulusX! could use the system GMT clock to adjust the virtual Local Time to a suitable soaring time based on the selected shift schema and the local GMT offset. There would still be the issue of the different scenery load times that would result in significant virtual local time differences between participants, but it is likely the time difference would be less than using manual methods to align our virtual clocks as we are trying to do now.

Apart from these specific questions, any other suggestions on how we can get our clocks synchronised more accurately or otherwise how we might improve our chances of creating a common thermal environment in a VATSIM multi-player network would be welcome.

Cheers,

-James

[Peter Lürkens 30]

Hi James,

before going into detail, first two questions from my side:

1) did you make sure not only to have the same sim-time but also the same date?

2) have you been able to test after using the "CumulusX! soaring clock" sync method?

I'd say, that 24 seconds lag is still not very critical, as it would only a shift the life cycles of a thermal by that amount between the clients. This might be somewhat relevant only in the beginning, or at the end of thermal's life cycle. There shouldn't been any noticable difference during the main phase of a thermal.

Cheers,

Peter

[JamesAllen 0]

Hi Peter,

In answer to question 1, yes we did check dates after syncing FSX Clocks and after activating the CumulusX! MP Soaring Clock.

In regards to question 2, we did all of our testing after activating the CumulusX! MP Soaring Clock because it was night time or early morning in real time at the chosen virtual test location in the USA - it was also winter time of course - so we would not have gotten any thermals there without using the MP Soaring Clock or shifting our dates manually. We did not try shifting dates and time manually.

One problem we did have is that to check our times in FSX we had to pause our clocks again and then have them re-start again after a scenery reload. We tried to do these checks in a synchronous way using TeamSpeak to minimise additional differences being added to our clocks. We are planning another test using a newer model of a glider that is fitted with an analogue clock that also has a second hand. This will allow us to confirm our time sync, or near sync, without pausing our clocks to access the Time and Seasons setting in FSX.

I have just now finished analysing some more of the snapshot images that were taken during our testing. In comparing the images from all 3 participants, with the exception of two images mentioned in my previous post, there doesn't appear to have been any significant matching of individual thermals in terms absolute location or relative location, even if you allow for slight differences in life cycle times. We each took images in batches of three synchronised using using verbal instructions over TeamSpeak to minimise the effect of life cycle differences . The images did show some clusters or occurrences of thermals in certain common areas of the landscape, as you would expect I suppose due to favourable land classes or terrain/solar irradiation etc. in those areas.

Regards,

-James

[Peter Lürkens 30]

Hi James,

sorry for the late reply, I missed your last post somehow. That seems indeed not what it should be.

Please, could you do the following:

• 
  
  
• Set up your situation as during your tests, wait a minute.
  
• Go to "Top down view" and zoom out until the cloud-filled circle is visible.
  
• Make a screenshot (pls convert to JPG).
  
• Zip the screenshot and your flt/wx ... files and send it to me.
  
• Do the same with another PC that shows the different coverage.
  

Well, as I said, even a time difference of a minute should not lead to significant differences of the coverage.

Cheers,

Peter

[JamesAllen 0]

Hi Peter,

I have emailed the requested images, the setup files and a report of our most recent test session. The latest test did not reveal anything new even though we were even more rigorous this time in trying to elliminate any differences between the participants.

Regards,

-James

Hi James,

sorry for the late reply, I missed your last post somehow. That seems indeed not what it should be.

Please, could you do the following:

• Set up your situation as during your tests, wait a minute.
• Go to "Top down view" and zoom out until the cloud-filled circle is visible.
• Make a screenshot (pls convert to JPG).
• Zip the screenshot and your flt/wx ... files and send it to me.
• Do the same with another PC that shows the different coverage.

Well, as I said, even a time difference of a minute should not lead to significant differences of the coverage.

Cheers,

Peter

[JamesAllen 0]

Thanks Peter,

The new CumulusX! 1.8.1 patch has sovled our multi-player environment problems for our FSX Acceleration Pack users exactly as you predicted. In several recent test events, members of the UK Virtula Gliding Association with FSX Sp2 and also with FSX Acceleration Pack have been able to enjoy the experience of flying together on VATSIM in identical auto-generated thermals using the new CumulusX! patch. Your assitance with this issue is greatly appreciated.

Cheers,

-James