Quasi Movement

[Quxios]

atm, you can use a script call qmove(direction, amount, multiplicity) by default multiplicity is set 1 and can be left out, but you can do something like:

qmove(4,3,32)qmove(2,6,32)and if you're in pixel movement that'll be equivalent to moving 3 * 32 tiles to the right then 6 * 32 tiles down.  I recently added the multiplicity in so I need to change some of the documentation on that.  But now that I look back I noticed I was dividing by speed instead of move_tiles which will give incorrect number of moves at certain speeds.  Once that's changed, I should probably default multiplicity to grid that way moving 1 amt will be equal to 1 grid move.

Setting a comment before a set move route to set the multiplicity seems likes a good idea too, probably much simpler for most users too.  I just made qmove so it can be used in the autonomous custom move route.

 

[Tsukihime]

Thanks, I like the qmove solution.


Do you have any suggestions for this?

Spoiler

Script: https://gist.github.com/HimeWorks/354167773c8d79e90c9c

The size of the box currently doesn't seem to take into consideration scaling (via zoom)


There are other scripts that change the size of the sprite via zooming as well (since the zoom function does a good job with scaling).

 

[Quxios]

Oh that looks cool, I'm curious if the collisions still work properly?

As for the boxes I never thought of zooms but you can go to the bottom where the sprite methods are, around line 1547, you'll see def start box and at the bottom of that def you could probably add something like

@box_sprite.zoom_x = @character.zoom_x@box_sprite.zoom_y = @character.zoom_yBut I'm not too sure how that'll affect the boxes positioning.  Those box sprite methods are pretty sloppy too, kind of just threw them together and didn't work on it much since it wasn't much of a priority so be warned

 

[Tsukihime]

The zoom is a visual thing, whereas the collisions are logical, so the collisions wouldn't occur properly.

Here's what I tried

class Sprite_Character alias :th_y_distance_zoom_update_box :update_box def update_box return unless @box_sprite th_y_distance_zoom_update_box @box_sprite.zoom_x = self.zoom_x @box_sprite.zoom_y = self.zoom_y endendAnd the boxes resize properly, but the detection still uses the actual box size.I'm not sure what would be easier: simply adjusting the logical size of the box (and then re-drawing the bitmap), or incorporating the zoom calculations into the collision detection while adjusting the size of the box via zooming (no re-draw)

Either way we'd have to figure out how to do the zoom calculations and how the box would need to be re-positioned so the latter sounds better in terms of performance.

On another note, I'm assuming the Dir8 flag would be used here in CharacterBase

def dir8enable? return falseendThere is also a bug with custom autonomous movement.By default, when you trigger an event, it will turn towards you and wait.

However, with the qmove, it will just continue to move.

 

[Quxios]

Yeah wasn't sure if the zooms would also "zoom" the x and y values to make them act the same.

I would try to change the box size whenever the zoom occurred.  Would have to change the bounding_box method inside Game_Event and Game_Player and put something like:
 

alias :bbox :bounding_boxdef bounding_box bb = bbox # bb = [width, height, ox, oy] bb[0] *= @zoom_x bb[1] *= @zoom_y @boundingbox = bbendnot sure if that's written correct just doing it off the top of my head, you might also have to adjust the offsets, unless the boxes top right position was in the correct spot when zoomed.

Then somewhere in your zoom method you would have to set @boundingbox to nil so it can get created again, and set the @zoom_x and @zoom_y values.

But not really sure if that would work, if it does that'd be amazing easy lol.  

For that dir8enable? it's a method that can be used for an addon for like 8 dir sprites, if you set it to true, direction can be set to 1,3,7,9 as well.

Example from my dir8 sprites:

class Sprite_Character < Sprite_Base    #--------------------------------------------------------------------------  # * Update Transfer Origin Rectangle  #--------------------------------------------------------------------------  alias :qs_sc_updatesrc   :update_src_rect  def update_src_rect    return update_8dir_rect if @character.dir8enable?    return qs_sc_updatesrc  endend

 

