Reverse mode

[MCMic]

Hi!

I'm trying to see if I can implement a reverse mode in STK.
I tried just reversing the quads order in the vector, no the karts start backwards (that mean, in the right way for a reverse mode), but lap counting and kart ranking has gone crazy…
What are the other elements that I should alter?
I looked the checklap system but it does not seem way-dependent.

Also, on the math class track, the AI drives in the wall. But it's the only track on which I experienced this problem.

[ctdabomb]

were you trying to implement a certain track? or have it reverse in the actual STK program?

To reverse a certain track you go in the blender file for the track(you can probably get it from the media repository)(read the track makers guide if you haven't http://supertuxkart.sourceforge.net/Tra ... 7s_Guide_2 and http://supertuxkart.sourceforge.net/New_drivelines) then switch the direction of the vertices that show which way the karts go, and reverse the order of the checklines, and export.

If you are trying to do it from the STK program, that hasn't been implemented yet, but what probably/might happen is that they will do what was written above for each track.

Hope this was helpful,
CT. da'Bomb

[MCMic]

I'm trying to implement it in the program.

I already reverse the order of the driveline and the checklines, it does not seems like enough…

[ctdabomb]

you probably then maybe have to do it in the program and something in the track. but I am not completely sure

[Auria]

Hi!

I'm trying to see if I can implement a reverse mode in STK.
I tried just reversing the quads order in the vector, no the karts start backwards (that mean, in the right way for a reverse mode), but lap counting and kart ranking has gone crazy…
What are the other elements that I should alter?
I looked the checklap system but it does not seem way-dependent.

Also, on the math class track, the AI drives in the wall. But it's the only track on which I experienced this problem.

Hi, Joerg can tell you better than me since he's more familiar with drivelines than I am. But here are a few things to consider :

1) when multiple checklines are chained, the chaining order needs to be reversed. This is I guess best done directly in blender
2) we have code that goes through the driveline and sets on each quad what is the required checkline. Check that this code does indeed go the reverse way, otherwise quad requirements will be wrong (see QuadGraph::setChecklineRequirements)
3) for rankings, start at LinearWorld::getDistanceDownTrackForKart
4) run with the 2 flags described at http://supertuxkart.sourceforge.net/Art ... checklines so that you can see if there are problems with the checklines

Thanks for your interest!

[MCMic]

Thanks for all that information.
I had reversed the order of the quads but the not the direction of each of them, which was a first problem.
The other one is indeed the order of the checklines, which seems to be complicated to resolve.

And also I'm not sure about the two unconnected edges at the beginning of the track as explained here : http://supertuxkart.sourceforge.net/The ... line_Model

[Auria]

The 2 unconnected edges are used only in blender and are not present on the C++ side of STK as far as I know.

Regarding checklines, one thing is that many tracks have only 1 checkline and don't chain them, so you could start with this case, which is much easier since there is no chaining to reverse then (i.e. nothing to do for reverse mode)

[MCMic]

Ok, I got the reverse of the quads right, now it works on some tracks.
(As quads re-use points of previous quads, I have to wait for all quads to be load before reversing)

But I still got a problem on oliver math class:
It seems to me there is only one checkline so that should not be a problem. But the lapcounting does not work, and it seems the lapline is wrong placed (thought karts start from the right position)

See the screenshot below look at the red line position on the mini-map:

[MCMic]

Ok, here is the svn diff with a reverse mode.
http://pastebin.com/03GC70Bp

It does not work for all tracks, but most of them are OK.
I revert the checklines order so that mess with their indexes and (some of the) tracks with multiple checklines works.

Is a mode the best way to integrate reverse tracks?
Could a STK dev look at my patch and tell me if it's OK?
I think we could activate only some levels in reverse mode (the one that works), the same way only battle levels are available in battle mode, is that possible?

What do you guys think? (Either way I'm enjoying playing reverse tracks, it's almost like playing new tracks ^^)

[hiker]

1) when multiple checklines are chained, the chaining order needs to be reversed. This is I guess best done directly in blender

I see two options:

• STK already supports various graph, quad, and scene files (specified in one track.xml file), though that feature is not used atm. So you could just add code to the track exporter to reverse the drivelines and checkline dependencies etc.
• Do the reversal in stk.

