https://forum.supertuxkart.net/ Sat, 19 Sep 2026 16:42:40 +0000 MyBB https://forum.supertuxkart.net/thread-434.html Fri, 18 Sep 2026 15:00:36 +0000 stbdev]]> https://forum.supertuxkart.net/thread-434.html
I am in the process of implementing a speed lines shader to the stk-codebase. With this post I'm hoping to discuss the possibility of adding it to the game.

Intro
Speed lines (aka wind streaks) (see the videos below for more info) are quite a common feature in kart racing games, as the name suggests they come on screen when the player experiences a speed boost of some sorts, usually through an upgrade. I personally noticed them first in Mario Kart, but I've since gone and checked a few other kart racers (Sonic, Crash Team Racing etc.) and they all feature them in some capacity. The main purpose is to provide an extra sense of speed to the player, by mimicking wind rushing past at high speeds.

Shader
I initially started writing the effect purely in GLSL, but pivoted to using Godot's visual shader graph for quicker iteration. Before delving into more specifics here's what it looks like in isolation:
https://youtu.be/_1LBMsESjSQ

(or see next post for embedded view)

There are quite a few tweakable parameters for the shader. Ranging from: 

• Density of particles
  
• Softness of the particles
  
• Amount of wisps (i.e. how many subdivisions of the UV space to sample the noise texture from)
  
• Wind speed (very useful as we can tie the intensity of the boost to this)
  
• Radial stretch (how blobly should the wisps be, effectively stretches the uv.x coordinate)
  
• Radial mask size (how much of the screen should be ensure is always free of the effect - for gameplay purposes)
  
• etc.
  

At the moment I have implemented a primary control to the shader (value ranging from 0-1 as a scalar float) BoostIntensity. That value is driving:

• the wind speed
  
• size of the radial mask (make the mask a bit tighter at higher intensities to really bring home the sense of speed)
  
• color saturation (make the effect pop more at higher intensities, makes the wind feel more intense)
  

While I still need to profile on some weaker hardware, the shader should be really cheap to run on most hardware. On my machine it was close to 30us (7900xt). The effect works with sampling a noise texture at 2 samples per pixel, which is really modest in my experience.

Preview
Hooking up the shader and it's driving value -> BoostIntensity. We get something like the following:

(note the effect does look somewhat choppy due to the video quality, but is smooth during actual gameplay)


Implementation
I am still trialing the proper CPU side implementation, mainly on the 'how exactly' the effect should come in, how strong and how long should it last etc.

I've been experimenting with a few different options for the question 'how exactly'. Ranging from:

• Should it come in mainly based on current velocity ratio with maximum velocity?
  
• Should it be on impulse/activation of a SpeedIncrease?
  

I believe at the moment I'm going with a bit of a hybrid solution of the both, this looks roughly like the following:

• Use the trigger of any SpeedIncrease modifier as the impulse 
  
  (as long as there's no active SpeedDecrease or Attachment like the anchor/parachute etc.).
  
  
• Then shortly driving up the value and overshooting slightly to a target value.
  
  (make the impulse of the effect a tad stronger than it's sustained intensity).
  
  
• Then settle down the intensity value and base it on the ratio between the current speed and the maximum speed.
  The last step here effectively helps tie the effect to match with the current speed regardless of difficulty setting.
  
  
• Then I use the already pre-existing unique duration(s) of the SpeedIncrease to keep the effect active.
  
  
• Once the SpeedIncrease runs out we linearly interpolate back down to 0 to gently ease out.
  
  
• There are also some provisions for correctly latching whether we've crashed into something, drastically lost speed or got hit with a SpeedDecrease to then directly ease down to 0 (rather than waiting for the effect to run out naturally).
  
  

I am still needing to properly clean up and dial in the logic, but I personally think it's getting closer to the final solution. A couple of notes from my side:

• The effect does still ramp up to 1.0f quite fast at the moment, dialing this down is something I'm working on, it should only really be at 1.0f if we've stacked 2-3 speed increases and going fast (i.e. coming out of red skid + zipper + nitro should be 1).
  
  
• Once we crash the effect can come down just a tad faster in my book, at the moment it uses the same linear ease down to 0 as when the effect normally runs out.
  
  
• Certain SpeedIncrease items we can maybe experiment with not having it contribute to the intensity (i.e. turn it off for skids etc.?)
  

Closing Remarks
If this feature/effect looks of interest to you and would be a good fit for the game, let me know and I can clean up my code and start the PR. From there we can discuss further and iterate on feedback/suggestions.

PS: I did only notice at the posting of this post that there might be a related thread to another implementation of speed lines, my apologies there, but I do think we can work out a way to combine our efforts. https://forum.supertuxkart.net/thread-200.html

Thanks and kind regards,
stbdev]]>
I am in the process of implementing a speed lines shader to the stk-codebase. With this post I'm hoping to discuss the possibility of adding it to the game.

