Altimit Pixel Movement [0.50β]

Hey Ace, we are also running into the same problem but with the player. At high speeds you can go through the impassible tiles collision box and get stuck inside them as well.

Video: When player uses dash, you can see the player go in and out impassible tile and then get stuck. The dash is set to a speed of 5.8 (using speed manager plugin)

Spoiler

 

The issue is the collider for terrain is 0px thick, so if the player/event collider is moving fast enough and the FPS is low enough it can jump over the 0px line and get stuck on the other side.

The fix would be to extend colliders when a gap between frames is detected. Alternatively, just make them permanently larger for any events or the player so the issue never has a chance to appear.

 

In the end I had to disable Altimit's plugin because I couldn't find a fix for this.

Hasn't anyone else encountered this problem ? I can easily reproduce the bug on a fresh empty project

 

I believe this behavior is working as intended.

If you want to make this facing-dependent, I think you can use yanfly's encounter aid as a workaround. Don't turn on the encounter direction lock, and just have your pillar events include a wrapper based on "this.checkEventFacingPlayerFront()". That should mean that the pillar events all turn to face the player when they get interacted with, but only the one that the player is facing towards is going to actually trigger your code.

It might be a decent idea to safety-proof things a bit by making the colliders on map tiles one-way pointing out, so a character that gets stuck inside a wall can always move to an adjacent clear spot. IIRC that's how RMMV handles characters embedded in walls already.

Wouldn't eliminate the problem entirely, but does mean that nobody's getting softlocked by clipping one tile into a wall.

 

Movement speed is inconsistent depending on direction and speed value. Sometimes top-left diagonal is faster than any other direction? Also a speed of 1 (slowest) characters can only move top-left.

EDIT: Yeah seems top-left is actual move speed and all other direction are slower.
EDIT: Disabling Normalize for the player allows them to move diagonally at slowest speed but not in the cardinal directions.

BUG: Seems that the value passed to 'Game_CharacterBase.prototype.moveVector' is way to small do to tiny maths.
FIX: Just re-evaluate at the start of the function, not ideal I know but it works. (Not ideal but works for me)

Code:

var len = Math.sqrt( vx * vx + vy * vy );
vx = ( vx / len ) * this.realMoveSpeed() * ( 1 / 60 );
vy = ( vy / len ) * this.realMoveSpeed() * ( 1 / 60 );

NOTE: This fix normalizes movement and will likely break various commands.

NOTE: Bug persists when disabling Normalize Movement.

 

Here's an issue I came across while mapping (works on a vanilla project with just altimit):

The target x,y coordinates that your character is pathing to persists across map changes. In the worst case scenario, the wrong click can leave you trapped with characters going in and out of a transition zone constantly, and the player constantly spamming the mouse button to try to hit a frame that registers a click.


I think this is related to a deeper change in how mouse input is handled - by default, RMMV will cancel the mouse click target if you open a menu, but with altimit active the target persists across menu open/closing.

In the meantime, you can workaround by including a

Code:

this._touchTarget=null;

in a move route script after any map transition.
======================

Since this is becoming a full freaking topic, here's what I've been doing to try to avoid event jitter when using the mouse movement in altimit.

The current anti-jitter patch doesn't work very well in this case. Here's a screenshot of a test map I made with background tiles that had horizontal and vertical bars on even numbered pixels, with events that had those bars on the opposite odd-numbered pixels. It's oddly inconsistent.

My best workaround is installing Galv's camera control, and altering the jitter prevention code to use ceil() instead of round()

Code:

// OVERWRITE - BECAUSE OF JITTER
Game_Map.prototype.displayX = function() {return Math.ceil(this._displayX * Galv.CC.size) / Galv.CC.size};
Game_Map.prototype.displayY = function() {return Math.ceil(this._displayY * Galv.CC.size) / Galv.CC.size};

This has the effect of making all of yanfly's doodads have perpetual jitter, so we go into yanfly's plugin and change the rounding like so

Code:

Sprite_Doodad.prototype.screenX = function() {
  var value = this._data.x;
  var display = $gameMap._displayX;
  value -= display * this._tileWidth;
  if (value + this.width < 0 && $gameMap.isLoopHorizontal()) {
    value += this._mapWidth;
  }
  // return Math.ceil(value);
    return Math.floor(value);
};

Sprite_Doodad.prototype.screenY = function() {
  var value = this._data.y;
  var display = $gameMap._displayY;
  value -= display * this._tileHeight;
  if (value + this.height < 0 && $gameMap.isLoopVertical()) {
    value += this._mapHeight;
  }
// return Math.ceil(value);
    return Math.floor(value);
};

Which makes everything consistent for doodads, but leaves events jittery when altimit is happening.

To finish eliminating event jitter, insert this function into the default jitterfix. Note that this will *cause* jitter when using non altimit movement. I couldn't figure out why altimit was jittering, but I *could* figure out how to produce an equal and opposite jitter.

Code:

 Game_CharacterBase.prototype.scrolledX = function() {
    var tw = $gameMap.tileWidth();
    return Math.ceil($gameMap.adjustX(this._realX)*tw*2)/(tw*2);
};

Game_CharacterBase.prototype.scrolledY = function() {
   var th = $gameMap.tileHeight();
    return Math.ceil( $gameMap.adjustY(this._realY)*th*2)/(th*2);
};

The issue is with this line

Code:

        // Resolve too much precision
        move.x = Math.floor( move.x * Collider.PRECISION ) / Collider.PRECISION;
        move.y = Math.floor( move.y * Collider.PRECISION ) / Collider.PRECISION; 

It's a floor function, which means it makes negative numbers bigger, and positive numbers smaller (instead of consistently moving everything towards zero)

Altering it to

Code:

        // Resolve too much precision
        if (move.x>0){move.x = Math.floor( move.x * Collider.PRECISION ) / Collider.PRECISION;
       }else{move.x = Math.ceil( move.x * Collider.PRECISION ) / Collider.PRECISION;}
        if (move.y>0){move.y = Math.floor( move.y * Collider.PRECISION ) / Collider.PRECISION;
       }else{move.y = Math.ceil( move.y * Collider.PRECISION ) / Collider.PRECISION;}

results in symmetrical movement in all directions (though you still get slightly bigger diagonals due to rounding)

since we're scraping the bottom of the precision barrel, we can change

Code:

Collider.PRECISION = Math.pow( 2, 7);

to

Code:

Collider.PRECISION = Math.pow( 2, 8 );

which gives enough precision to move in all 8 directions at minimum speed

 

Changing

Code:

      var Game_Player_clearTransferInfo = Game_Player.prototype.clearTransferInfo;
      Game_Player.prototype.clearTransferInfo = function() {
        Game_Player_clearTransferInfo.call( this );
        this._moveTarget = false;
        this._moveTargetSkippable = false;
      };

to

Code:

      var Game_Player_clearTransferInfo = Game_Player.prototype.clearTransferInfo;
      Game_Player.prototype.clearTransferInfo = function() {
        Game_Player_clearTransferInfo.call( this );
        this._moveTarget = false;
        this._moveTargetSkippable = false;
       this._touchTarget = null;
      };

fixes this for any sort of map transition.

 

Thanks, I was looking for where that was supposed to go.


EDIT: My perpetual anti-jitter saga has come to an end. Edit the Jitterfix.js to use floor, and add on the scrolledX and scrolledY functions, like below. This will ONLY cure event jitter on altimit, it will create an equal and opposite jitter in non-altimit games.

Code:

Game_Map.prototype.displayX = function() {
    return Math.floor(this._displayX * Liquidize.JitterFix.TileSize) / Liquidize.JitterFix.TileSize;
   //return Math.ceil(this._displayX * Liquidize.JitterFix.TileSize) / Liquidize.JitterFix.TileSize;
};