In any way, the quads should probably not needed to be changed (I say 'should' since there might be some dependencies on the quad orientation, but if there is it should be fixable - one point might be the start position, which might be hardcoded to use the orientation of the connection from 0 to 1 in the first quad). The only change would be the actual quad graph (see driveline page on our wiki for details), i.e. reverse the order in which the quads are connected to each other. So you would basically have to revert the QuadGraph.

Then you also need to revert the dependencies of check lines.

Additionally we need a flag for each track to indicate which track can be driven in reverse (since some track can't).

2) we have code that goes through the driveline and sets on each quad what is the required checkline. Check that this code does indeed go the reverse way, otherwise quad requirements will be wrong (see QuadGraph::setChecklineRequirements)

That should sort itself out (if the code is correct) if you reverse the graph.

3) for rankings, start at LinearWorld::getDistanceDownTrackForKart

Again, this should work itself out if the quad graph is reversed.

Cheers,
Joerg

[hiker]

The 2 unconnected edges are used only in blender and are not present on the C++ side of STK as far as I know.

Correct.

Regarding checklines, one thing is that many tracks have only 1 checkline and don't chain them, so you could start with this case, which is much easier since there is no chaining to reverse then (i.e. nothing to do for reverse mode)

E.g. Zen-Garden has only one check line (plus the lap line).

Cheers,
Joerg

[hiker]

Ok, I got the reverse of the quads right, now it works on some tracks.
(As quads re-use points of previous quads, I have to wait for all quads to be load before reversing)

Yes and no, you should work on the quad graph, not the actual quads. But yes, you would first load everything, then modify the data (or modify while loading, not sure).

But I still got a problem on oliver math class:
It seems to me there is only one checkline so that should not be a problem. But the lapcounting does not work, and it seems the lapline is wrong placed

No, math class has 3 check line and the lap counting line.


Cheers,
Joerg

[hiker]

Ok, here is the svn diff with a reverse mode.
http://pastebin.com/03GC70Bp

Thanks, I'll have a closer look.

It does not work for all tracks, but most of them are OK.
I revert the checklines order so that mess with their indexes and (some of the) tracks with multiple checklines works.

That sounds great

Is a mode the best way to integrate reverse tracks?

Sorry, definitely not. This way you can't have all three race modes in reverse, you only get one. I'd say that in the last gui screen (where you select number of laps) you can also select 'reverse track' (if available for the selected track).

Could a STK dev look at my patch and tell me if it's OK?

It looks like you are just modifying the quads, not the quad graph (but admittedly based on a very quick look) - is that correct?

Also I noticed that you just completely commented out some (unrelated) functions (e.g. Track::loadCurves). If there is some reason for this this should certainly be a separate patch - bezier curve support was started in order to have a kind of camera zoom showing the track at start up or so, though it's not used atm).

I think we could activate only some levels in reverse mode (the one that works), the same way only battle levels are available in battle mode, is that possible?

It should be a per track flag added to the track.xml file.

What do you guys think? (Either way I'm enjoying playing reverse tracks, it's almost like playing new tracks ^^)

Thanks a lot for your contribution, I won't have time before Monday to look at it in more detail.

Cheers,
Joerg

[MCMic]

It does not work for all tracks, but most of them are OK.
I revert the checklines order so that mess with their indexes and (some of the) tracks with multiple checklines works.

That sounds great

I just change the order of checklines in the chekmanager, maybe I should also alter their "m_index" attribute, not sure if that's used.

Is a mode the best way to integrate reverse tracks?

Sorry, definitely not. This way you can't have all three race modes in reverse, you only get one. I'd say that in the last gui screen (where you select number of laps) you can also select 'reverse track' (if available for the selected track).

Ok, makes sense.
I'll see if I'm able to do this myself.

It looks like you are just modifying the quads, not the quad graph (but admittedly based on a very quick look) - is that correct?

Hum, I don't completely understand what you mean.
I revert quads themselves, so that they are facing backwards.
And I also revert the quadset order by reversing the order of the quads vector.

Also I noticed that you just completely commented out some (unrelated) functions (e.g. Track::loadCurves). If there is some reason for this this should certainly be a separate patch - bezier curve support was started in order to have a kind of camera zoom showing the track at start up or so, though it's not used atm).

That was just because at beginning I was confuse between quads and curves and I commented this function to be sure it did nothing.