[pelvichan]

 This is a great scripts!

 But does anyone else have problem using doors?

 I freeze when using doors. =[

 

[Archeia]

Doors work fine to me?


Maybe you got the player moving up on an unpassable tile. Try checking the box Skip if cannot move on the move event.

 

[pelvichan]

Doors work fine to me?

Maybe you got the player moving up on an unpassable tile. Try checking the box Skip if cannot move on the move event.

 Well even thought that wasn't the problem I want to thank you for the quick response.

 I don't know what the problem was but i made a new project and everything seems to be working properly.

 

[Susan]

Any pixel movement script can sometimes cause your game to freeze depending on where the character is standing (blocked by part of an impassable tile next to the doors), because the character is unable to move in a straight line as what is being instructed by the "set move route" event commands.

Solutions (choose any one):

1) Add a "Through ON" at the beginning of your "set move route" command for the player, and add a "Through OFF" at the end of your "set move route" command.

2) You can set your door to open on player touch or by pressing the action button, and then let the player walk onto the transfer tile themselves before transferring to a map, instead of using the "set move route" command. 

3) Check the passability of the tiles you placed at the doors. Passability from tiles B-E takes precedence over passaibility from tiles A1-A5.

Hope that helps. ^^

 

[Quxios]

@pelvichan sounds weird that making a new project fixed it.  Was the door evented exactly the same?  I also know of a bug that if the player gets stuck inside an event while both they have Through OFF, it will freeze the game and you might have stumbled upon that.

 

[pelvichan]

I couldn't reproduce the error. The door was a quick event and was working correctly but then doors stopped working. I tried using transfers and they worked fine.

That is until i added the door animation move route of the door and the same thing happened. 

But as I said, I can't reproduce the error. I most probably did something wrong I cannot recall. 

 

[Mireneye]

UPDATE: I'm getting it to run on 2 pixels minimum grid. 1 throws the aformentioned error. Now not able to move on the map but I'm assuming it's all down to setting up my maps proper or somesuch. Maybe it's because I'm using two designated tiles to setup collision, because I'm otherwise using parralax maps. How would I find which tiles it is by number and set their collision setting off?

Upon starting a new game (using movement keys in an evented menu on the startmap) I get an error. You can see it in attatched files, I also did some stack tracing so maybe that will tell you more than it does me.

Granted I am running a bunch of other scripts, been trying out different script orders etc, so far seems unable to get it to work. 

If it helps it does display the bounding boxes (as it should for testing) because I can see some of the map events on my makeshift startmap menu. 

Any help appreciated. Would be really nice to give this a whirl and see how it plays in my project.

Oh and I can already tell you put down huge efforts into making this so, mad props! Thank you! ^-^
 

 

[Quxios]

I'm getting it to run on 2 pixels minimum grid.

Even with GRID set to 1, you'll most likely be moving around 2-6 pixels instead of 1.  This is because of the characters move speed, if you set the movespeed all the way down ideally it should move at 1 grid.  This only apply's to low grids numbers.

How would I find which tiles it is by number and set their collision setting off?

Do you mean the number for the tilebox?  You can either eye ball it based on how that box looks like, ex, if its a 32x32 box then you know it'll be one of the flags that have a [32, 32] box, then you can comment then out to see which one it was.  Or the fastest way, how I grabbed the flags is by putting in this snippet:

Spoiler

class Game_Map def flag_at(x, y) puts "Flags at cord (#{x}, #{y})\n" all_tiles(x, y).each do |tile_id| flag = tileset.flags[tile_id] next if flag & 0x10 != 0 # [☆]: No effect on passage p flag end return false endendclass Scene_Map < Scene_Base alias qupdate update def update qupdate if Input.trigger?C) $game_map.flag_at($game_player.x, $game_player.y) end endend

And just walk around the map with debug through ( hold ctrl ), and on the tile you want to know the flags, press C ( enter ) and it'll log the flags on that tile.

Looking from that error log, it looks pretty weird, it crashed when it was checking for an event box.  But it crashed because the event was a fixed number not an event class.  So I'm assuming you might have a script that for some reason is changing @events to be a list of event ids? instead of the actual event class.

I also see you have XAS, is that an action battle system?  If so how does that work with my movement?  I'm just curious since I was thinking no action battle system would work with my movement without some sort of patch.

 

[Mireneye]

UPDATE: It seems the tiles I'm standing at that do not allow movement are set at the number 1536, so I added it to the TILEBOXES array, first in the list. What numbers should I add to it? Not certain I understand this function. 

XAS is an ABS yes. When I get it to run at all I still can't move around maps, but from what I can tell by trying out the combat is that by hitting XAS copies an event from an event map, this is your weapon or tool. This tool or weapon will get displaced oddly, I'm thinking it's internal placement needs to be modified/multiplied by whatver multiplier you are using for the move-routes. 

