I am working on building a track where the rider proceeds up ramps and grades both forward (through normal riding) and backwards through downhill coasting. The problem I am having is with checkpoints. Since the track runs above and below itself on the y-axis, later checkpoints (in race progression) are positioned closer to the starting line (x-axis) than earlier checkpoints. These checkpoints either trigger prematurely, or do not trigger at all. This makes it very difficult to set checkpoints following difficult obstacles. Is there a way to either limit the trigger points of the individual checkpoints to a smaller area (other than driving line) or to trigger the checkpoints using "manual" in game triggers so that the checkpoints trigger and function in line with the planned race progression versus delta from the starting line? I have attempted multiple methods including turning the checkpoints on and off, but nothing seems to get me the results I'm looking for. Any help would be appreciated. Thanks!
I'm not sure if Evolution has changed anything as far as this goes, but in HD there was no way to do what you're talking about since each checkpoint had to be at a greater value on the X axis than it's predecessor. Even with trigger systems and the like, there was just no way around it that I ever found or heard of. Since EVO has a curved driving line, things may be different. The first thing that comes to mind for me is to place a very small curve in the line between the last checkpoint on the left to right portion of the driving line and all of the checkpoints that would be at a lesser value to it on the X axis. In doing this, your checkpoints for the backward coasting portion of your track would be at a different value on the Z axis, which may possibly allow what your'e looking for. It seems like that's what you're essentially doing when creating a 90 degree curve in the driving line and lining up a bunch of checkpoints along the new line. Their placement on the Z axis would then be the only thing differentiating them from one another so perhaps doing so in your case would work as well. I hope this all made sense. I find myself wanting to draw a picture to illustrate my point but hopefully you get what I'm saying.
You could do an inventive thing such as make a trigger area that way if rider faults, reset him to a specific checkpoint. Under player event tool.
Here's an ugly solution: duplicate the track. When the rider reaches the top, use an event to set his position on the track to the duplicated incline. The duplicated incline can have its own checkpoints that will activate as normal.
Obviously, this requires that you duplicate any changes you make to the track if you want it identical - hence it being ugly. Camera interpolation may cause this to look odd, though it might not if you have it set to immediately interpolate during this switch.
How would you instantly teleport the bike to the other position? I don't think I've seen an event which can do that.Originally Posted by Akaji
Am I mistaken in thinking there's a way to set an object to a specific position on the driving line? I may be talking out my arse here.
IIRC Object Position events can't target the rider or bike, but if you glued an object to either then you could attach the OP event to that object... if you can glue things to the rider or bike.
What the hell do I know, the first thing I do when I create a track is disable the bike and rider and create something more interesting to control.![]()
Found it -- Player Event. See here: http://www.youtube.com/watch?v=ifeam..._video#t=4m37s
Aha, I see, thanks. I wish object position would work too, but that's much better than nothing.
OK... An update.... I have a solution. Although it is not perfect, I am adjusting and I am getting much closer. Here's what I've done so far for a partial solution:
1. Create multiple square area triggers along the driving line following the checkpoint that should have activated. These should be close enough together to ensure a crash is captured. Also the triggers need to have the "Disable after Hit" checkbox de-selected.
2. Create a Player condition filter using the "Riding" option/variation
3. Create a player event "Reset to Checkpoint". For this, keep the physics box checked.
4. Link all of the individual triggers to the filter on-hit
5. Link the filter to the event on the "False" condition.
Results: Captures rider bailouts and crashes with an immediate reset to the selected checkpoint. For troubleshooting purposes, I placed a sign next to each checkpoint with the checkpoint number. Would be nice to have this on the checkpoint properties but.... One drawback I noticed so far is that the reset is immediate without watching the full crash, but oh well.. Better race times for all! The other MAJOR issue with this is that it seems to count the rider as not riding when in the air (which prematurely fires the trigger). I will play around with this to see if there is another filter that can capture this better.
I will post again on this thread if I come up with a better solution, and I will also post the track name when I'm finished if anyone wants to see the results. Thanks for the replies so far! Happy riding.
All, I have developed a much better permanent solution to this problem. It meets the needs MUCH better than the previous solution. It is a bit complex to build, but here is a step-by-step process.
1. Create an area trigger for each checkpoint immediately after you pass the checkpoint
2. Create a variable data source with a default value of 0 (ensure the reset at checkpoint restart is de-selected.
3. Create a set value event for each checkpoint in the order you want them triggered. Set the value to the race progression vs. the actual index of the checkpoint.
4. Create a player event, reset to checkpoint, for each checkpoint. These will need to correspond to the actual checkpoint index value for each checkpoint.
5. Create a generic filter for each checkpoint where the Variable data source equals the number of the checkpoint you want to trigger.
6. Create an impulse splitter
7. Create 2 player event triggers. One for crash, the other for bailout.
8. Link the crash and bailout events to the impulse splitter
7. Link the impulse splitter to each of the filters.
No sweat right
Results: When configured in this way, the checkpoints will function in the order you want them to. Reset is still immediate, without full crashes, but what can you do...
Caveat: Due to limitations in the impulse splitter, this will only work for up to 8 checkpoints, so it's best to allow for normal checkpoint control on those checkpoints that function normally, but you still need to reset the value to ensure the filter for the "bad" checkpoint don't still trigger. I am still in the testing phase, but this looks like it is a viable solution. For you geeks out there, this solution functions similar to a CASE statement in code. Could be useful for other things.. Happy riding!