It should be a per track flag added to the track.xml file.

Okay, thanks for the information.

[MCMic]

Ok, here is the new version of it : http://pastebin.com/2t8jskwV
Now there is a "revert" option that must be set to "Y" in track.xml if a track can be reversed, and then when choosing the number of laps, there is a checkbox allowing to revert the track.
It seems to work pretty well.
I failed to show any text next to the checkbox, despite calling setText on it, nothing shows in the GUI.

And if this patch is validated, the option should be added to be able to add reversed track in GPs.

[Auria]

Hi,

I will let Joerg review the patch since that's more his area.

Regarding the GUI, indeed checkboxes have no labels in an of themselves, so you need to add a Label widget next to the checkbox widget

[hiker]

Ok, here is the new version of it : http://pastebin.com/2t8jskwV

Great. I've created a new branch for this at supertuxkart.svn.sourceforge.net/svnroot/supertuxkart/main/branches/reverse_mode and also updated the corresponding ticket #503.

Now there is a "revert" option that must be set to "Y" in track.xml if a track can be reversed, and then when choosing the number of laps, there is a checkbox allowing to revert the track.
It seems to work pretty well.

That sounds good. Before I commit things a first few comments:

• It would save us some work if you could follow our coding style guides, esp. using "{' on a new line, and perhaps the maximum line length of 80 (admittedly there is a lot of code that does not adhere to the latter).
• If you add a new function parameter with a default, try to add it to the end (so that it's less likely that any other code might provide suddenly incorrect parameters), e.g.:
  

  {l Code}: {l Select All Code}

  -    void               loadTrackModel  (World* parent, unsigned int mode_id=0);
+    void               loadTrackModel  (World* parent,
+                                        bool revert_track = false,
+                                        unsigned int mode_id=0);


  
  You added the revert_track parameter before mode_id, risking that elsewhere where a mode_id is used, this might be mistaken as revert flag. Yes, the compiler should complain But better safe than sorry.

...

And if this patch is validated, the option should be added to be able to add reversed track in GPs.

Yes, indeed. But that can wait, it's easy enough to do once we have the other problems sorted out

I am about to finish a first part of your patch, which does all the GUI handling, storing reverse in the track object, but for now removed anything to do with the actual quads (well, I emptied a few functions). So at this stage the reverse-available flag can be set in tracks, and selected in the GUI, but nothing will actually happen. I'll commit this tomorrow, it needs a little bit of work still.

Reason is that I first want to clarify your reversion process:

• I don't understand why you have to revert the quads. Ideally this shouldn't matter, but there might be a bug ... or I might be missing something But I would prefer fixing any bugs we might have, than working around them
• I don't think that simply reversing the quads will work - as soon as you have a short-cut/alternative way, it won't work anymore. Also there are some (at least one ) internal data structure which will likely not be correct anymore (the bouncing ball has information about what path to use to reach a kart that might be on a short cut). The right way would be to reverse the graph, since it's the graph that determines the order in which the quads must be driven. If you need additional explanation here, let me know!
• Just reverting the order of the check-structures is not good enough, it will (most likely) work if we have a simple linear list of check-structures, but not all tracks have that. Have a look at math class, which has two additional check lines to the left and right of the start line (which are (iirc) necessary if a kart crosses the line to far to the left, but still under the bridge). I didn't try, but with your change it should be possible to cross the lap line on the very far left, then you can drive back, cross to the right, drive back, .... Let me know if you want some additional explanation of this.

Thanks a lot!
Joerg

[MCMic]

[*]It would save us some work if you could follow our coding style guides, esp. using "{' on a new line, and perhaps the maximum line length of 80 (admittedly there is a lot of code that does not adhere to the latter).

Oh, yeah, sorry about that, didn't cross my mind :-/

[*]If you add a new function parameter with a default, try to add it to the end (so that it's less likely that any other code might provide suddenly incorrect parameters), e.g.:

{l Code}: {l Select All Code}

-    void               loadTrackModel  (World* parent, unsigned int mode_id=0);
+    void               loadTrackModel  (World* parent,
+                                        bool revert_track = false,
+                                        unsigned int mode_id=0);


Hum, I searched in files and it seemed that this parameter was never used, that's why I added my parameter before it. (And if I add my parameter in the end, I'll have to fix the value of the other one when I call the function and want to set the value of my parameter.)

[*] I don't understand why you have to revert the quads. Ideally this shouldn't matter, but there might be a bug ... or I might be missing something But I would prefer fixing any bugs we might have, than working around them

If I just reverse the order of quads and not there direction, rank is wrong when two karts are on the same quad. (the kart that is behind the other is shown first in the kart list)

[*]I don't think that simply reversing the quads will work - as soon as you have a short-cut/alternative way, it won't work anymore. Also there are some (at least one ) internal data structure which will likely not be correct anymore (the bouncing ball has information about what path to use to reach a kart that might be on a short cut). The right way would be to reverse the graph, since it's the graph that determines the order in which the quads must be driven. If you need additional explanation here, let me know!

Yeah, I thought about these shortcut problems and things, but I don't know STK graph system enough to sort this issue out.

[*] Just reverting the order of the check-structures is not good enough, it will (most likely) work if we have a simple linear list of check-structures, but not all tracks have that. Have a look at math class, which has two additional check lines to the left and right of the start line (which are (iirc) necessary if a kart crosses the line to far to the left, but still under the bridge). I didn't try, but with your change it should be possible to cross the lap line on the very far left, then you can drive back, cross to the right, drive back, .... Let me know if you want some additional explanation of this.

I know reverting the order of the check-structures won't work for all tracks, but I did not got any better idea.
That's why there is this "revert_available" flag for tracks.
I think tracks that have a more complicated check system should have a second check system for the revert version of the track.

So, what should I do now?
I'm not sure if I'm familiar enough with STK code to improve the reverting that much.
And besides I'm not sure on which version of the code I should work on (I think I should switch to the svn branch you created and send patches for this version, but I'm not sure about that)

