Altimit Pixel Movement [0.50β]

● ARCHIVED · READ-ONLY
Started by xilefian 545 posts Page 7 of 28 View original ↗
  1. xilefian said:
    Yes you're right, some of the features are implemented, but not all of them. Animations for standing, moving and dashing are in place at the moment, but I haven't added support for jumping, idling or "low-health" and I haven't added support for custom states.

    EDIT: I'm still strongly considering separating the extra frames module into its own Plugin that works without Altimit Movement. This will allow some dedicated development and its own bug/feature tracker (and documentation).

    It's a bit more work for me in the short term, but a lot less work in the long term. What are everyone's thoughts on this idea?

    I'd probably make it support the QSprite JSON format in addition, so people can use the QSprite editor with it. There's a lot of planning to do, I added it into Altimit Movement for the extra walk frames and 8 directions, however the feature creep is real and I need this system for my studio's own project too.

    I'd recommend keeping the pixel movement as its own separate plugin, because the extra frames/8 directions plugins already exist, and most of the other animations can be done simply through events in the editor. Here's a quick example of what I've been working on; all of which was done with your plugin and a simple common event. (This is only a sandbox test map, and the graphics and sound effects are place-holders)
    [embedded media]

    So I've tried using the .XML format to create the Idle and Moving Frames. The trouble being, I only want to use 4 directions, and if you don't assign the diagonal directions in the .XML file, it will revert back to the normal default sprite when moving or facing diagonally.
  2. Ace of Spades said:
    I'd recommend keeping the pixel movement as its own separate plugin, because the extra frames/8 directions plugins already exist, and most of the other animations can be done simply through events in the editor. Here's a quick example of what I've been working on; all of which was done with your plugin and a simple common event. (This is only a sandbox test map, and the graphics and sound effects are place-holders)
    ...

    So I've tried using the .XML format to create the Idle and Moving Frames. The trouble being, I only want to use 4 directions, and if you don't assign the diagonal directions in the .XML file, it will revert back to the normal default sprite when moving or facing diagonally.
    Wow that's an impressive video! Nice work there.

    Yeah that's a limitation I didn't really address properly. There's some work to be done on the extra frames, it's already integrated a lot with Altimit Movement. I guess I'll try extracting it out now and see how well that goes and then re-address the idea of making it a separate Plugin.
  3. @xilefian I would support that. Additional frame support isn't really a requirement for a pixel movement plugin, and I'm not a big fan of omnibus plugins- I'll take a slightly longer plugin list for more modularity and less bloat from unused features. It should also make debugging and maintainance much easier.
  4. Doktor_Q said:
    @xilefian I would support that. Additional frame support isn't really a requirement for a pixel movement plugin, and I'm not a big fan of omnibus plugins- I'll take a slightly longer plugin list for more modularity and less bloat from unused features. It should also make debugging and maintainance much easier.
    Alrighty then I'll up the priority. Discussion for the extra frames API will be held on the Github still: https://github.com/AltimitSystems/mv-plugins/issues/22

    When it is removed from Altimit Movement I'll make a topic for the new Plugin, for now discussion can be had in the Github.

    I've got some cool ideas on how to do the API, including the ability to write Javascript logic to select your animation frames. I was toying around with XML state machines and it got very unruly; it's much simpler to just allow Javascript to be used and provide an API interface for that.

    EDIT: Okay some good news, I did a test of gutting the animation system; it can be removed easily and cleanly, so that's great.

    I've started work on the new system to replace it, once it has feature parity with the old system (need to figure out animation timing and sort out how states are handled) I'll update Altimit Movement to remove the old system.

    EDIT2: I've now separated the extra frames module. Altimit Movement is now at beta 0.50

    I'll be making a new thread for Altimit Character Animations.

    EDIT3: Here's the thread https://forums.rpgmakerweb.com/index.php?threads/altimit-character-animations-0-01α.89437/
  5. The pixel movement feels great in game. Havent had much time to test, but one small issue I've found is it seems to ignore restricted regions that have been set using Yanflys Region Restriction plugin.
  6. Lear said:
    The pixel movement feels great in game. Havent had much time to test, but one small issue I've found is it seems to ignore restricted regions that have been set using Yanflys Region Restriction plugin.
    That's because this plugin changes how collision with tiles is handled. There issue was brought up earlier in the thread, if you want to look.
  7. I've been trying to figure out an issue I've been having with this plugin replacing the default $gamePlayer.isMoving() function. I've tried using $gamePlayer._isMoving, but I'm met with errors stating a variable isn't a boolean. Is there a simple way to convert $gamePlayer._isMoving into a true/false boolean, or is there a way to restore the functionality of the default $gamePlayer.isMoving() function?
  8. I'm not quite sure what you're doing that would make JavaScript complain about Boolean typing, but you should just be able to cast the value to a bool like normal? Have you tried seeing what the actual value you're getting is?
  9. Doktor_Q said:
    I'm not quite sure what you're doing that would make JavaScript complain about Boolean typing, but you should just be able to cast the value to a bool like normal? Have you tried seeing what the actual value you're getting is?

    The console log shows that both $gamePlayer.isMoving and $gamePlayer._isMoving return false, even when the player is moving. After looking at the plugin, it appears that line 868 is what's overriding the original function.

    Spoiler
    var Game_CharacterBase_isMoving = Game_CharacterBase.prototype.isMoving;
    Game_CharacterBase.prototype.isMoving = function() {
    return Game_CharacterBase_isMoving.call( this ) || this._isMoving;
    };

    I'm not sure if it's possible to retain both functions without breaking this plugin, or if there's some other work around, but I'm open to suggestions.
  10. Hey! I am running into a problem, where it will trigger two action button events at the same time, when they are standing next to each other. Is there a way to prevent that and only run one of them?
  11. I have some suggestions/feature requests for the this plugin.
    • Make it so we can use event notetag and comments to define it's collision collision (Perhaps a pointer to a preset)
    • Secondly make followers trigger the Event/Player Touch page condition.
    I might contribute to this plugin myself If I get far enough into my current project. Follower Touch would make how I am going to do encounters much better.
  12. BorhilIan said:
    Make it so we can use event notetag and comments to define it's collision collision (Perhaps a pointer to a preset.

    That one already exists and seems to work perfectly fine. It's not documented in the plugin itself, though. In fact, that's the entire usage of the presets.

    BorhilIan said:
    Secondly make followers trigger the Event/Player Touch page condition.

    This is a good idea, but it should definitely be a per-event setting. I don't want followers tripping move commands or cutscenes.
  13. After using this plugin for quite a while now, I ran into this problem:
    While Altmit Pixel Movement is enabled, any plugin that depends on region ID's won't work. E.g. Yanflys Region Events, Ryuusa_FootstepSE, and so on. Any workaround for this?
  14. First thing I did was I modified the way region IDs were checked, since region IDs wouldn't work at all even with vanilla events.

    Code:
          var Game_Map_regionId = Game_Map.prototype.regionId;
          Game_Map.prototype.regionId = function( x, y ) {
            return Game_Map_regionId.call( this, Math.floor(x), Math.floor(y) );
          };

    Now, this will make regions work again. However, the regions are now being taken from the top left of the character sprite, way outside its region box. To fix this, we'll have to put the region check in the center of the collision. In my case, I use the circle collision, so my code would look like this:

    Code:
    Game_CharacterBase.prototype.regionId = function() {
       if(this._collider) {
           return $gameMap.regionId(this._x + this._collider.x, this._y + this._collider.y);
       }
       return $gameMap.regionId(this._x, this._y);
    };

    To make this work without creating a new plugin, you can use Scriptlets and create a Scriptlet on Initialize (with condition set to true).

    http://pivoo.me/scriptlets/
  15. I might be having an intensely stupid moment, but I can't get followers to work at all with this. When I put this plugin in a stock project, they just all sit in the center of the screen. The pixel movement itself works fine, and nothing is logged to the console.

    I've used the plugin command to enable follower movement, but nothing happened. I tried starting without extra party members, and adding them later (they spawn in the center of the screen and don't move). I also tried turning them on and off again, and using the Gather Followers event command (which works, but they become stationary again afterwards). I've left all the plugin parameters at their default values. Nobody else seems to be having this issue, so I assume I'm just missing something really basic, but I can't for the life of me figure out what it is.
  16. This looks *wipes tears from eyes* simply beautiful! I'll be sure to use this if I ever go back to working with MV.
  17. Hmmm I have two sort of issues.
    The first one was that I used Events to limit the player from going somewhere (basically using events set to the same level as the player to block the player from going to a certain place) however my character could just go through them, like nothing was stopping him. So I changed Events>Character Collider to "<circle cx='0.5' cy='0.7' r='1' />" (though it's been a while, so maybe it was another line I changed, but I think it was this one). That fixed it so I couldn't pass through them anymore.
    But now a second thing has come up. I have an event that makes a character walk into a bed. So basically just a "move left, face up" movement in an event that's activated with an action key. However, you can stand sort of halfway down the event and then you still activate the event, but you walk left one space too low, making you end up below the bed instead of in it :o Normalize movement is set to "true" on everything.

    Did I do the wrong thing for the first issue, or is there a fix for the second one? Thanks in advance for the help you can give me!
  18. If you want to make walls for the player, you should probably use square colliders instead of circles- the shape is better. Also, I believe there was a javascript command that centers a character within their current tile- you can use this to control where the character is before they start moving around, in theory.
  19. Doktor_Q said:
    If you want to make walls for the player, you should probably use square colliders instead of circles- the shape is better. Also, I believe there was a javascript command that centers a character within their current tile- you can use this to control where the character is before they start moving around, in theory.

    Oh! The square collider might actually be the answer to both questions. I probably made it round and then too big, so that's why you can be basically one space off and that messes the whole movement path thing up (making it so you can access the collision box when you're not on the right space).

    Is it as easy as changing "circle" into "rect"? I'm afraid that this level of coding is just barely out of my comfort zone.
  20. It's not even coding, really- look back a bit in the thread, it should have an example of the rectangle collider.