Disabling Diagonal Movement

Well since maxRollVelocity isn't an absolute limit, but a value that is multiplied by input, airAcceleration probably is too. If you move ~1.4 times faster in the air, and you spend most of a level jumping....

Mar 30, 2013, 4:13am, admin wrote:If diagonal and normal movement are the same now then jumping does not matter, nor should any other value in marble.cs because you've limited the speed.

You can test better by going jumping forwards vs. jumping diagonally and check for differences and then better test for those.

If your goal was to have diagonal = forwards only speed, then you've succeeded and replicated a MBU/O player with an unmodded xbox360 controller.
From the results I've gotten, the diagonal speed = forwards speed only when you are not jumping. If you jump whilst moving diagonally, then you move faster than if you were moving forward and jumping. In that example it suggests that moving diagonally is what is giving you the extra speed, which is what I don't want.

Mar 29, 2013, 10:31pm, frublox wrote:The only other one that seems to even remotely control speed is airAcceleration, but that just controls how fast the marble moves whilst in the air. I should note that if you do not jump with this mod enabled, diagonal movement and normal movement are almost the exact same. Perhaps I'll play with that and see what I get.I looked at some posts on another thread and found some more marble settings. I modified a few of them by a factor of 1/sqrt(2) (I also put everything to 4 dp) and I got a diagonal movement closer to forward movement. I made further modifications using the settings and I got a configuration that gets ~2.56 on the Time Trial TM while going diagonally, but the final time of the marble is still different (so there's some sort of acceleration difference). I can't post the code now since my laptop is out of battery and I left the charger at school yesterday (I can't get it back until next Monday).

airAcceleration is new to me, have you tried changing that? Constant jumping essentially implies the marble is in the air almost all the time.

Mar 30, 2013, 3:48pm, imacmatician wrote:
Mar 29, 2013, 10:31pm, frublox wrote:The only other one that seems to even remotely control speed is airAcceleration, but that just controls how fast the marble moves whilst in the air. I should note that if you do not jump with this mod enabled, diagonal movement and normal movement are almost the exact same. Perhaps I'll play with that and see what I get.I looked at some posts on another thread and found some more marble settings. I modified a few of them by a factor of 1/sqrt(2) (I also put everything to 4 dp) and I got a diagonal movement closer to forward movement. I made further modifications using the settings and I got a configuration that gets ~2.56 on the Time Trial TM while going diagonally, but the final time of the marble is still different (so there's some sort of acceleration difference). I can't post the code now since my laptop is out of battery and I left the charger at school yesterday (I can't get it back until next Monday).

airAcceleration is new to me, have you tried changing that? Constant jumping essentially implies the marble is in the air almost all the time.
Can you list the values you changed? From what I've seen, I haven't found any other values that would be relevant to marble speed/acceleration.

If anyone wants to try what I did for maxRollVelocity and angularAcceleration, use the value 3.5355339059327376220042218105242 (approximate, and you can probably do without that many decimal places) for airAcceleration. I'll try this and update accordingly.

UPDATE: This actually seems to work! Jumping made neither diagonal movement nor normal movement faster. Adding this to the code in the first post.

Note guys that the airAcceleration static (tagged fields) field only takes affect whenever the marble is not colliding with something. Just wanted to clarify that, which hopefully you guys knew.

Just for your knowledge (because I am a geek and you know it!)

Tagged (Static) Fields are those that are callbacks to the engine.

Dynamic Fields are those that are only script related fields.

Mar 30, 2013, 6:16pm, jeff wrote:Note guys that the airAcceleration static (tagged fields) field only takes affect whenever the marble is not colliding with something. Just wanted to clarify that, which hopefully you guys knew.

Just for your knowledge (because I am a geek and you know it!)

Tagged (Static) Fields are those that are callbacks to the engine.

Dynamic Fields are those that are only script related fields.
I kind of guessed that.

Either way the code will work in any circumstance the marble is in (that I have tested). If anyone has problems, let me know.

Tested it in a number of places, there are no problems as far as I am aware.

Apr 2, 2013, 8:40am, imacmatician wrote:Tested it in a number of places, there are no problems as far as I am aware.

I think it would be interesting to play with this feature as a sort of handicap (like no jumping, for instance).

Yeah that would be pretty neat to play with. And of course disabling jumping would be so easy, just have a global variable that stops jumping lol.

Apr 2, 2013, 3:04pm, frublox wrote:
Apr 2, 2013, 8:40am, imacmatician wrote:Tested it in a number of places, there are no problems as far as I am aware.

I think it would be interesting to play with this feature as a sort of handicap (like no jumping, for instance). I'm going to make a video to be released either in 1-2 weeks or sometime next month (most likely the latter). From preliminary playing, I've found that the marble handles much differently from normal play. When playing normally, one use diagonal movement every time two movement keys are pressed at once, even if one is not specifically moving diagonally for a significant duration. That can happen when turning, when stopping, or even when changing direction without camera movement.