[hiker]

[*]It would save us some work if you could follow our coding style guides, esp. using "{' on a new line, and perhaps the maximum line length of 80 (admittedly there is a lot of code that does not adhere to the latter).

Oh, yeah, sorry about that, didn't cross my mind :-/

No big deal, just thought to point that out

[*]If you add a new function parameter with a default, try to add it to the end (so that it's less likely that any other code might provide suddenly incorrect parameters), e.g.:

{l Code}: {l Select All Code}

-    void               loadTrackModel  (World* parent, unsigned int mode_id=0);
+    void               loadTrackModel  (World* parent,
+                                        bool revert_track = false,
+                                        unsigned int mode_id=0);


Hum, I searched in files and it seemed that this parameter was never used, that's why I added my parameter before it. (And if I add my parameter in the end, I'll have to fix the value of the other one when I call the function and want to set the value of my parameter.)

Yes, you are right, it's not used atm - sorry, I missed that. The parameter is actually intended to allow you to select from various modes for one track. E.g. imagine a city track, where we might have 5 different ways of racing through them, but still only one main model. Or (my original intention) one mode could be the reverse mode (assuming that reverse driving is implemented as a different mode, and not automatically done as you have done it). But agreed, in this case your order was better.

[*] I don't understand why you have to revert the quads. Ideally this shouldn't matter, but there might be a bug ... or I might be missing something But I would prefer fixing any bugs we might have, than working around them

If I just reverse the order of quads and not there direction, rank is wrong when two karts are on the same quad. (the kart that is behind the other is shown first in the kart list)

Good point, I'll have a look at that.

[*]I don't think that simply reversing the quads will work - as soon as you have a short-cut/alternative way, it won't work anymore. Also there are some (at least one ) internal data structure which will likely not be correct anymore (the bouncing ball has information about what path to use to reach a kart that might be on a short cut). The right way would be to reverse the graph, since it's the graph that determines the order in which the quads must be driven. If you need additional explanation here, let me know!

Yeah, I thought about these shortcut problems and things, but I don't know STK graph system enough to sort this issue out.

[*] Just reverting the order of the check-structures is not good enough, it will (most likely) work if we have a simple linear list of check-structures, but not all tracks have that. Have a look at math class, which has two additional check lines to the left and right of the start line (which are (iirc) necessary if a kart crosses the line to far to the left, but still under the bridge). I didn't try, but with your change it should be possible to cross the lap line on the very far left, then you can drive back, cross to the right, drive back, .... Let me know if you want some additional explanation of this.

