Reverse mode

[MCMic]

Re the ordering of karts: the distance from start computation (for each graph node) is not correct anymore, I'll fix that. This his causes the karts to change positions more or less randomly every time a new quad is entered.

Any idea why it's not right anymore?
It was ok when I was reversing the order of the quads the brutal way (reversing the vector).

[hiker]

Re the ordering of karts: the distance from start computation (for each graph node) is not correct anymore, I'll fix that. This his causes the karts to change positions more or less randomly every time a new quad is entered.

Any idea why it's not right anymore?
It was ok when I was reversing the order of the quads the brutal way (reversing the vector).

The old 'distance from track' computation (which determines for each graph node how far it is away when following the track from the start line) was incorrect, it assumed that the graph nodes were added in the same order in which they are connected. Since this was not the case anymore, it failed.

When you reversed the order of quads, your code still fulfilled that condition.

I've fixed the code (hopefully) to work correctly in r10819 (and removed some assumption about quad 0 always being the first quad of a new lap). I had only time to do some quick tests, but it looks like all karts are now being in the right order during a race (at least till they cross the lap counting line ). I'll browse through the code to see if there are any more (now incorrect) assumptions.

Now, next step would be to reverse the order of the check structures. Are you going to look at that?

Cheers,
Joerg

[MCMic]

Hum, I don't know how to handle the check structure thing.
Only Check-Lines dependency order should be reverted I think (other checks does not seem lap related).
But that means instead of adding structures to "m_check_structures_to_change_state", we would need to add ourselves in the same attribute of these structures, but at loading we don't know if they are loaded yet, so this reversal needs to be done once all check structures are loaded, that seems kind of complicated…

Thanks for you help on this

[hiker]

Hi,