Intro
Speed lines (aka wind streaks) (see the videos below for more info) are quite a common feature in kart racing games, as the name suggests they come on screen when the player experiences a speed boost of some sorts, usually through an upgrade. I personally noticed them first in Mario Kart, but I've since gone and checked a few other kart racers (Sonic, Crash Team Racing etc.) and they all feature them in some capacity. The main purpose is to provide an extra sense of speed to the player, by mimicking wind rushing past at high speeds.

Shader
I initially started writing the effect purely in GLSL, but pivoted to using Godot's visual shader graph for quicker iteration. Before delving into more specifics here's what it looks like in isolation:
https://youtu.be/_1LBMsESjSQ

(or see next post for embedded view)

There are quite a few tweakable parameters for the shader. Ranging from: 

• Density of particles
  
• Softness of the particles
  
• Amount of wisps (i.e. how many subdivisions of the UV space to sample the noise texture from)
  
• Wind speed (very useful as we can tie the intensity of the boost to this)
  
• Radial stretch (how blobly should the wisps be, effectively stretches the uv.x coordinate)
  
• Radial mask size (how much of the screen should be ensure is always free of the effect - for gameplay purposes)
  
• etc.
  

At the moment I have implemented a primary control to the shader (value ranging from 0-1 as a scalar float) BoostIntensity. That value is driving:

• the wind speed
  
• size of the radial mask (make the mask a bit tighter at higher intensities to really bring home the sense of speed)
  
• color saturation (make the effect pop more at higher intensities, makes the wind feel more intense)
  

While I still need to profile on some weaker hardware, the shader should be really cheap to run on most hardware. On my machine it was close to 30us (7900xt). The effect works with sampling a noise texture at 2 samples per pixel, which is really modest in my experience.

Preview
Hooking up the shader and it's driving value -> BoostIntensity. We get something like the following:

(note the effect does look somewhat choppy due to the video quality, but is smooth during actual gameplay)


Implementation
I am still trialing the proper CPU side implementation, mainly on the 'how exactly' the effect should come in, how strong and how long should it last etc.

I've been experimenting with a few different options for the question 'how exactly'. Ranging from:

• Should it come in mainly based on current velocity ratio with maximum velocity?
  
• Should it be on impulse/activation of a SpeedIncrease?
  

I believe at the moment I'm going with a bit of a hybrid solution of the both, this looks roughly like the following:

• Use the trigger of any SpeedIncrease modifier as the impulse 
  
  (as long as there's no active SpeedDecrease or Attachment like the anchor/parachute etc.).
  
  
• Then shortly driving up the value and overshooting slightly to a target value.
  
  (make the impulse of the effect a tad stronger than it's sustained intensity).
  
  
• Then settle down the intensity value and base it on the ratio between the current speed and the maximum speed.
  The last step here effectively helps tie the effect to match with the current speed regardless of difficulty setting.
  
  
• Then I use the already pre-existing unique duration(s) of the SpeedIncrease to keep the effect active.
  
  
• Once the SpeedIncrease runs out we linearly interpolate back down to 0 to gently ease out.
  
  
• There are also some provisions for correctly latching whether we've crashed into something, drastically lost speed or got hit with a SpeedDecrease to then directly ease down to 0 (rather than waiting for the effect to run out naturally).
  
  

I am still needing to properly clean up and dial in the logic, but I personally think it's getting closer to the final solution. A couple of notes from my side:

• The effect does still ramp up to 1.0f quite fast at the moment, dialing this down is something I'm working on, it should only really be at 1.0f if we've stacked 2-3 speed increases and going fast (i.e. coming out of red skid + zipper + nitro should be 1).
  
  
• Once we crash the effect can come down just a tad faster in my book, at the moment it uses the same linear ease down to 0 as when the effect normally runs out.
  
  
• Certain SpeedIncrease items we can maybe experiment with not having it contribute to the intensity (i.e. turn it off for skids etc.?)
  

Closing Remarks
If this feature/effect looks of interest to you and would be a good fit for the game, let me know and I can clean up my code and start the PR. From there we can discuss further and iterate on feedback/suggestions.

PS: I did only notice at the posting of this post that there might be a related thread to another implementation of speed lines, my apologies there, but I do think we can work out a way to combine our efforts. https://forum.supertuxkart.net/thread-200.html

Thanks and kind regards,
stbdev]]> https://forum.supertuxkart.net/thread-421.html Tue, 25 Aug 2026 20:08:19 +0000 Gusta]]> https://forum.supertuxkart.net/thread-421.html
I have some ideas that I can talk later.]]>
I have some ideas that I can talk later.]]> https://forum.supertuxkart.net/thread-412.html Wed, 19 Aug 2026 15:50:32 +0000 schrowd]]> https://forum.supertuxkart.net/thread-412.html Issue #5197 mentions adding the ability to pause, seek, move back and forth by individual frames and change
the speed of playback when watching replays. To this, Alayan responded "Pause, rewind and speed change are
all things I would like to have as well. This won't be in 1.5 and maybe not in 2.0, but it's definitely on the roadmap."

I have built the engine side of this and in accordance with the "Communicating with the team" section of the
contributing code guidelines I am making a forum post about it.

I have implemented this by means of a ReplayControl class that owns the replay clock. It can pause (setPlaying), move 
the head of the playback to a desired time (seek) and change the rate of playback (setRate). The ability to move back and 
forth by individual frames naturally falls out of this; you would just seek by a frame-sized delta (or move to an adjacent time
via m_all_times, both can work). This functionality is currently enabled via a --replay-control flag and without it it is inert.
This doesn't change the normal race clock: everything outside of watch replay mode remains untouched.

I have deliberately NOT added the UI. I've built the mechanism, however as it stands there is no user interface that allows
the user to control it. This is on purpose and has been done for two main reasons.

   1. Building UI blind without knowing if it is wanted or how the structure should be set out puts my time and effort at risk of being wasted.

   2. Where the UI lives, how it looks, where the buttons are, etc. are design decisions that are not my call to make.

This feature has a dependency on the fix outlined in pull request #5837 - without it, seeking backwards would cause the ghost
to freeze in place, which is far from ideal.

The diff can be found here: https://github.com/schrowd/stk-code/compare/fix-ghost-controller-seekable...feature-replay-control

(Note to reviewer: the three "removed" lines in world_status.cpp are still there, they're just indented one level deeper and so
 GitHub shows them as red. None of the original behaviour has been changed or deleted. You can see that exact same code in
 lines 479-481.)

To wrap this up, I'd like to ask a few questions:

• Is this something you'd want in the main game?
  
• Should I build the UI or is that something you would be doing?
  
• Is driving the world clock the correct approach?
  
• Where should this live? It currently lives in src/replay: does it belong somewhere else?
  
• Whose job should it be to handle frame-stepping - ReplayControl's or the UI's?
  

