Login
Support Sailonline
If you haven't already - join the SAILONLINE YACHT CLUB!
Please also consider making a donation - all amounts are greatly appreciated!
Board
»
Technical Discussion
»
Performance loss
Page: First Previous 7 8 9 10 11 12 13 Next
|
Posted by dtayls  |
|
|
It has been talked about for years, but I think the time for an update to the 'performance' model has finally arrived. The following is my summary and the beginnings of a proposal.
I have just re-read this thread (Performance loss) as well as the original 2008 Wrong Speed VMG topic. For anyone interested in the topic I would recommend reading both in full. The original 2008 topic gave some interesting insights in to the thinking behind the original PL approach adopted, but both then and now there are some major frustrations amongst both new and old SOLers with the model and how it works. The original purpose was apparently to stop certain behaviours that were (presumably) causing undue load on the server or other problems. Back in 2009 jacob wrote the following:
BUT, with modern yachts - some of which can do in excess of 40kts - this model has clearly outlived its useful life and become a liability. It also penalizes newbies unnecessarily for simple learning mistakes. Now, there have been a lot of good ideas proposed including momentum-based models, etc but I really think we need to keep it simple for a couple of reasons. Firstly, the model needs to be intuitive. It should make sense to IRL sailors as well as those new to SOL and to sailing in general. Secondly, it needs to be fair. It should not require intimate knowledge of the internals of the model - which I know and refuse to use - to sail a reasonable race. And thirdly, it should be easy to implement and relatively light on the server end. This one probably won't be so obvious to those without a computer science or engineering background, but it turns out that while linear responses are easy to graph and to understand, exponential responses - the way a lot of the natural world works - are actually really easy to do in 'discrete simulations' (eg. computer simulations such as SOL where everything moves in steps of say 15 seconds). The basics of my proposal are as follows: 1. Scrap the per-degree PL penalty entirely. There is no basis in reality and I think no value in SOL. Also, newbies need to be able to play with direction changes. Of course, those effectively using autopilots (ie. large numbers of DCs) are another matter entirely and should simply declare their hand for all to see. 2. The 93% limit is a joke and needs to be scrapped. There is no basis for it and it is badly implemented. For instance, today I got down to 80% whereas if I had 'gamed it' then I would have never gone below 93%. This moves the focus from sailing to the gaming engine in which case EVERYONE loses. Ok. That's two of the pillars of the current model discarded, so what's left? Tacks and gybes clearly have performance impacts IRL and these need to be reflected in the SOL gaming engine. A yacht can almost stop in a tack but recovery is relatively quick whereas there is often little speed loss during a gybe but recovering any lost speed can take a very long time. Looking at this from an engineering perspective, apparent wind strength (AWS) seems to be a very important factor here and it may be something that can be used to drive the 'recovery model'. Consider that before, during and after a tack the AWS is higher than it is for a gybe. What's more, in the seconds and minutes after a tack the AWS increases as the boat speed picks up thus increasing the driving/accelerating force, whereas, in the case of a gybe, as boat speed increases the AWS goes down and the accelerating force decreases meaning that it will take longer and longer to reach that theoretical max downwind speed for a given angle. I propose (arbitrary) penalties of 25% for a tack and 10% for a gybe. 'Recovery' is then a different a matter. It should probably apply to ANY course change. At the time of any course change we know (a) the current boat speed which may of course be less than optimal (b) the theoretical boat speed on the new course according to the polar of the yacht and (c) the apparent wind speed (AWS). Given the appropriate combination of all three of these I think we should be able to develop a model for 'recovery' (or should we call it acceleration?) that makes sense to everyone. BTW, a change to a point of sail on the polar that indicates a lower theoretical speed than current should be immediate. The 'recovery model' should only be applied when a positive change in speed is indicated. Should 'recovery' etc depend on the weight of the boat etc? Perhaps. Do we have this information today? No. Could we get this information? Yes. Where? I have some thoughts on this that I would be happy to share. If we can get some agreement on these ideas then I will happily look at coding it ... with the agreement and assistance of hmmm and the SOL management team, of course. |
|
|
Posted by kroppyer  |
|
|
Very quick reply because I'm running late:
Your insight that AWS is more important than TWS for performance loss is wonderful! We have thrown some ideas around (via mails) and I think that, let's call it, "mechanical performance loss" is not the main part of the distance/time lost during a gybe or tack or anything else. It's moving sails and other weight around, many gybes/tack takes an impact on the crew. A penalty for non tack-changing manoeuvres should stay. This mainly simulates changing sails, but it's also necessary to prevent "polar hopping" every minute along a given path where the TWS gives the best VMC. I will read the older thread, I didn't know about it... |
|
|
Posted by dtayls |
|
|
Thanks kroppyer. I truly think that apparent wind (AWS) is a relevant driver for any meaningful performance model, particularly for the 'recovery' phase.
It think it's clear that we disagree on the question of penalties for non-tacking course-change manouevres. In reality, most sail changes occur when we go around marks where we change from up-wind to down-wind or vice-versa. Other than that, sail changes usually occur due to changes in the sailing environment - wind strength or direction changes - rather than as a change directed by the navigator (or SOLer, in our case). Of course, these can't be easily incorporated in to SOL because (a) our polars aren't sail-combo-specific and (b) that would be way too complex for most folk anyway! You mention "polar hopping" as an issue but I don't quite get it. As far as I can see the current system not only supports but encourages small automated changes as these incur virtually no penalty. Systems that do this have many names but I simply call them 'autopilots'. And while I like playing with such technologies, I don't really want to race against them. As a sailor I want something close to real-life. Realism is good, but this is a game after all so I'm happy to compromise a bit. As an engineer I just want to create a model that makes sense ... to me, to sailors, and to novices alike. As a programmer I want something I can implement cleanly and easily that will not suck the life out of the server platform through unnecessary calculations. The 'performance model' (loss and recovery) has clearly been an issue for many years now. I personally think the time has come to tackle it and resolve it once-and-for-all. There are two main forum threads dealing with this issue. If there are related thoughts/ideas/etc that have been shared only in emails then perhaps they should be shared here as well. BTW. I am likely to go ferral on this issue if we don't get some traction ... |
|
|
Posted by Karri  |
|
- End quote
I don't know about "automated changes", as I would understand that "automatic" would mean something that would somehow react to something as opposed to "precalculated" and "preprogrammed". I do use relatively large quantities of DCs (up to 200 per wx), which I calculate once the wx is available and I've done my routing exercises, but in my opinion there is no more automation involved in than that setting ten DCs. To an outside observer that might appear as "automated changes". I don't know where you are going with this discussion, but if the idea would be to somehow penalise setting a lot of DCs, I fail to see the idea behind that. Would you limit the number of course changes allowed in IRL sailing? --- Last Edited by karriv at 2014-11-13 14:47:01 --- --- Last Edited by karriv at 2014-11-13 14:47:54 --- My opinions may have changed, but not the fact that I'm right. |
|
|
Posted by kroppyer |
|
|
I think I'm starting to understand what dtayls talks about. Correct me if I'm wrong.
A course change of 5 degrees results in more performance loss than 5 course changes of 1 degree (over a longer period of time). My reaction to that: that difference is negligible compared to the loss as a result of not sailing the fastest course. Those bigger jumps in HDG are only advantageous when polar hopping. Since most dents on the polar are caused by sailchanges, a performance penalty for such a change is not so weird. I will get back to this and expand tonight (UTC+1) |
|
|
Posted by Karri |
|
|
Kroppyer, you are right, but that is not why I use a lot of DCs. The reason is to be as much as possible on the optimal course, and that by "rounding" the track you save distance compared to doing sharp angles. This has much more to do with implementation of optimal route as I described it in the router-thread than performance loss.
I actually tested doing a turn in multiple steps to reduce the perf loss, in a situation where you had to bear away after a mark about 30 degrees. Doesn't work, you loose much more in running a suboptimal route than what you gain in perf loss. If you are talking about course changes of some degrees, perf loss is totally insignificant even in the AC72. My opinions may have changed, but not the fact that I'm right. |
|
|
Posted by kroppyer |
|
|
Why is performance loss necessary for non-tack-changing manoeuvres?
Sometimes you want to sail along a path of better wind pressure, when there's no shift to play with. Often, you can just sail along this path. Sometimes, the wind angle is such that you would be sailing in a dent of the polar if you followed the path. Most common is the upwind dent, or downwind dent. Solution to that is to do quick tacks of gybes along the path following VMG angles. That's not realistic, no one does 100+ tacks/gybes an hour. So performance loss is calculated for each tack/gybe, making it faster to leave more time between the tacks/gybes. A bit less common is that it's not the upwind or downwind dent, but a dent between, say, code 0 and gennaker (I know we don't really have sailchanges in sol, but the polars show the dents anyway). In this case sailing in the dent of the polar is slower than sailing with the code 0 for about 30 seconds, then with the gennaker back across the centre of the path, and continue "polar hopping" along the path. This is just as unrealistic as 100+ tacks/gybes an hour, and this is the reason we need performance loss for non-tack-changing manoeuvres. So, performance loss actually hurts any automatic course changes to follow a path (hard to set so many DCs and still stay in the centre of the path). ___ The problem with the current performance model is that it has a learning curve that is far too steep. I want a performance model that is understandable/predictable for people with only IRL sailing knowledge: a realistic model. Everyone must be able to make somewhat accurate guesses for how much distance they will loose after a given course change. That's (I think) what makes strategy games good, when predictions can be done, so that you can think ahead. ___ My personal conclusion (subject to change) is that the (what I call) "mechanical performance loss" (boat changing direction: kinetic energy or momentum, small duration of flapping sails, etc) is too small and quick that it's not useful to make it very realistic. Boats are updated once every 10-20 seconds. If you are able to give an accurate formula to calculate performance loss and recovery after a tack/gybe/whatever, that formula will need to be chopped down into 10-20 second pieces anyway, so all those realistic details will be removed. Other than that, the mechanical performance loss is almost negligible compared to the performance loss due to moving weight around, and crew fatigue. Offwatch crew needs to wake up to move to the bunk on the other side of the boat. You can't to that too often or your crew starts hallucinating from lack of sleep. ___ I am working, with some others, on designing an alternative model. Once we have something we think is good, I hope to share it with you, including our considerations that lead to the new model. Others are free to do the same. Of course this can result in some double work, but I wasn't really expecting many people to jump up and design a new model. |
|
|
Posted by dtayls |
|
|
karriv: I love the technology of routers. As an electrical engineer and a computer scientist I just can't help myself. My ideal today would be using Expedition plugged in to SOL via BrainAid's NMEA plugin, then taking the steering data from Expedition and automatically feeding that back in to SOL.
The problem I have with what you are doing with (say) 200 DCs every 6 hours (ie. one DC every 1.8 mins) is that it either involves an autopilot or a very patient helmsman. In my experience, giving a helmsman a tiny change every couple of minutes is a good way of getting turned into a man-overboard dummy. And from that moment he/she is is going to follow your last instruction to the letter, so don't expect to be recovered from the water any time soon! To be honest, I think it's great that people like you, kroppyer and others are willing to put in so much effort to developing and learning how to use advanced tools. The ultimate gift is then sharing this knowledge with others. |
|
|
Posted by dtayls |
|
|
kroppyer: I think it is fair to say that the whole SOL community is indebted to you for your indepth investigations and analyses, not to mentionion the fact that you share this knowledge so openly. Your analysis of the whole performance model question is invaluable.
I can see what you are saying re 'dents' in the polars. The upwind and downwind ones are obviously the most obvious but there are others and yes these often relate to sail changes. I think it is clear that tacks and gybes should incur a performance penalty, but I personally think SOLers should be allowed to play with the other bumps and lumps to their hearts' content. As far as I can see any gains in actively playing these would be negligible so we'd might as well take the opportunity to simplify the SOL model by removing the dTWA dependency entirely. If anything, maybe turning across a 'dent' should drop your speed to (say) half the depth of the dent. Thereafter it would be up to my generic exponential recovery model for boat speed to return to that indicated by the polar. This would work well for tacks and gybes too delivering a a 50% drop during a tack! During a gybe things would be a little different. A square-rigger, for instance, would see almost no penalty. A VO70 on the other hand would see perhaps a 15% hit, but they can immediately turn to a wind angle that gives them high AWS thus helping them recover any lost speed very quickly before settling at their optimum TWA. Interestingly, while my model is very simple, it potentially encourages IRL sailing skills such as those involved with efficient tacking. Let's say our optimal upwind TWA is 45 degrees. During a tack we lose a bit of speed so we generally lay off a little by going past the optimal angle to say 50 degrees or maybe a little more. As we pick up speed we harden up to the optimal 45 degrees again. |
|
|
Posted by andebjor  |
|
|
If we want to limit the number of tack/gybes per hour, why don't we do just that?
By storing one additional variable for each boat, called e.g. `crew_fatigue', this could be implemented easily. A tack/gybe increases the variable by some value, a course change increases it by a smaller value and a server jump decreases it by an appropriate amount. The performance loss would then depend on this value with a larger loss when the crew is tired. The downside to this would be the introduction of a new variable I suppose. To me it seems like an intuitive variable, but it probably has to be displayed in the client for transparency. |
))
Page: First Previous 7 8 9 10 11 12 13 Next
Please login to post a reply.Races
Next Race: 00d 00h 00m
Current Races:
Chinook Salmon - Canada to Andreanovs
A year after spawning in the upper reaches of the rivers of British Columbia, Chinook Salmon develop the age-old urge, so familiar to SOLers, to go to sea, heading for different parts of the northern Pacific Ocean. This race catches up with a particular school with an instinctive memory for the Andreanov Islands far west on the Aleutian Islands chain, as they depart the Salian Sea between Vancouver Island and the San Juans. It’s 2200nm and we’re taking the 60ft Trimaran, in the hope we can keep up!
Race #2048
INFOby brainaid.de
60ft Trimaran PARTICULARS
WX Updates:
0430 / 1030 / 1630 / 2230
Ranking: MIG - SYC
Race starts: Jul 21st 11:00 Registration Open!
GO TO RACE
Juventud TIMED Race 2026
This is a TIMEDrace so you may RE-REGISTER HEREto try again after finishing a run. You will have two weeks to test your skill and decision making after the race opens.
Race #2049
INFOby brainaid.de
The boat for this race is the sporty Mini 6.5p Foil PARTICULARS
WX Updates:
0430 / 1030 / 1630 / 2230
Ranking:
TRQ3 - TRCH - SYC
RACE CLOSE: Saturday,
1 August at 23:00 UTC
Race starts: Jul 19th 12:00 Registration will open soon
GO TO RACE
Tall Ships 2026 - Antwerpen to Stavanger
Welcome to the third of four virtual Tall Ships Races in European waters which are concurrently being organized in-real-life by Sail Training International . This third race is from Antwerpen back up the North Sea to Stavanger in Norway – another proper tall ship training adventure of circa 450nm, online again in Sailonline’s classic Clipper 240.
NOTE: Starts and Finishes in tall ships racing are always offshore to avoid conflict with shipping and shipping lanes; online and real-life may not match exactly.
Race #1994
INFO by brainaid.de
Clipper 240 PARTICULARS
WX Updates:
0430 / 1030 / 1630 / 2230
Ranking: TSI - SUPBUD - SYC
Race starts: Jul 14th 16:00 Registration Closed
GO TO RACE
Lake Ontario 300 Challenge 2026
Lake Ontario Offshore Racing (LOOR) welcomes Sailonline sailors to a second virtual version of a race in their annual series, and for the sixth year in succession the LO300. As the name implies, the LO300 is a 300nm offshore race across the length and breadth of Lake Ontario, from and back to Port Credit YC. This year, for the first time, we will be racing the 300nm circuit in Sun Fast 3200s. As usual, there is an overall prize for the SOLer who best bosses Lake Ontario over the two races hosted by Sailonline, this LO300 and the Susan Hood raced back in May, and this year also the race and the Susan Hood count towards the title of Super Buddy 2026; so, let the competition be fierce!
Race #2044
INFOby brainaid.de
Sun Fast 3200 PARTICULARS
NAM_AWIP WX Updates:
0245 / 0845 / 1445 / 2045
Ranking: LOOR - SUPBUD - SYC
Race starts: Jul 11th 15:10
Registration Closed
Alaska to Easter Island 2026
INFO by brainaid.de
Imoca 60 Foil v2 PARTICULARS
WX Updates:
0430 / 1030 / 1630 / 2230
Ranking: OCQ3 - RNW - OCCH - SYC
Race starts: Jul 06th 11:00 Registration Closed
GO TO RACE
Cross the Convergence 2026 - Sao Tomé to Tristan
Race #1985
INFOby brainaid.de
Volvo OD65v3 PARTICULARS
WX Updates:
0430 / 1030 / 1630 / 2230
Ranking: CCZ - SYC
Race starts: Jul 03rd 18:00 Registration Closed
GO TO RACE
SYC Ranking
Series
- SYC ranking
- 2026 TSI
- 2026 TRQ4
- 2026 TRQ3
- 2026 TRQ2
- 2026 TRQ1
- 2026 TRCH
- 2026 TQD
- 2026 SUPerBUDdy
- 2026 SSANZ
- 2026 SPQ4
- 2026 SPQ3
- 2026 SPQ2
- 2026 SPQ1
- 2026 SPCH
- 2026 SHE
- 2026 ROW
- 2026 RNW
- 2026 RNI
- 2026 RMI
- 2026 RED
- 2026 OCQ4
- 2026 OCQ3
- 2026 OCQ2
- 2026 OCQ1
- 2026 OCCH
- 2026 NIA
- 2026 MIG
- 2026 MED
- 2026 LOOR
- 2026 CCZ
- 2026 BOL
- 2026 B2B
- 2025 TS
- 2025 TRQ4
- 2025 TRQ3
- 2025 TRQ2
- 2025 TRQ1
- 2025 TRCH
- 2025 TD
- 2025 SuperSOLer
- 2025 SSANZ
- 2025 SPRCH
- 2025 SPQ4
- 2025 SPQ3
- 2025 SPQ2
- 2025 SPQ1
- 2025 SHE
- 2025 SBB
- 2025 RWW
- 2025 RMI
- 2025 RED
- 2025 OCQ4
- 2025 OCQ3
- 2025 OCQ2
- 2025 OCQ1
- 2025 OCCH
- 2025 NT
- 2025 LOOR
- 2025 DN
- 2025 B2B
- 2025 ARQ4
- 2025 ARQ3
- 2025 ARQ2
- 2025 ARQ1
- 2025 ARCH
- 2025 ABS
- 2024 TS
- 2024 TRQ4
- 2024 TRQ3
- 2024 TRQ2
- 2024 TRQ1
- 2024 TRCH
- 2024 TD
- 2024 SVF
- 2024 SUPerSOLer
- 2024 SSANZ
- 2024 SPRQ4
- 2024 SPRQ3
- 2024 SPRQ2
- 2024 SPRQ1
- 2024 SPRCH
- 2024 SHE
- 2024 RTW
- 2024 RMS
- 2024 OCQ4
- 2024 OCQ3
- 2024 OCQ2
- 2024 OCQ1
- 2024 OCCH
- 2024 LOOR
- 2024 HILAT
- 2024 GWT
- 2024 DN
- 2024 CRW
- 2024 B2B
- 2024 ARQ4
- 2024 ARQ3
- 2024 ARQ2
- 2024 ARQ1
- 2024 ARCH
- 2023 TS
- 2023 TRQ4
- 2023 TRQ3
- 2023 TRQ2
- 2023 TRQ1
- 2023 TRCH
- 2023 TD
- 2023 SVS
- 2023 SUPerSOLer
- 2023 SSANZ
- 2023 SPRQ4
- 2023 SPRQ3
- 2023 SPRQ2
- 2023 SPRQ1
- 2023 SPRCH
- 2023 SHE
- 2023 RTW
- 2023 RNI
- 2023 RMS
- 2023 PIC
- 2023 OCQ4
- 2023 OCQ3
- 2023 OCQ2
- 2023 OCQ1
- 2023 OCCH
- 2023 LOOR
- 2023 DN
- 2023 ARQ4
- 2023 ARQ3
- 2023 ARQ2
- 2023 ARQ1
- 2023 ARCH
- 2022 TRQ4
- 2022 TRQ3
- 2022 TRQ2
- 2022 TRQ1
- 2022 TRCH
- 2022 TD
- 2022 Tall Ships
- 2022 SUPerSOLer
- 2022 SSANZ
- 2022 SSA
- 2022 SPRQ4
- 2022 SPRQ3
- 2022 SPRQ2
- 2022 SPRQ1
- 2022 SPRCH
- 2022 SHE
- 2022 OCQ4
- 2022 OCQ3
- 2022 OCQ2
- 2022 OCQ1
- 2022 OCCH
- 2022 NTR
- 2022 LOOR
- 2022 CTR
- 2022 ARQ4
- 2022 ARQ3
- 2022 ARQ2
- 2022 ARQ1
- 2022 ARCH
- 2021 TRQ4
- 2021 TRQ3
- 2021 TRQ2
- 2021 TRQ1
- 2021 TRCH
- 2021 TD
- 2021 Tall Ships
- 2021 SYCQ4
- 2021 SYCQ3
- 2021 SYCQ2
- 2021 SYCQ1
- 2021 SYCCH
- 2021 SUPerSOLer
- 2021 SSANZ
- 2021 SPRQ4
- 2021 SPRQ3
- 2021 SPRQ2
- 2021 SPRQ1
- 2021 SPRCH
- 2021 Shetland
- 2021 PAC6
- 2021 OCQ4
- 2021 OCQ3
- 2021 OCQ2
- 2021 OCQ1
- 2021 OCCH
- 2021 ESRW
- 2020 TSE
- 2020 TSA
- 2020 TRQ4
- 2020 TRQ4
- 2020 TRQ3
- 2020 TRQ2
- 2020 TRQ1
- 2020 TRCH
- 2020 Tasman Double
- 2020 SYCQ4
- 2020 SYCQ3
- 2020 SYCQ2
- 2020 SYCQ1
- 2020 SYCCH
- 2020 SUPerSOLer
- 2020 SSANZ
- 2020 SRQ4
- 2020 SRQ3
- 2020 SRQ2
- 2020 SRQ1
- 2020 SPRCH
- 2020 Shetland
- 2020 RTW
- 2020 RNI
- 2020 Odyssey
- 2020 OCQ4
- 2020 OCQ3
- 2020 OCQ2
- 2020 OCQ1
- 2020 OCCH
- 2020 A3
- 2019 TRQ4
- 2019 TRQ3
- 2019 TRQ2
- 2019 TRQ1
- 2019 TRCH
- 2019 Tasman Double
- 2019 Tall Ships
- 2019 SYCQ4
- 2019 SYCQ3
- 2019 SYCQ2
- 2019 SYCQ1
- 2019 SYCCH
- 2019 SUPerSOLer
- 2019 SSANZ
- 2019 SRQ4
- 2019 SRQ3
- 2019 SRQ2
- 2019 SRQ1
- 2019 SPRCH
- 2019 Shetland
- 2019 Round New Zealand
- 2019 OCQ4
- 2019 OCQ3
- 2019 OCQ2
- 2019 OCQ1
- 2019 OCCH
- 2018 TRQ4
- 2018 TRQ3
- 2018 TRQ2
- 2018 TRQ1
- 2018 TRCH
- 2018 Tasman Double
- 2018 Tall Ships
- 2018 SUPSOL
- 2018 SSANZ Triple
- 2018 SRQ4
- 2018 SRQ3
- 2018 SRQ2
- 2018 SRQ1
- 2018 SPRCH
- 2018 Shetland
- 2018 Shackleton Challenge
- 2018 OCQ4
- 2018 OCQ3
- 2018 OCQ2
- 2018 OCQ1
- 2018 OCCH
- 2018 40CH
- 2017 TS RDV
- 2017 TRQ4
- 2017 TRQ3
- 2017 TRQ2
- 2017 TRQ1
- 2017 TRCH
- 2017 Tasman Double
- 2017 Tall Ships
- 2017 SWR
- 2017 SUPSOL
- 2017 SSANZ Triple
- 2017 SSANZ RNI
- 2017 SPRR3
- 2017 SPRR2
- 2017 SPRR1
- 2017 SPRCH
- 2017 Red Dot
- 2017 OCQ4
- 2017 OCQ3
- 2017 OCQ2
- 2017 OCQ1
- 2017 OCCH
- 2017 40CQ3&4
- 2017 40CQ1&2
- 2016 TRQ4
- 2016 TRQ3
- 2016 TRQ2
- 2016 TRQ1
- 2016 TRCH
- 2016 Tasman Double
- 2016 Tall Ships
- 2016 SUPSOL
- 2016 SSANZ Triple
- 2016 SRQ4
- 2016 SRQ3
- 2016 SRQ2
- 2016 SRQ1
- 2016 SPRCH
- 2016 RTWR
- 2016 OCQ4
- 2016 OCQ3
- 2016 OCQ2
- 2016 OCQ1
- 2016 OCCH
- 2016 Corporate Open Gold
- 2016 A3
- 2015 TRQ4
- 2015 TRQ3
- 2015 TRQ2
- 2015 TRQ1
- 2015 TRCH
- 2015 Tasman Double
- 2015 Tall Ships
- 2015 SYQ4
- 2015 SYQ3
- 2015 SYQ2
- 2015 SYQ1
- 2015 SYCCH
- 2015 SUPSOL
- 2015 SSANZ Triple
- 2015 SRQ4
- 2015 SRQ3
- 2015 SRQ2
- 2015 SRQ1
- 2015 SPRCH
- 2015 OCQ4
- 2015 OCQ3
- 2015 OCQ2
- 2015 OCQ1
- 2015 OCCH
- 2015 Aegean Rally
- 2014 Timed Races Championship
- 2014 Tasman Double
- 2014 Tall Ships
- 2014 SYC Championship
- 2014 SSANZ Trio
- 2014 SSANZ RNI
- 2014 Sprints Championship
- 2014 Scandinavian Tour
- 2014 Round The World Race
- 2014 Ocean Championship
- 2014-2015 Sailonline World Race
- 2013 Tall Ships
- 2013 SYC Championship
- 2013 SSANZ B&G Simrad
- 2013 Capt Anderson
- 2012 W Australia Regatta
- 2012 Tall Ships
- 2012 SSANZ B&G Simrad
- 2012 RNZ Two Handed
- 2012 Global Challenge
- 2012 Ecker Cup
- 2012 Black Sea
- 2012 A3
- 2011 Vancouver Island
- 2011 Tasman Double
- 2011 SSANZ B&G Simrad
- 2011 SOL Global Challenge
- 2011 SJORA Series
- 2011 Scandinavian Tour
- 2011 Round North Island
- 2011 Asian Sprints
- 2011-2012 SOL World Race
- 2010 Tasman Double
- 2010 Ouzo Rally
- 2010 Iberian Tour
- 2010 Auckland Regional
- 2009 French SOLo
- 2009 Bosphore - Bretagne
- 2008 SYCC
- 2008 -2013 SYC Week Race Championship
- 2008 -2013 SYC Week-End Race Championship
- 2008 -2013 SYC Ocean Race Championship
- 2008-2009 Sailonline Ocean Race
- 2004 LOOR
Mobile Client
SYC members have the benefit of access to our mobile/lightweight web client!