I also enjoyed testing this code and figuring out what the different values do to the marble. I think I'll go into some coding in the near future, it sounds like a good idea for me.

^ programming is a good thing to learn ( slightly biased opinion from me much, eh? )

It is like solving a big puzzle, except it never ends....:c

Apr 3, 2013, 2:00pm, jeff wrote:^ programming is a good thing to learn ( slightly biased opinion from me much, eh? )

It is like solving a big puzzle, except it never ends....:c
Programming isn't the puzzle, debugging is. (IMO)


Apr 3, 2013, 11:42am, imacmatician wrote:
Apr 2, 2013, 3:04pm, frublox wrote:

I think it would be interesting to play with this feature as a sort of handicap (like no jumping, for instance). I'm going to make a video to be released either in 1-2 weeks or sometime next month (most likely the latter). From preliminary playing, I've found that the marble handles much differently from normal play. When playing normally, one use diagonal movement every time two movement keys are pressed at once, even if one is not specifically moving diagonally for a significant duration. That can happen when turning, when stopping, or even when changing direction without camera movement.

I also enjoyed testing this code and figuring out what the different values do to the marble. I think I'll go into some coding in the near future, it sounds like a good idea for me.
It doesn't occur when just any two movement keys are pressed -- just the ones that allow the player to use diagonal movement. Pressing W and S together doesn't cause the changes for diagonal movement, and neither does pressing A and D.

Anyway, I'm looking forward to seeing your video. It'll be a real test of this code.

Nice, but to optimize code, you have to check for diagonal movement only in two cases.

Since the diagonal movement is based on pressing two keys, you shoud check only for moveleft and moveright or moveforward and movebackward.

Apr 19, 2013, 12:55pm, dobrakmato wrote:Nice, but to optimize code, you have to check for diagonal movement only in two cases.

Since the diagonal movement is based on pressing two keys, you shoud check only for moveleft and moveright or moveforward and movebackward.

I specifically left out checking those key combinations because they don't cause diagonal movement. Pressing forward and backward together doesn't even move the marble, nor does pressing left and right.

I think that what Mato means is that you only need to check isMovingDiagonally() in 2 of your movement functions, not all 4. You will always be pressing either left or right when moving diagonally, so you can remove the if statements from forward and back. Or you could remove the if statements from right and left, same effect. Probably makes more sense to remove it from forward and back because they are (most likely) used more.

Currently you are checking isMovingDiagonally() twice every time 2 buttons are pressed at once, and if it returns true changing the values twice as well (to the same thing).

It didn't even occur to me until Mato mentioned it.

@Don.Gato and Mato - makes sense to me, as it is redundant to check them twice.

@Frublox, i suggest you change what they said, keep the left/right keys checking,but restore the forwards/backwards keys to the original.

Well, that makes a lot more sense than what I thought he meant.

I'll change it now.

Code:function isMovingDiagonally()
{
if (($mvLeftAction && $mvForwardAction) || ($mvRightAction && $mvForwardAction) || ($mvLeftAction && $mvBackwardAction) || ($mvRightAction && $mvBackwardAction))
return true;
}

a) You aren't returning anything if the test fails; in TS this probably returns an empty string, but this would cause crashes in other languages, and it's not good practice anyway.
b) if (x) return true; else return false; is equivalent to just saying return x;. In other words, there's no reason to have an if test if you're just returning a simple boolean expression.
c) This can be simplified even further by taking advantage of the fact that TS and many other languages use 0 and 1 to represent boolean true and false, so you can treat them as numbers.

Here's a revised isMovingDiagonally() accounting for the above:

Code:function isMovingDiagonally()
{
return ($mvForwardAction + $mvBackwardAction + $mvLeftAction + $mvRightAction == 2);
}

This code has slightly different behavior in three ways:

-If you press three keys at once, it will register as normal movement, while the original would register this as diagonal. This is a desirable change, as pressing three keys ends up equating to normal movement, not diagonal movement.
-If you press two opposing keys, however, it will register as diagonal movement. This isn't desired, but it won't matter, because here the marble isn't accelerating.
-The biggest issue is that this code fails if you're using anything but key presses—anything that uses moveXAxis and moveYAxis will cause this code to give false negatives. However, this isn't a terrible issue, as you'd probably want separate joystick code anyway.

Also, my intuition tells me that maxRollVelocity shouldn't need to change, but Don.Gato just said otherwise, which I find odd.

Thanks for the revision, whirligig (most of my code isn't that efficient since I always forget to revise it). I'll update the code in the first post.

As for moveXAxis and moveYAxis, I've yet to experiment with them. Perhaps by using them it's possible to achieve disabled diagonal movement for the keyboard and joysticks simultaneously.

For maxRollVelocity, I still need to do some testing to see which variables actually play a role in capping diagonal movement. Then I can see if perhaps you're right about it not needing to change.