Those are the main questions I'd like answers for however if you have any other questions or concerns I'd be happy to answer them.]]> Issue #5197 mentions adding the ability to pause, seek, move back and forth by individual frames and change
the speed of playback when watching replays. To this, Alayan responded "Pause, rewind and speed change are
all things I would like to have as well. This won't be in 1.5 and maybe not in 2.0, but it's definitely on the roadmap."

I have built the engine side of this and in accordance with the "Communicating with the team" section of the
contributing code guidelines I am making a forum post about it.

I have implemented this by means of a ReplayControl class that owns the replay clock. It can pause (setPlaying), move 
the head of the playback to a desired time (seek) and change the rate of playback (setRate). The ability to move back and 
forth by individual frames naturally falls out of this; you would just seek by a frame-sized delta (or move to an adjacent time
via m_all_times, both can work). This functionality is currently enabled via a --replay-control flag and without it it is inert.
This doesn't change the normal race clock: everything outside of watch replay mode remains untouched.

I have deliberately NOT added the UI. I've built the mechanism, however as it stands there is no user interface that allows
the user to control it. This is on purpose and has been done for two main reasons.

   1. Building UI blind without knowing if it is wanted or how the structure should be set out puts my time and effort at risk of being wasted.

   2. Where the UI lives, how it looks, where the buttons are, etc. are design decisions that are not my call to make.

This feature has a dependency on the fix outlined in pull request #5837 - without it, seeking backwards would cause the ghost
to freeze in place, which is far from ideal.

The diff can be found here: https://github.com/schrowd/stk-code/compare/fix-ghost-controller-seekable...feature-replay-control

(Note to reviewer: the three "removed" lines in world_status.cpp are still there, they're just indented one level deeper and so
 GitHub shows them as red. None of the original behaviour has been changed or deleted. You can see that exact same code in
 lines 479-481.)

To wrap this up, I'd like to ask a few questions:

• Is this something you'd want in the main game?
  
• Should I build the UI or is that something you would be doing?
  
• Is driving the world clock the correct approach?
  
• Where should this live? It currently lives in src/replay: does it belong somewhere else?
  
• Whose job should it be to handle frame-stepping - ReplayControl's or the UI's?
  

Those are the main questions I'd like answers for however if you have any other questions or concerns I'd be happy to answer them.]]> https://forum.supertuxkart.net/thread-401.html Mon, 03 Aug 2026 22:39:14 +0000 nastynate664]]> https://forum.supertuxkart.net/thread-401.html https://forum.supertuxkart.net/thread-400.html Sun, 02 Aug 2026 16:53:03 +0000 Mish7913]]> https://forum.supertuxkart.net/thread-400.html

Few days ago, I learned that you can make several animation for assets, and game will choose randomly what to play in current race, you need just put markers on timeline "start" and "end" several times to separate animations, like this.



So ... that gives me an idea, what if add this method to the karts as well?
When you repeat same markers of animation, for example "winning animation", and when you will win the race - game will randomly choose one of winning animations, that can be also for "loosing" animation, for "hit", for "jump", etc ...

Like this:


So ... what do you think about this idea?

  2026-08-02 19-33-15.jpg (Size: 16.06 KB / Downloads: 98)

  2026-08-02 19-34-07.jpg (Size: 8.23 KB / Downloads: 94) ]]>

Few days ago, I learned that you can make several animation for assets, and game will choose randomly what to play in current race, you need just put markers on timeline "start" and "end" several times to separate animations, like this.



So ... that gives me an idea, what if add this method to the karts as well?
When you repeat same markers of animation, for example "winning animation", and when you will win the race - game will randomly choose one of winning animations, that can be also for "loosing" animation, for "hit", for "jump", etc ...

Like this:


So ... what do you think about this idea?

  2026-08-02 19-33-15.jpg (Size: 16.06 KB / Downloads: 98)

  2026-08-02 19-34-07.jpg (Size: 8.23 KB / Downloads: 94) ]]> https://forum.supertuxkart.net/thread-399.html Sun, 02 Aug 2026 13:35:20 +0000 Gusta]]> https://forum.supertuxkart.net/thread-399.html
Someone with experience with Vulkan coding can help me (and DON'T DARE TO USE LLM IN THIS, DAMN).

Things to finish:

 - Post processing (stk-code/src/graphics/post_processing.xpp)
 - Shadows 
 - Maybe new shaders? 
 - More things to see in video settings.

Maybe, I will create a repository to make easier the co-working.]]>
Someone with experience with Vulkan coding can help me (and DON'T DARE TO USE LLM IN THIS, DAMN).

Things to finish:

 - Post processing (stk-code/src/graphics/post_processing.xpp)
 - Shadows 
 - Maybe new shaders? 
 - More things to see in video settings.

Maybe, I will create a repository to make easier the co-working.]]> https://forum.supertuxkart.net/thread-398.html Sat, 01 Aug 2026 17:58:55 +0000 Stellar Horse]]> https://forum.supertuxkart.net/thread-398.html They are not fit to the sizes of the characters on the karts. When I drive along the tracks i always think - Why everything is so big here? All tracks are so beautifully made, but there is no feeling of awareness that these tracks are created for the characters. Right now it feels as if they are just some strangers who accidentally drove into a places that not belongs to them. 

And because everything is so big, I can't enjoy the beauty of the tracks on the fullest because everything is too high, so i have to drive back to get better look at some objects.

I just thought maybe you would consider this question and maybe adjust the sizes? 

In any case, i just sharing with you my thoughts  I love this game, it's very enjoyable to play ]]> They are not fit to the sizes of the characters on the karts. When I drive along the tracks i always think - Why everything is so big here? All tracks are so beautifully made, but there is no feeling of awareness that these tracks are created for the characters. Right now it feels as if they are just some strangers who accidentally drove into a places that not belongs to them. 

And because everything is so big, I can't enjoy the beauty of the tracks on the fullest because everything is too high, so i have to drive back to get better look at some objects.

I just thought maybe you would consider this question and maybe adjust the sizes? 

In any case, i just sharing with you my thoughts  I love this game, it's very enjoyable to play ]]> https://forum.supertuxkart.net/thread-393.html Thu, 23 Jul 2026 14:41:04 +0000 Fine-Feline-3d]]> https://forum.supertuxkart.net/thread-393.html It's a small detail but can easily introduce enhanced visual on most characters very easily once implemented.

What I'm talking about is giving the possibility to the artists to assign certain bones the ability to be affected by the speed vector.
what do I mean by this? for example.

For a practical example, consider any Kart which character has big ears. if the artist decided to animate the ears, currently the only way to go about it is to choose what direction they should flop towards in a turn. if you expect the character to have the ears flop towards the left when turning right, as an artist what you will do is baking in the turning right animation the ears to flop or lean towards the left. However this approach breaks the moment the player drifts. if the player counter steers, the kart started the drift on the left but counter steer to the right, the turning right animation will playing, which is correct, but will set the ears to flop in the opposite direction of where they would naturally flop. this breaks the visuals a bit. the other solution is just not animating them at all which really makes the game feel visually a bit stale.

so what I'm asking for is to be able to use the velocity vector of the kart and use that to affect how selected bones behave. In the far future if this is expanded, it could also lay the base to make entire animations more dynamic, so like depending on the velocity vector the character might lean to one side, not binded to the turning left turning right. if the kart jumps onto bumps you will see the character jumping in the seat a little bit or if he hits another cart you'll see the sudden deceleration causing the character to bounce to one side. all of which wouldn't require separate animations to be baked but just selected bones to react to the kart speed vector.

minor details that have big visual impacts and make everything more fun to look at.

