Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by JamesAllen

  1. Hi Rafael, You don't have to worry about the tow planes on VATSIM – they are not visible to other users. The UK VGA members fly regularly online using CumulusX! on VATSIM with synchronised soaring environment (typically twice a week). We take advantage of the multiplayer features of CumulusX! to provide a common soaring environment for our association group launches. So we often have multiple gliders sharing the same thermal, of chasing each other along the same ridge, although with our club the competitive aspects of our online soaring are mainly focused on x-country task completion and badge achievements rather than outright racing. Most of our members are now using FSInn in preference to Squawkbox mainly because it seems to be more reliable but also the graphics representation of other aircraft appears to be slightly less choppy. FSInn is much harder to set up properly though. Also there can be issues with glider models not displaying as the correct aircraft type to other players if you fail to set your model type correctly before connecting to VATSIM, or if they don't have your model type installed. Our club has some configuration files and advice for members to minimise this. Nevertheless, there are still some issues because our members like to use a wide variety of glider models, particularly on our vintage nights. Also the Aerosoft Discus X is a worst case for this sort of issue because on VATSIM it looks as thought it is standing upright with its tail stuck in the ground when on the ground although it looks normal when airborne. We have done some testing of FSX Multiplayer Mode using the Wippien VPN and/or direct connects and the results were very good compared to VATSIM, however this mode requires reliable broadband connections, which a few of members do not have. VATSIM is more tolerant of disconnections and a player can reconnect without interrupting the task that they are flying. So we now only use FSX Multiplayer Mode for ad hoc events or buddy flight arranged between members. Tow planes are a slight issue in this mode but if you use the registered version of CumulusX! then you can optionally use the smart towplane feature, and then sometimes your tug will find its way back to airfield, land, taxi to parking and then vaporise, but not always. You have to be careful when launching that there isn't a tug returning to land, so the call from our launch point controller of “All clear above and behind!” has some real meaning in this mode. Also some of our members prefer to winch launch anyway. So far the lost tugs haven't been a big issue for us when using this multiplayer mode. Cheers, -James
  2. This reply post was corrupt for some reason and in my first attempt I could not edit ot delete the post - so my reply follows in the next post -James
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  • Create New...