When I mean "To run" I meant that before that the script would crash in another way. I might look up what later.

The error seemed to stem from Victors base script, from what I understand. It had this snippet, which would make sense based on your description.

  def map_events #Miredit

    @map.events

  end

I won't ask for compability fixes and what not. I just hope to enlighten you as to how it seemingly interacts with other scripts.
Best of luck with your work!

 

[Quxios]

If the tile flag isn't in the list, then the script assumes it's an empty box [0, 0] which just means it's passable.  So the impassibility is most likely from a compatibility issue.  And yeh the reason I'd assume ABS wouldn't work with my pixel movement is because I added a new cords which are px, py for the pixel points, unlike a few other movement systems which still used the old x and y but changed them to floats so every pixel movement was 1 / 32.0, but I wasn't really fond of that and wanted to see the actual pixel location values.

And oh yeah that is the source!  Didn't think any other script would use a method named map_events lol.  I'll rename the method in my scripts in the next update.  If you want to do this yourself, go to my movement script, replace ( ctrl + H) "map_events" with "map_events_values".  Do this for my optimize script as well if you are using it.

 

[Mireneye]

Excellent ^-^

So I'm just being silly. While poking around at the script I had commented out @velocity which broke other stuff. Removing it I get the script running in my project. COOL!. It's surprisingly well working, it will definietly need some patching up, but It's something to work with ^-^

Motion is a bit jerky on 2 and 8 pixel move. Havn't tried other settings yet. 

In XAS after killing an enemy (ANY enemy it seems), I get a crash: http://imgur.com/Y1Mc8rd. May this be because XAS is disposing of an event that your script is accounting collision for? just a loose idea.

And XAS's hookshot skill type is entierly broken, I suppose because it can not scriptwise reach it's end destination and therefore does not terminate, catching the player in the motion. 

[SIZE=14.2857141494751px]EDIT: Would it perhaps work if I went into XAS hookshot script to replace whatever move function I suspect is in there with Qmove?[/SIZE]

Just thought I'd update on the process. I really like this idea and It'd be a neat thing to implement and get working. So far you've been wonderful help, thanks!

 

[Quxios]

Yeah this script probably doesn't work to well with funky moves.  Should stick with either a grid of 1, 16 or 32.

That crash might be if the direction when that passability check ran was anything other then [2, 4, 6, 8].  I've fixed the direction problem in my projects version but I haven't updated it yet because there's still a small bug I'm trying to iron out.

No because qmove() isn't a real function, it's a psuedo function that just acts as a placeholder so you can type that inside the move route.  You'll want to look inside the hookshot and see if it has it's own passability function, if it does then you'll need to modify that to match the passable? function from my movement.  My movement checks tiles with tilebox_passable?(pixel_x, pixel_ y, direction) and checks for character collision with collide_with_box?(pixel_x, pixel_y) both those methods will cause a crash if that hookshot doesn't have a box though.

 

[Quxios]

Update!

Finally had time to finish up rewriting the latest version.

https://github.com/quasixi/RGSS3/blob/master/System/Movement.rb

Don't forget to change Quasi Optimize (a method was renamed for compatibility issue!)

https://github.com/quasixi/RGSS3/blob/master/System/Optimize.rb

Whats new:

• Highly optimized compared to the previous version ( according to some bench-marking it's around 4x faster )
• Collision Maps is built into this so no need for the extra script!
• Random move is much better and safe to use!
• Bounding boxes were changed into a class, so if anyone did any edits instead of doing something like bounding_box[0] for the width, it's now bounding_box(direction).width or just bounding_box.width (direction defaults to the current facing direction)
• Lot of collision checks were rewritten to increase performance.
• OPT feature from collision maps is fixed ( never noticed I had a typo in it before! ) 

 

[Archeia]

Aaah! So excited. Can't wait to try it out

 

[Mireneye]

Hahah super cool! It's actually playable with XAS now as long as I don't die it seems (probably due to my own tinkering with the dead mechanics of the project). The tool placement is funny ofc, but it works surprisingly well at some points! 

Now that I could check out the other maps I could confirm what I thought. The script does run a bit heavy on my already heavy maps, as to be expected. I take it it's a result from multiplying up all those move-route commands to run every pixel.

Sad because this is a BEASTLY AWESOME script!

I might try to design my next project around it, maybe then I'll be able to tinker out a way to optimize everything together ^-^ 

WELL DONE!