FreeGameDev

Can anybody explain, what is going on with Adiumy and Beagle in this video?

https://www.youtube.com/watch?v=XK3hfSztZmU STK 8.0.1 - Green Hill track

Error log:
...
[warn ] physics: Kart at (39.363750 -16.871273 -64.079742) can not be dropped.
[warn ] physics: Kart at (-54.444500 -16.894531 66.315750) can not be dropped.
[warn ] physics: Kart at (46.723999 -16.883774 -66.867996) can not be dropped.
[warn ] physics: Kart at (-60.440750 -16.894030 64.235245) can not be dropped.
...

It seems like they got stuck in a rescue loop, and when rescuing it can't find a suitable place to drop them (probably drivelines are too low in relation to the ground there).

Arthur {l Wrote}:It seems like they got stuck in a rescue loop, and when rescuing it can't find a suitable place to drop them (probably drivelines are too low in relation to the ground there).

Yes, the drivelines are completely wrong. I'd say we should never have allowed this to go life

Cheers,
Joerg

Well addons generally being of dubious quality is not much we can do about unless we start testing more rigirously and giving specific guidelines on what level of quality we want there. More work than benefit IMHO - users will just have to realize addons is not officially supported content.

Arthur {l Wrote}:Well addons generally being of dubious quality is not much we can do about unless we start testing more rigirously and giving specific guidelines on what level of quality we want there. More work than benefit IMHO - users will just have to realize addons is not officially supported content.

STK already does a lot of tests (if started with --track-debug). E.g. for this track I get:

{l Code}: {l Select All Code}

[warn   ] physics: Kart at (55.610748 3.355978 -5.424000) can not be dropped.
[warn   ] physics: Kart at (53.489250 4.062727 -11.418249) is too high above ground at (53.489250 -12.196415 -11.418249)


Over 1000(!) lines of warnings all in all - I think we can expect that any track we approve would pass a --track-debug run without warnings. Track designers can easily run this test themselves (we should of course document our criteria for track acceptance and what designers should do to test this beforehand).

Cheers,
Joerg

Maybe it should give in-game errors as well then, so track designers get them whether they run from terminal or not? That would make it a higher incentive to fix.

This is probably because STK used to be much less strict than it is now, so probably at the time it was approved it worked well

Arthur {l Wrote}:Maybe it should give in-game errors as well then, so track designers get them whether they run from terminal or not? That would make it a higher incentive to fix.

Makes sense. All the time, or only on request? If the latter, then command line option, or perhaps add it to the debug menu? Or automatically enable this whenever you run with artist debug mode?

Cheers,
joerg

Probably the last option: enable this when run in artist debug mode. Not sure if we want to confuse users with those messages since they may have no idea what they mean or what causes them.