Objects set to reset player don't always reset player

[stkAnon]

I made a track in which a plane was supposed to rise up through the ground and reset the player. It didn't work. Instead, the player was just pushed upwards by the plane.

It seems that there has to be some kind of a collision for the rescue to happen, as show in this video (which is not of the test I described).

EDIT: Tested on 2a473a5, due to everything later being broken for me.

[auriamg]

You can give a link to where the track can be downloaded?

[stkAnon]

The track in the video can be downloaded here. The plane rises at slightly over 2:00.

Note however that the plane doesn't rise smoothly in this track; it just teleports from below the track to slightly above. I didn't save the track where the plane rises gradually, as it was only a test. It should be pretty simple to make a test with two planes where one is set to reset the kart and rise up, though.

[auriamg]

Can you describe the problem a bit better? Which part of the track should reset but doesn't? Also, sharing the blend file would help

[stkAnon]

At 2 minutes into the game, a plane is supposed to pop up to 0.1 meters above the ground from 0.1 meters below. This plane is set to reset the player in both object and material settings. The problem is that nothing happens.

To find out what was happening, I took another plane, which started slightly above the track and rose to two meters above from 1:15 to 2:00, and set it to reset the player. When I tested the modified map, I found that instead of resetting the player's kart, the plane would just push it up.

I've actually just uploaded the source files of this track for samuncle, so you can download them here. The plane that pops from slightly below to slightly above the track is in layer 10 ("0" key) of both 1_32.blend and 1_20.blend, and you can recreate the test I did with the rising plane by changing one of the objects on either layer 6 ("6" key) or 16 ("alt-6") of 1_20.blend to reset the player.

Note that you'll probably have to copy "temple 14_8_21/assets/library/stklib_lowAnimGrass_a" into "stk-assets/library" for the track to work. You might also have to extract the entire archive, instead of just the .blend files.

[hiker]

I think the issue is that we have two kind of resets: one that is triggered on collision of the chassis with an object, the second one on driving on a specific terrain (i.e. texture). In your case, with the plane slowly raising, there won't be a collision with the plane (the kart chassis hovers over the terrain, it never touches it).

To make your idea work you need to set the material of the plane to trigger a reset (see the SuperTuxKart image properties, interactions: reset (on drive)).

I couldn't test it (your latest version crash stk for me atm, but that's an issue with my graphics card), so please let us know if this works as expected.

[stkAnon]

I checked the file, and the plane was set to both reset on drive in the material properties and reset on collision in object properties. It wasn't set to reset on collision in material properties though, so I enabled that.

With it enabled, the behaviour is almost exactly the same (i.e. the kart doesn't get rescued as it should), with only one small exception. Before, crashing into the barrier at the edge of the track had a small chance of causing a rescue. Now, it happens every time.

[hiker]

Could you upload the exported track and the modified .blend? I have the package you mentioned above, so I guess I have all textures etc. I just want to make sure we are talking about the same things ;) (e.g. I had an older exporter, and your loxXYZ changes were exported as scaleXYZ, which is not supported from STK).

[stkAnon]

Here's the exported track.

And here's a .blend file which should be the same as the one with all reset options enabled (I closed that one without saving).

[hiker]

Just as a quick update: I think I have found the problem (the raycast detecting the terrain is only done against the main track mesh, not against all physical bodies like your plane. The wheels on the other hand test collision against anything). Fixing this is not entirely trivial, since only the main track mesh (atm) stores the texture information, not a physical object.

[hiker]

I have just pushed a first version to improve the handling of driving on physical bodies (68e45db). I'll do some more refactoring, and have to update the exporter. But if you want to test it now:

• you need to apply scaling to the meshes that move.I am also not convinced that modifying the scale will actually work (for physical objects), I haven't tested it.
• mark the material to trigger a reset.
• after exporting, add 'driveable="yes"' to the object in the scene.xml file, e.g.:

  <object id="waterdeath" type="animation" xyz="0.00 -0.10 0.00" hpr="0.0 -0.0 0.0" 
          scale="1.00 1.00 1.00" interaction="static" shape="exact" model="waterdeath.b3d"
          reset="y" skeletal-animation="false" driveable="yes">
     <curve channel="LocY" interpolation="linear" extend="cyclic">
     ...