anyway back to what I was saying, all the rest can be kept for the far future. I'm just asking for selected bones to be affected by the speed vector to make simple things like ears or tails that flop following the "wind" or like even certain kart components, clothes pieces like capes or scarfs.

  incredible diagram sorry.png (Size: 57.48 KB / Downloads: 19)

Sadly I don't know exactly how this should be implemented the best. in theory it should be relatively simple but I have no familiarity with the game engine. I might make a more detailed post in the future since this is a sketch outlining an idea.
Thank you for taking a look at this let me know if it is in any plans.]]> It's a small detail but can easily introduce enhanced visual on most characters very easily once implemented.

What I'm talking about is giving the possibility to the artists to assign certain bones the ability to be affected by the speed vector.
what do I mean by this? for example.

For a practical example, consider any Kart which character has big ears. if the artist decided to animate the ears, currently the only way to go about it is to choose what direction they should flop towards in a turn. if you expect the character to have the ears flop towards the left when turning right, as an artist what you will do is baking in the turning right animation the ears to flop or lean towards the left. However this approach breaks the moment the player drifts. if the player counter steers, the kart started the drift on the left but counter steer to the right, the turning right animation will playing, which is correct, but will set the ears to flop in the opposite direction of where they would naturally flop. this breaks the visuals a bit. the other solution is just not animating them at all which really makes the game feel visually a bit stale.

so what I'm asking for is to be able to use the velocity vector of the kart and use that to affect how selected bones behave. In the far future if this is expanded, it could also lay the base to make entire animations more dynamic, so like depending on the velocity vector the character might lean to one side, not binded to the turning left turning right. if the kart jumps onto bumps you will see the character jumping in the seat a little bit or if he hits another cart you'll see the sudden deceleration causing the character to bounce to one side. all of which wouldn't require separate animations to be baked but just selected bones to react to the kart speed vector.

minor details that have big visual impacts and make everything more fun to look at.

anyway back to what I was saying, all the rest can be kept for the far future. I'm just asking for selected bones to be affected by the speed vector to make simple things like ears or tails that flop following the "wind" or like even certain kart components, clothes pieces like capes or scarfs.

  incredible diagram sorry.png (Size: 57.48 KB / Downloads: 19)

Sadly I don't know exactly how this should be implemented the best. in theory it should be relatively simple but I have no familiarity with the game engine. I might make a more detailed post in the future since this is a sketch outlining an idea.
Thank you for taking a look at this let me know if it is in any plans.]]> https://forum.supertuxkart.net/thread-391.html Wed, 22 Jul 2026 12:19:32 +0000 Mish7913]]> https://forum.supertuxkart.net/thread-391.html
What if create "Ghost Kart" power-up. It's like a Suzanne in Cocoa-Temple track (she racing like a ghost kart, you can't interact with her). So ... what if make this power-up, when you enable it you will be a ghost kart for a few seconds, and you can ride through all karts and bananas, and no-one can interact with you (slap you with swatter or bowling ball, or cake, etc...).

And this will have a small weakness as well (for the balance) - when you are ghost kart, you can't grab gift boxes, and nitro.

So what do you think?

  screenshot.jpg (Size: 125.67 KB / Downloads: 13) ]]>
What if create "Ghost Kart" power-up. It's like a Suzanne in Cocoa-Temple track (she racing like a ghost kart, you can't interact with her). So ... what if make this power-up, when you enable it you will be a ghost kart for a few seconds, and you can ride through all karts and bananas, and no-one can interact with you (slap you with swatter or bowling ball, or cake, etc...).

And this will have a small weakness as well (for the balance) - when you are ghost kart, you can't grab gift boxes, and nitro.

So what do you think?

  screenshot.jpg (Size: 125.67 KB / Downloads: 13) ]]> https://forum.supertuxkart.net/thread-390.html Wed, 22 Jul 2026 11:10:48 +0000 Mish7913]]> https://forum.supertuxkart.net/thread-390.html
Right now items in addons looks like that:


