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);
};
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.
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