I'll update this ticket as I get more work done, but feedback would be appreciated.

[hiker]

I added a new 'driveable' property to the exporter in r15569. Please let me know how you go.

[stkAnon]

My build failed with the following message(s):

make[2]: *** [CMakeFiles/supertuxkart.dir/src/main.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
In file included from /home/username/bin/stk/git/stk-code/src/tinygettext/tinygettext.hpp:22:0,
                 from /home/username/bin/stk/git/stk-code/src/utils/translation.hpp:27,
                 from /home/username/bin/stk/git/stk-code/src/race/grand_prix_data.hpp:27,
                 from /home/username/bin/stk/git/stk-code/src/race/race_manager.hpp:34,
                 from /home/username/bin/stk/git/stk-code/src/challenges/story_mode_status.hpp:22,
                 from /home/username/bin/stk/git/stk-code/src/config/player_profile.hpp:22,
                 from /home/username/bin/stk/git/stk-code/src/config/player_manager.hpp:24,
                 from /home/username/bin/stk/git/stk-code/src/online/online_profile.cpp:21:
/home/username/bin/stk/git/stk-code/src/tinygettext/dictionary_manager.hpp:92:59: warning: ‘auto_ptr’ is deprecated (declared at /usr/include/c++/4.8.3/backward/auto_ptr.h:87) [-Wdeprecated-declarations]
   void set_filesystem(std::auto_ptr<FileSystem> filesystem);
                                                           ^
make[1]: *** [CMakeFiles/supertuxkart.dir/all] Error 2
make: *** [all] Error 2

This actually happens with all revisions less than a couple days old. Any idea what's causing it? I think 44d50aa is the most revision I tried that worked.

Thanks.

[hiker]

This is only a warning message (which I get as well), it does not cause the error message. Could you paste the actual error message (don't run make with -j, then the last message should be the actual error).

[stkAnon]

I think this is it:

In file included from /home/username/bin/stk/git/stk-code/src/graphics/shaders.hpp:24:0,
                 from /home/username/bin/stk/git/stk-code/src/graphics/irr_driver.hpp:40,
                 from /home/username/bin/stk/git/stk-code/src/main.cpp:155:
/home/username/bin/stk/git/stk-code/src/graphics/shaders_util.hpp: In member function ‘void TextureRead<tp>::SetTextureHandles(const std::vector<long unsigned int>&)’:
/home/username/bin/stk/git/stk-code/src/graphics/shaders_util.hpp:431:67: error: there are no arguments to ‘glUniformHandleui64ARB’ that depend on a template parameter, so a declaration of ‘glUniformHandleui64ARB’ must be available [-fpermissive]
                 glUniformHandleui64ARB(TextureLocation[i], args[i]);
                                                                   ^
/home/username/bin/stk/git/stk-code/src/graphics/shaders_util.hpp:431:67: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)
make[2]: *** [CMakeFiles/supertuxkart.dir/src/main.cpp.o] Error 1
make[1]: *** [CMakeFiles/supertuxkart.dir/all] Error 2
make: *** [all] Error 2

[hiker]

I assume you have libglew 1.9 (or older) installed? You need libglew 1.10 to compile STK now :(

[stkAnon]

Aw. I don't suppose there's any way to get that on Fedora 20 without manually installing it?

Anyway, I noticed that the example scene.xml you gave uses drivable="yes", while the exporter uses drivable="true".

[hiker]

For my OpenSuse I had to find a different repository, from which I could install 1.10. I don't know much about fedora, but googling for 'fedora glew 1.10' returned (among others):

https://pkgs.fedoraproject.org/repo/pkgs/glew/glew-1.10.0.tgz/

http://rpm.pbone.net/index.php3/stat/4/idpl/27028074/dir/fedora_other/com/glew-1.10.0-5.fc21.x86_64.rpm.html

I hope some other fedora user here might be able to provide more details.

[hiker]

Oh, and I forgot to mention: "true" or "yes" in XML files is both accepted by STK.

[stkAnon]

Looking at the second link, and apps.fedora.org, it seems that the libglew1.10 package is only for Fedora 21, which is slated to be released in December. I'll make a thread on the forums asking if there's some other repository I can install to get it on Fedora 20.

Thanks for implementing this and helping me compile the game. Unless the scale not working is a big issue, then this ticket can probably be closed.