Settings and activity
15 results found
-
29 votes
An error occurred while saving the comment 
Jan Langkjær Hansen (eCKD)
supported this idea
·
-
13 votesJan Langkjær Hansen (eCKD)
supported this idea
·
-
22 votes
An error occurred while saving the comment Jan Langkjær Hansen (eCKD)
commented
For a race with more timeslots for a combined result to be just close to fair we surely need possibility to specify wind strength AND direction, so it will be same for all timeslots for a given stage.
A degree of randomization and/or specified variation during race both in direction and strength could be alright. But for a start, just constant direction constant strength for the duration of the event would be highly appreciated.
Jan Langkjær Hansen (eCKD)
supported this idea
·
-
4 votesJan Langkjær Hansen (eCKD)
supported this idea
·
-
16 votesJan Langkjær Hansen (eCKD)
supported this idea
·
An error occurred while saving the comment Jan Langkjær Hansen (eCKD)
commented
Two things come to my mind:
1) A stationary finish line camera: Just after banner to the side facing backwards. Great if zoomable.
2) A photo-finish screenshot:
a) A screenshot will be saved on riders own device when rider pass the line.
b) If option marked in Event Creation, a zip-file with every finishline photo is mail to the organizer. -
17 votesJan Langkjær Hansen (eCKD)
supported this idea
·
-
44 votesJan Langkjær Hansen (eCKD)
supported this idea
·
-
9 votesJan Langkjær Hansen (eCKD)
shared this idea
·
-
17 votesJan Langkjær Hansen (eCKD)
supported this idea
·
-
23 votesJan Langkjær Hansen (eCKD)
supported this idea
·
-
6 votesJan Langkjær Hansen (eCKD)
supported this idea
·
-
3 votesJan Langkjær Hansen (eCKD)
supported this idea
·
-
18 votes
Many thanks for your suggestion, and support for TrainingPeaks Virtual.
To confirm, the TrainingPeaks Virtual physics engine already takes into account the height and weight of riders, so - to use your example - you will already experience a higher drafting effect when sitting behind a larger rider.
All that is currently missing is the graphical representation of that.
Jan Langkjær Hansen (eCKD)
supported this idea
·
-
21 votesJan Langkjær Hansen (eCKD)
supported this idea
·
An error occurred while saving the comment Jan Langkjær Hansen (eCKD)
commented
Yes, this will be neccesary when you as a coach use TPVirtual in a studio and have set up an event for the class, - then when everyone is ready you should be able to start the event.
Motivation:
1) A coach in a studio might have a session of 2 hours doing perhaps 3 events. But the schedule for these are not fixed, so he need them all to be pre-defined but not started.
2) You are at a live event arranging races at the venue, but people never gets ready in time or the equipment fails to pair etc. Then you need to be able to start an event as you like.
The UX could be:
1) In Event Creation you choose this to be a "start-on-demand" event. No start time is set.
2) Then as an appointed "Ride-leader" (i.e. the organizer by default, see other RFE for "Ride-leader" functionality) you go to Event Organisation > Broadcast Stream or Check & Edit, where a "start event" button exist.
The event is now started with a count down timer of 45 minutes (or whatever is default for starting event-server before an event).
3) When the "Ride-leader" then either join the event or View through "Broadcast Stream" an option exist to "Overwrite/cancel/shorten countdown" which sets whatever countdown is at (e.g. 7 minutes and counting) to 75 seconds to allow pens to close etc.
-
3 votesJan Langkjær Hansen (eCKD)
shared this idea
·
Specification of Bot Levels.
I see a "straight forward" solution in Event Creation:
* Pen Type: Single Pen
Introduce two new options:
1) Fixed number of Bots: e.g. = 30
mutually exclusive with "Pen Size: e.g. = 30 riders"
2) Bot ARR Range: e.g. = [800–1500]
Bot Distribution Logic
The best use of the option is if "Fixed number of bots" is also selected, but it will work in both cases although vanishing effect if "Pen size" is used and more people are attending the event.
When pen begins to fill:
1) Base Distribution
Bots are initially added using a 'uniform distribution' across the specified ARR range.
2) Adaptive Adjustment
As human riders join:
* Bot density is 'slightly biased toward the ARR of participating humans (if humans ARR within bot ARR range)'
* The full bot ARR range is still represented
* Stronger and weaker bots remain present to maintain race structure
Use Cases
1) Single Pen Races (Human-focused)
In typically human-only events, weaker riders some time/often end up isolated and effectively doing an iTT.
Solution
* Set a lower bot range, e.g. = [600–900]
Effect
* Adds depth to the back of the field
* Provides riders with similar-level competition
* Reduces isolation without impacting front-end racing
2) Multi-Timeslot Races (e.g. Easter Eight Escapes)
Current behavior
* Strong human participation leads to stronger bots and faster races
* Weak participation leads to weaker bots and slower races
* Results vary significantly between timeslots
Solution
* Use a wider bot range, e.g. = [600–1600]
Effect
* Ensures presence of stronger bots regardless of human participation
* Reduces dependency on who shows up in each timeslot
* Creates more homogeneous and comparable races across all slots
This balances:
* Consistency across timeslots (fixed ARR range)
* Relevant competition within a race (adaptive density)
Result:
* Fairer comparisons between riders in different timeslots
* Improved experience for both strong and weaker participants