FreeGameDev

Is there still an option to show drivelines in the config file for debugging? I see that show fps is still there, and maybe show checklines with --check-debug is new, but show drivelines seems to be missing.

I only ask because I'm having problems getting the drivelines to export correctly. For example: AI running into walls, laps being counted on the track below the start/finish line, etc. Maybe more debug features would help newcomers.

Thanks, and great work on 0.7

Hi,

try --track-debug ?

Ha, thanks!

I haven't heard of these debug features being offered before, so I won't be offended if they sound too difficult or not useful. Maybe extra debug features for drivelines in future releases could be:

Colored trails left behind AI karts so that you can see where they crash, take corners the wrong way, never use a shortcut, etc. without wasting time following them around.

Have markers left where the AI karts used a rescue from being stuck, driving off the track, etc.

how do i enable those debug features? is there a list somewhere?

i sometimes miss a camera fly mode. is this possible somehow?

horace {l Wrote}:how do i enable those debug features? is there a list somewhere?

i sometimes miss a camera fly mode. is this possible somehow?

If you issue, on a terminal,

supertuxkart --help

you will get a list of all terminal commands, including debug ones (if you have a debug build). However there are also other debug keys, and I don't think we have a list (Joerg?); for fly mode, in a debug build you may use key "i" to go up and "k" to go down. However this will not work with a release build you would download from our website
(Joerg: maybe we should somehow make these features available in release build too, for modellers to be able to use them without building from source...)

downer {l Wrote}:Colored trails left behind AI karts so that you can see where they crash, take corners the wrong way, never use a shortcut, etc. without wasting time following them around.

Have markers left where the AI karts used a rescue from being stuck, driving off the track, etc.

Both of which would need a good 'camera fly' mode or so. ATM auria implemented a 'fly' mode for karts (you need a debug compilation, then press (iirc) i and k to go up and down), but it's probably a bit too basic to get a good view. Note that you can play a profile game (--profile=-2 -N -2 indicates two laps),

AI rescue positions could just be printed to stdout, that might actually be easier to implement. And/or we could enable skid marks all the time as a start.

Cheers,
Joerg

Auria {l Wrote}:

horace {l Wrote}:how do i enable those debug features? is there a list somewhere?

i sometimes miss a camera fly mode. is this possible somehow?

If you issue, on a terminal,

supertuxkart --help

But that list does not include the debug features.

you will get a list of all terminal commands, including debug ones (if you have a debug build). However there are also other debug keys, and I don't think we have a list (Joerg?); for fly mode, in a debug build you may use key "i" to go up and "k" to go down. However this will not work with a release build you would download from our website
(Joerg: maybe we should somehow make these features available in release build too, for modellers to be able to use them without building from source...)

That's actually a difficult question. Many features are very useful, but others might be used to give away too much of the game (i.e. seeing the drivelines might tell you were hidden shortcuts are; checkline debug information can be used to find unwanted shortcuts). Also I can't distribute a normal debug executable for windows, since the MS VS redistributable package does not include the debug dlls (and I think even the license might prevent me from doing that).

Perhaps we should make a special 'for artists' version, replacing some #ifdef DEBUG with #ifdef ARTIST_VERSION or so. That would at least solve the technical difficulties of how to distribute the binary (on windows).

Then perhaps offer the artists-executables (only) as additional downloads, so at least the majority of players won't get it automatically?

Cheers,
Joerg

hiker {l Wrote}:...

That's actually a difficult question. Many features are very useful, but others might be used to give away too much of the game (i.e. seeing the drivelines might tell you were hidden shortcuts are; checkline debug information can be used to find unwanted shortcuts). Also I can't distribute a normal debug executable for windows, since the MS VS redistributable package does not include the debug dlls (and I think even the license might prevent me from doing that).

Perhaps we should make a special 'for artists' version, replacing some #ifdef DEBUG with #ifdef ARTIST_VERSION or so. That would at least solve the technical difficulties of how to distribute the binary (on windows).

Maybe you can force define "DEBUG" symbol even you're using release configuration or you can also remain some debug features in release version, but the user needs "--debug" command line to activate them ...

hiker {l Wrote}:AI rescue positions could just be printed to stdout, that might actually be easier to implement. And/or we could enable skid marks all the time as a start.

Yes, both sound like a good start. Doesn't have to be fancy, just something left behind so that I don't have to run the race over and over to tweak each corner.

Joerg: maybe we could have a special config option to enable these features; they would be disabled by default. Then our wiki pages could explain artists how to enable them. So the average user won't accidentally stumble on them

acme_pjz {l Wrote}:Maybe you can force define "DEBUG" symbol even you're using release configuration or you can also remain some debug features in release version, but the user needs "--debug" command line to activate them ...

I want to be able to add more 'invasive' code if necessary with DEBUG. One example is that we have a lot of additional tests happening around race rank updates. This is meant mostly to detect early on any problems with lap counting etc. This kind of code should probably not be enabled in a build for artists (e.g. it might have a performance impact, or print some cryptic debug output). So I'd say to wrap all command line debug options into #ifdef ARTISTS or so, which leaves us free to use DEBUG for more 'internal' stuff. It's probably a bit too late for the 0.7, but it would be easy enough to make an artist version after the release (probably based on SVN, since we already have additional features in svn, like billboards).

Cheers,
Joerg