I know reverting the order of the check-structures won't work for all tracks, but I did not got any better idea.

Yes, this should be fixed to work with as many tracks as possible.

That's why there is this "revert_available" flag for tracks.

Well, I'd say that flag should only be used for tracks that can't be driven backwards, e.g. a track that has a jump in one direction that can't be driven the other way - iirc Crescent Crossing has that problem (when leaving the house).

I think tracks that have a more complicated check system should have a second check system for the revert version of the track.

I think it should be possible to automatically reverse the order. Perhaps we might want to store more information (iirc the check structures store the 'next' check structure, perhaps it would be easier if they would also store the previous structure). Not sure, we would need to study the code in more detail.

So, what should I do now?
I'm not sure if I'm familiar enough with STK code to improve the reverting that much.

There's nothing you can't learn The most important information is on the wiki:
http://supertuxkart.sourceforge.net/The ... line_Model
Ignore the blender details (the two 'antennas' to indicate start etc), but read the rest. Especially the section "Detailed concept: QuadGraph ", it even contains a reverse graph as an example.
It might be as simple as just reversing the order in which a graph in the edge is defined, e.g.:

{l Code}: {l Select All Code}

m_all_nodes[from]->addSuccessor(to);


could simply become:

{l Code}: {l Select All Code}

if(reverse)
    m_all_nodes[to]->addSuccessor(from);
else
    m_all_nodes[from]->addSuccessor(to);


So if a reverse flag is defined, just swap from and to (that's from quad_graph.cpp, around line 161, but there are a few more places that add a successor that need to be changed). But this is just a quick thought from me, so a good look at the code is still necessary.

And besides I'm not sure on which version of the code I should work on (I think I should switch to the svn branch you created and send patches for this version, but I'm not sure about that)

I created the branch hoping that you would want to continue working on that - I would then just give you write permission to that branch, and once you are done we merge this back into trunk. It's unlikely that there will be any conflicts with any of the other work happening atm - auria is busy with overworld, I am with the physics. If you are interested in finishing this, just email me your sourceforge account name (I assume that you are familiar with SVN).

I've applied the first half of your patch (r10767 ) - so it kind of sets up the infrastructure, but does not do any actual reversing. There should be some differences in naming, so expect a few conflicts when you try merging this with your current code. Best would probably be to go to a clean version of the branch, and then start working on the graph etc. You could start by fixing the GUI (following Auria's comment about adding a text to a check box), then looking at the graph structure and fixing this (which would allow the AIs to drive backwards, though lap counting wouldn't work), and in the final step then doing the checklines (which then enables proper lap counting).

Cheers,
Joerg

[MCMic]

Ok, I'll try to do a graph reversing system in the branch

[ctdabomb]

Well, I'd say that flag should only be used for tracks that can't be driven backwards, e.g. a track that has a jump in one direction that can't be driven the other way - iirc Crescent Crossing has that problem (when leaving the house).

in the next version Crescent Crossing will be replaced though, so that wont be an issue(though that is only one track and there might be more.)

[MCMic]

Hiker, I commited in the branch.
I tried the reversing graph thing.

It does not fully work, even after putting back the quad reversing. (the directions, not the order)
No surprise lap counting is buggy as checklines are messed up (I don't reverse checklines order as we said it's not a good solution).
But kart ranking does not work either. I can't figure out why…

[hiker]

Hiker, I commited in the branch.
I tried the reversing graph thing.

It does not fully work, even after putting back the quad reversing. (the directions, not the order)

Good start, it works as much as I was hoping for For example in math class the two branches (left/right of tree) work fine

No surprise lap counting is buggy as checklines are messed up (I don't reverse checklines order as we said it's not a good solution).
But kart ranking does not work either. I can't figure out why…

OK, I can have a look at that. I also noticed that I can't select the reverse-checkbox with mouse, only when I use up/down arrow can I navigate to it. More tomorrow.

Cheers,
Joerg

[MCMic]

Oh, really?
I had the problem of being unable to check the checkbox when the text I had added was in front of it, but I thought I managed to fix this, it works on my computer.

[hiker]

Oh, really?
I had the problem of being unable to check the checkbox when the text I had added was in front of it, but I thought I managed to fix this, it works on my computer.

OK, I might have a look on Linux.

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.

Cheers,
Joerg