But what if make looks like that? 
(I just edited screenshot in GIMP for example)


  screenshot.jpg (Size: 63.51 KB / Downloads: 95)

  screenshot-edited.jpg (Size: 82.64 KB / Downloads: 94) ]]>
Right now items in addons looks like that:


But what if make looks like that? 
(I just edited screenshot in GIMP for example)


  screenshot.jpg (Size: 63.51 KB / Downloads: 95)

  screenshot-edited.jpg (Size: 82.64 KB / Downloads: 94) ]]> https://forum.supertuxkart.net/thread-389.html Tue, 21 Jul 2026 20:58:35 +0000 Mish7913]]> https://forum.supertuxkart.net/thread-389.html
For example: 

• When you hit another kart, play sound like "YES!!!" or "YEAHH!!!".
  
• When someone hits you: "Aaaaah!" or "Oh NO!!!".
  

Custom audios for each kart, audio can be for winning and losing as well.

What do you think about this idea?]]>
For example: 

• When you hit another kart, play sound like "YES!!!" or "YEAHH!!!".
  
• When someone hits you: "Aaaaah!" or "Oh NO!!!".
  

Custom audios for each kart, audio can be for winning and losing as well.

What do you think about this idea?]]> https://forum.supertuxkart.net/thread-384.html Mon, 13 Jul 2026 13:56:15 +0000 Mish7913]]> https://forum.supertuxkart.net/thread-384.html  Well ... if it's not what STK need, at least I have fun drawing this, and also it maybe gives to someone ideas for real STK story.

P/S: Watch with SOUND ON (I voiced).

---

IDEA 1: 
]]>  Well ... if it's not what STK need, at least I have fun drawing this, and also it maybe gives to someone ideas for real STK story.

P/S: Watch with SOUND ON (I voiced).

---

IDEA 1: 
]]> https://forum.supertuxkart.net/thread-379.html Sat, 04 Jul 2026 15:30:10 +0000 NGTT2]]> https://forum.supertuxkart.net/thread-379.html I have observed that the last player has the highest chance to get 3+ zippers from the powerup chest so i was just wondering how it works and also does it effect the percentage of them getting a bomb instead of anchor and parachute if they are last. 

I also have question related on how i can record benchmark or do test like how fast the ai kart is in server vs offline mode in same map and same goes to the players.


Thank you,
NGTT2 

ssdsa




fdfdf]]> I have observed that the last player has the highest chance to get 3+ zippers from the powerup chest so i was just wondering how it works and also does it effect the percentage of them getting a bomb instead of anchor and parachute if they are last. 

I also have question related on how i can record benchmark or do test like how fast the ai kart is in server vs offline mode in same map and same goes to the players.


Thank you,
NGTT2 

ssdsa




fdfdf]]> https://forum.supertuxkart.net/thread-373.html Mon, 29 Jun 2026 19:40:50 +0000 Gusta]]> https://forum.supertuxkart.net/thread-373.html
I tested 30 and 60 (60 was the best).

If you want to test, download this .APK (STK Evolution build for arm64): https://drive.google.com/file/d/1pbLTvcl...p=drivesdk

You can post your feedback here (and pls, do it ]]>
I tested 30 and 60 (60 was the best).

If you want to test, download this .APK (STK Evolution build for arm64): https://drive.google.com/file/d/1pbLTvcl...p=drivesdk

You can post your feedback here (and pls, do it ]]> https://forum.supertuxkart.net/thread-341.html Mon, 18 May 2026 22:24:58 +0000 meatball_stk]]> https://forum.supertuxkart.net/thread-341.html I am working on fixing the bug described in Github Issue #3782 and it would be helpful if I could see the blend file; however, the blend file for STK Enterprises is not in the stk-media-repo. Does anyone know where that file it located?]]> I am working on fixing the bug described in Github Issue #3782 and it would be helpful if I could see the blend file; however, the blend file for STK Enterprises is not in the stk-media-repo. Does anyone know where that file it located?]]>