I did a bit more cleanup (removed reversing the quads, instead adjusted only the data structure in the graph node that were dependent on the orientation), and also improved the GUI issue (see ticket #571 for outstanding issues, since it looks pretty bad, at least at 800x600).

Hum, I don't know how to handle the check structure thing.
Only Check-Lines dependency order should be reverted I think (other checks does not seem lap related).

Best is to work on all check structures (which is all done in the CheckStructure base class anyway). Atm (afaik) we only use CT_NEW_LAP and CT_ACTIVATE, but it's probably no more effort and it would be future proof.

But that means instead of adding structures to "m_check_structures_to_change_state", we would need to add ourselves in the same attribute of these structures, but at loading we don't know if they are loaded yet, so this reversal needs to be done once all check structures are loaded, that seems kind of complicated…

I agree, it can't simply be done in the CheckStructure. I see two options:

• First read the check structure, and create 'empty' check structures only (probably same-id can still be read, since it should be unaffected from reversing them, but ignore other-ids in the first pass). Then loop again over all check structure infos in the XML file, and reverse the order (i.e. check structure X has y0, y1, ... as other-ids, add X as other-ids (successors) to y0, y1, ...).
• After reading the check structure, use this info to create a new array of check structures, and going through all data in the original structure, set up the new structure in the reverse order. Then free the original data structure, and use the new data structure in the check manager.

The first option appears to be easier, now that I have written that, but I didn't study the code too much.

Does this help?

Cheers,
Joerg

[MCMic]

Hi,

I did a bit more cleanup (removed reversing the quads, instead adjusted only the data structure in the graph node that were dependent on the orientation), and also improved the GUI issue (see ticket #571 for outstanding issues, since it looks pretty bad, at least at 800x600).

It seems you did not commit in the branch I'm working on.

I'll see if I success in reverting the check structures.

[hiker]

Hi,

I did a bit more cleanup (removed reversing the quads, instead adjusted only the data structure in the graph node that were dependent on the orientation), and also improved the GUI issue (see ticket #571 for outstanding issues, since it looks pretty bad, at least at 800x600).

It seems you did not commit in the branch I'm working on.

See r10822 and 10823, both done on the reverse_mode branch.

I'll see if I success in reverting the check structures.

Great!

Cheers,
Joerg

[MCMic]

Ok, reversing of check structures is now working!

The only problem left is that karts start after the finish line instead of before, so they have to do one more lap, the first one is not counted.
The track being reversed, karts start position should be the other side of the lap line.

How are these positions calculated?

PS: Also, look at the code, I'm not sure you'll like everything in it. I was kind of bugged that m_check_structure_to_change_state was a vector of int and not unsigned int, it seems that's because the xml reading needs a vector of int. I also had to put CheckManager as a friend class of CheckStructure.

[hiker]

Ok, reversing of check structures is now working!

Great news!

The only problem left is that karts start after the finish line instead of before, so they have to do one more lap, the first one is not counted.
The track being reversed, karts start position should be the other side of the lap line.

This is fixed in r10831 - I accidentally started the 'distance from start' calculation in reverse mode with the wrong node (and the wrap around of distance from start triggers the new lap detection).

There is one additional thing which we have to check: auria added some code to better determine the rescue position, which I am not really familiar with. I'll ask her tomorrow (there is at least one hardcoded test for graph node 0 in it, which might not be right anymore).

How are these positions calculated?

If you are still interested, see QuadGraph::setDefaultStartPositions, there's some comments explaining the details.

PS: Also, look at the code, I'm not sure you'll like everything in it. I was kind of bugged that m_check_structure_to_change_state was a vector of int and not unsigned int, it seems that's because the xml reading needs a vector of int. I also had to put CheckManager as a friend class of CheckStructure.

OK, I'll have a look.

We are close to merging everything back to trunk. Auria has already improved the design of the track-info dialog (its layout is now specified in an XML file, not hard coded anymore), so merging those two together is necessary, but that's not too bad.

Stay tuned, I'll update this thread

Thanks!
Joerg

[MCMic]

Great news, thanks.

About start positions, I'm really not familiar with this, but I think that the code compute default positions based on the track, but the track might also indicates some start positions in the xml, right? In this case, We'll have a problem in reverse mode no?

Also, we have a problem with best time : reverse mode time should be separated, not mixed with normal mode time. (Some tracks might be easier/harder in reverse mode)
(That means in track_info_dialog we need to update the best time showns when (un)checking the reverse mode)

Oh, and I'd like reverse mode to be something that the user unlock thanks to a challenge, would that be easy to implement?

[asciimonster]

Oh, and I'd like reverse mode to be something that the user unlock thanks to a challenge, would that be easy to implement?

And track designers need to get an option ("reversible" checkbox?) in the blender plugin. Some tracks feature jumps, which prevent the racks from being driven backwards...

[Auria]

If we get to support reverse, IMO all tracks should support it.

We could make some driveline segments be conditional on driving direction; if you drive normal driveline X is activated, if you drive reverse then it's driveline Y

[hiker]

If we get to support reverse, IMO all tracks should support it.

Ideally yes, but I wouldn't reject a nice track with (say) a nice jump, just because it only works in one direction. Minigolf and Crescent Crossing are tracks with that problem (though admittedly they can easily be fixed), but potentially having nice jumps would make it (close to) impossible to reverse tracks.

We could make some driveline segments be conditional on driving direction; if you drive normal driveline X is activated, if you drive reverse then it's driveline Y

Yes, though I'd say we wait till we actually have a track which has that problem. I'd guess for the foreseeable future enabling/disabling this for a complete track would be the only thing we need (i.e. anything making a track so special that it can't be driven in reverse will likely be on a 'main' part of the track ).

Cheers,
Joerg

[MCMic]

It seems there is something wrong with the end race camera, it shows me the back of the characters.

[hiker]

Hi,

fyi: I am currently working on fixing rescue (which is depends on checkline ordering, and might not be entirely correct).

It seems there is something wrong with the end race camera, it shows me the back of the characters.

Good point - the order of end camera is (iirc) determined in the track exporter, and needs to be reversed as well (or Camera::checkForNextEndCamera should just check all cameras instead of only the next one). Do you want to have a look at that? Otherwise I'll do it once I've fixed rescue.

Cheers,
Joerg

[hiker]

It seems there is something wrong with the end race camera, it shows me the back of the characters.

Good point - the order of end camera is (iirc) determined in the track exporter, and needs to be reversed as well (or Camera::checkForNextEndCamera should just check all cameras instead of only the next one). Do you want to have a look at that? Otherwise I'll do it once I've fixed rescue.

OK, I've fixed most of the issues now - rescuing and end camera. There is a minor bug (in certain circumstances there is a one-frame jump in the camera when switching to a static-follow-kart camera, but I think that's not related to reverse). Once I am done with that I'll merge everything back to trunk

Thanks a lot for your help - any intentions of doing more? Mirroring tracks perhaps ?

Cheers,
Joerg

[MCMic]

Great news, thanks.

About start positions, I'm really not familiar with this, but I think that the code compute default positions based on the track, but the track might also indicates some start positions in the xml, right? In this case, We'll have a problem in reverse mode no?

Also, we have a problem with best time : reverse mode time should be separated, not mixed with normal mode time. (Some tracks might be easier/harder in reverse mode)
(That means in track_info_dialog we need to update the best time showns when (un)checking the reverse mode)

Oh, and I'd like reverse mode to be something that the user unlock thanks to a challenge, would that be easy to implement?

Hiker : you did not answer any of the things I said in this post, what about best times?

[hiker]

Hiker : you did not answer any of the things I said in this post, what about best times?

Good point, I've just added this to the todo list in #503 (wish trac would have hierarchical tickets *sigh*). Do you want to have a look at that? Basically adding a new field to highscores which indicates the direction.

Cheers,
Joerg

[MCMic]

I'll try and look into it. I won't have a lot of spare time this week though…

[hiker]

Hi,

just a quick update: wardje has offered to look into this (see https://sourceforge.net/apps/trac/super ... ticket/587 for the trac ticket).

Cheers,
Joerg

[MCMic]

That's good news, I was busy with school projects and now I'm beginning an internship that might also take most of my time.

[hiker]

That's good news, I was busy with school projects and now I'm beginning an internship that might also take most of my time.

Sure, no problem. I just wanted to make sure there are not two people working on it at the same time And besides, this is already finished and implemented, so we have (nearly fully) featured reverse track support now.

Thanks a lot to MCMic and Wardje!
Joerg

[ctdabomb]

according to bug #583, some of the tracks had issues:
Fort Magma: fixed I am pretty sure
Amazonian Journey: fixed unless there is something wrong with the drivelines. I cant test without SVN
Old Mine: to confusing
Blackhill Mansion: letting samuncle fix
Tux Tollway: clearer with some signs and cones

[Auria]

Hi,

thanks for your efforts, I applied the changes to jungle Now I think in the jungle we still need to better show the user the right way in reverse mode, maybe there could be a big arrow on the vertical wall under the jump.

For the other tracks I think more work is needed : In Tux Tollway, the place indicated by the screenshot in the ticket is also a little ambiguous, more cones and bigger signs could help; also when you are near the gas station and approach the dead-end, there could be cones and a bigger sign pointing right. I think it's still confusing

In fort magma, I find I still jump quite a bit too much in tunnel

[ctdabomb]

I wasn't really sure which bump it was. which one is it?
I can make the signs and cones and bigger and better.
I can try in the jungle, but I am not really sure where to get a texture for a jungle sign/what it should look like.
(yay! finally something I did was applied!!!! )

[Auria]

in fort magma, pretty much every platform in the tunnel causes a bump, I think they should be smoothed out (this is worse in reverse but to be honest I think it wouldn't hurt to smooth them in forward driving too)