Game_Map.prototype.displayY = function() {
    return Math.floor(this._displayY * Liquidize.JitterFix.TileSize) / Liquidize.JitterFix.TileSize;
   //return Math.ceil(this._displayY * Liquidize.JitterFix.TileSize) / Liquidize.JitterFix.TileSize;
};

 Game_CharacterBase.prototype.scrolledX = function() {
    var tw = $gameMap.tileWidth();
    return Math.ceil($gameMap.adjustX(this._realX)*tw*2)/(tw*2);
};

Game_CharacterBase.prototype.scrolledY = function() {
   var th = $gameMap.tileHeight();
    return Math.ceil( $gameMap.adjustY(this._realY)*th*2)/(th*2);
};

 

Is this plugin still being developed/supported?
I grabbed what I believe is the current version and dropped it into my project and it seems pretty great so far! However, I did run into a few issues.

Followers get stuck behind obstacles pretty easily, but I think everybody knows that.

When the player moves left or right while the followers are above them, the followers fail to fall into line. Similar behavior occurs if the player moves up or down while the followers are to their left.

When approaching an event, the player moves around it too easily, making it hard to line up. I thought I could fix this with an octagonal collider, but the octagon ended up being rotated 22.5 degrees from my intention.

I am also experiencing the same problem reported here by vico.

If the followers copied the player's movement like in Chrono Trigger, rather than moving towards the player's location, I think that could fix most of the issues with followers.

 

Actually, I do like the followers moving towards the player instead of making a caterpillar. It makes them feel more 'natural'. However, them getting stuck and never finding a way out or at least going through things when stuck like in SAN's Analog Movement can become an issue...

 

Doing both might be plausible, at the user's option. But fixing the followers as they are might need better pathfinding for them.

 

One problem using mouse movement is that if you define colliders using events, players clicking on that collider will have their destination set to the x,y coordinate of the event's base position, which isn't great.

This tweak to Game_Player.prototype.moveByInput will ignore any characters with no image when deciding on whether to track an event or not, so invisible colliders (and other invisible accessory events) will remain unnoticed by the mouseclick.

Code:

               if ( touchedCharacters.length ) {
                   if(!(touchedCharacters[0]._characterName=="")) //ignore characters with no image
                   {
                     // Move toward character
                     characterTarget = touchedCharacters[0];
                   }
                }

 

I need an small adaptation to this script. I want to be able to enable and disable it by plugin/script command because I only want to use it on the World Map.

Also I need a fix for touch input when zooming the map. The touch indicator circle is sightly displaced. I'm using MBS_MapZoom plugin (last version), zoom value is 2.0

And there's a bug making the character tremble when moving after collide with something.

EDIT: Also, is there any option to disable the diagonal movement?

 

I'm using this plugin for some time now, I don't had any problem so far. But I decided to test the gamepad support today and it doesn't seens to work. I'm using a Xbox One game pad. Any idea of what I can be doing wrong?

I already tried all game pad modes.

 

The only two problems that I have with this is the player can pass between two events in diagonally or if they are facing each other.

Spoiler: image

And, if I change the default colliders, for me to no not pass between two events face each other, when I press "OK" button, the two events are triggered.
I change to that(player collider and event collider):
<rect x='0.0' y='0.0' width='1.0' height='1.0' />
<rect x='0.0' y='0.0' width='0.4' height='0.4' />
<rect x='0.6' y='0.24' width='0.36' height='0.24' />

Also have some issues when event move towards player =/
The event don't move.

 

@Eliaquim can't you just make extra events on those spots and set them same as character?

 

if they're identical, you should probably just make them a single event.

 

Yes, I can, but make this all over the game seems impractical for me...
But thanks for the answer! I've found another pixel movement plugin that suits better. ^^

 

Could someone make a tutorial on how to use collision detection for parallax maps? Thanks.

 

These are round:

Code:

<collider>
<circle cx='0.5' cy='0.5' r='0.40' />
</collider>

It will draw a circle in the middle of an event with a diameter of 40 pixels.

These are Spongebob:

Code:

<collider>
<rect x='0' y='0' width='1' height='1' />
</collider>

This draws a rectangle of 48p by 48p.

Yes decimals work as long as you use a dot.
Put the collider code in a comment and at the top of the contents in an event.
No mayonaise is not an instrument.