The music in the race doesn't loop.
I run a long race and found that the music started again when it reached its end. What's wrong?
Additionally, when you exit a race and go into another one, the music keeps playing from the same spot.
The racing music seems to start always from the beginning. Do you mean the menu music between the races?
If you do a trick and Tux lands on his head, he will continue to slide that way until you do another trick.
Yes, that's a drolly bug. I've reimplemented the tricks in a rush. For me, it's not important
enough to spend several hours for bugfixing. I think, at the moment it makes more sense to lock this option.
Also, would it be possible to implement "make clean" functionality similar to ETR 0.4
I guess you mean the option of automake, needed for deinstallation. In my opinion, this requires a full build system to undo the 'make install'.
And now some explanations about the doc:
Why does [env] fall back to "tuxracer" as opposed to "etr"
That can be mistakable, indeed. First: An environment consists of 2 parts, the location (representated by the subject of the skybox) and the light conditions (sunny, foggy ..., represented by the light adjustments in light.lst AND the skybox). The light conditions are free selectable in training mode or by the event.lst, but the locations are tightly assigned to the courses. That makes sense and it means that a course creator has to decide which location is suitable for his course. An he has to enter it in course.dim.
Currently there are 2 locations (= sets of skyboxes): tuxracer and etr. These are work indentifiers, I think the locations should get more expressive names. The fall-back is another specialty of the new code with the SP library. SP is less syntax sensible than Tcl. In the case that an entry in a configuration file is absent or wrong the program falls back to a default value (not always but very often). For example, if there is no location defined in course.dim the program assumes the default location 'tuxracer'. Advantages: less errors and you needn't rework all existing courses. Again: this is only one example, there are lot of situations that follow this sample.
For the sake of consistency, can ETR recognize and items.png?
Items.png? I guess, you mean trees.png. Yes! ETR can read both, an items list and the bitmpap 'trees.png'. For future usage the list is better since it allows to define a lot of object properties, for each particular object. So it's unavoidable to change to this procedure. An the other hand, for keeping consistency and (also important) for fast locating a lot of objects on the course, the bitmap is still advantageous. That's the reason why old ETR courses can be loaded without an items list. ETR parses the trees.png and generates an items list that is used from then on. The items.lst has priority. Nevertheless it's a good idea to keep both in the course directory.
...the y-position is 0.0. This value is not used since it can be exactly calculated when the course is loaded." is rather confusing, I don't know what you mean by that.
Yes, that might be confusing, especially for people who didn't work on the code. Each position needs 3 params: x, y and z, where y is the height coordinate. I think, that's clear. In commercial Tuxracer you have to define all position coordinates in the items list. x and z are rather simple, but locating an object exactly on the surface is extremely difficult. In most cases the object dives into the snow or is flying up in the air, often unvisible. There is only one reasonable way, the height (y) must be calculated by the program itself. The program can do it very exactly at all points of the course. The concerned function is 'find_y_coord'. So it's unnecessary to enter an y coordinate in items.lst, the value can be 0 or any other number, it's not read. With this in mind we can understand that the information, stored in the x/z array of a bitmap like trees.png, is sufficient for the localization in 3 dimensions.
But is there a reason to calculate the y coordinates at all starts? Yes, there is. You may want to move an object by changing the x or z values. The program doesn't know that - so the height can get wrong. Another question: Why not use a 2D vector in items.lst? Possible but hard to accept: first value is x, second is y (height) ... that becomes second nature. Additionally there might be a reasonable applicatin for the middle number. It can be used as relative coordinate. 0.0 means that the object is placed on the surface, -0.2 would mean that is is located a bit deeper (flags !!!), independent of the absolute height at the point.
Wow, again a long explanation. But I think, all this should be clear. So ask, ask ...
BTW: The translation code seems to work. I couldn't rework all language files yet. They must be reworked since they use SP instead of Tcl. For testing you can try English (default language, see above), French, German and Polish (the latter to test some 'special' letters). Finally the translators must work again.