Quasi Movement

[Quxios]

[Quasi] Movement Version 1.54​

by Quasi​

 ​

--Discontinued--​

This script is no longer supported. Meaning there will be no bug fixes or new features being added.​

 
 
What it does:
   1. Changed how movement works. Allows players to choose how many pixels to move per movement. In better terms, allows players to make characters have a pixel movement or still move by a grid like 32×32 or even 16×16.
   2. Changed how collisions work. Events now have bounding boxes surrounding them. If two boxes touch there will be a collision. Boxes can be set in each event, further detail inside the scripts instructions.
   3. Tiles automatically have boxes set to them depending on their passage ( 4 dir), you can also set boxes to Regions.  Regions prioritize over tiles. (Ex: Tile has no passibility but a region has a box of [0, 0] (no box meaning passable) so that tile will be passable.)
 
New  calls/Functions to know:
 Bounding boxes are set inside a comment in the event, or in the actors note field with the following format:

<bbox=width,height,ox,oy>(ox and oy can be left blank, they can also be negative. )
 
Example:

Spoiler

bbox was changed to be wrapped in <>'s
 
or inside of an actors note tag:

or:<bbox>:main => [width, height, ox, oy]:dirX  =>  [width, height, ox, oy]</bbox>Where X (inside :dirX) is the direction (2, 4, 6 or 8)
Example:

Spoiler

 
You can use multiple event comments to set up each direction :

 

 
 
Bounding boxes can be shown in game by setting line 136 to true. (Only in play testing)
 
New move route function for less move calls.  You use this with a script call inside the move route with the following format:qmove(direction, amount, multiplicity)direction is set to 2,4,6,8 or diag 1,3,7,9
amount is how many times it should move forward in that direction.
multiplicity is multiplied against amount to make it easier to find the right amount
 
Example:

Spoiler

Event moves 64 times down, 224 times right, 64 times up, 224 times left then repeats.
**Was changed from q_move to qmove**
 
Amount times are large since grid is set to 1 but if we use multiplicity we can make it look like:qmove(2,2,32)qmove(6,7,32)qmove(8,2,32)qmove(4,7,32)

 
By default the Px, and Py value are set on the 32 grid where the event was placed.  But we can change the default px, py value of an event with the following comment inside an event:

<ox=#><oy=#>

Where # is equal to an integer.  A negative X value would move the sprite to the right while a positive X value moves it to the left.  Negative Y value would move it up and positive would move it down.
 
Further Instructions:
 Read script header and my site's post.
 
Known Bugs:
 - ??

Terms of Use
 
Links:
Script
Required!
 
Optional links:
Optimize
Demo

 

[Susan]

Looks really promising. I will be trying this script out.

 

[Archeia]

I've been waiting for a script that does the bounding box option! Can't wait to try it out.
EDIT #1: Holy smokes this works like a charm <3
EDIT #2:
Something seems to be funky with followers when you are doing diagonal movement:

 

[Quxios]

EDIT #2:

Something seems to be funky with followers when you are doing diagonal movement:

Oh I forgot about that one!  That's also a bug dealing with the movement speed change, I'll add it to the list of fixing.

Also I found out I forgot 2 passability auto tile flags, so I'll be adding them in next update.

 

[Archeia]

I was just wondering, how well does it take extra frames for sprites? I'm guessing there's some incompatibilities about it?

 

[Sophism]

I'm very much an outlier, as I have a pretty big map with around 200 events spread over, so take this with a grain of salt.

The script completely tanks my performance. This includes running into a solid wall without any diagonal movement. Setting it to 32 pixel movement eliminated that problem, but when it checks for collision diagonally or along edges it wrecks the frame rate once more. In fact, moving diagonally period could lower FPS from 60 to the low 40s even when not checking for any collision. It also seems to have disliked my parallel process that checks for the player's x and y location, as it would just crash every time until I removed the event in question.

Overall, the movement also had two small quirks during my testing. The first was how the diagonal speed value didn't actually seem to impact speed; I tried changing it to -2, -1, -0.75, -0.25, 0, and 2, and none of these values appeared to do anything. The second probably has something to do with using any lower than 32 grid movement, as it basically made dashing a negligible speed increase, even when moving only horizontally or vertically.

I really like what you have here though. It's probably the first pixel movement/diagonal movement solution I've tried that felt just right when handing corners and one-tile wide entrances. Not to mention the hitbox configuration being pretty easy to change on a per event basis. May I suggest having an option to not use the player's collision settings as the default for every event though? Maybe a toggle that instead makes events have a blank collision unless you set them up for one?

Thanks for this cool script. Even if I can't use it in my current project, I'd love to try it out on the next or any smaller side ones. 

 

[Quxios]

@Archeia

Not sure, haven't test compatibilities with other scripts, if any are to appear I'll gladly fix them.  And extra frames as in higher frame rate or like more then 3 frames per move?

@Sophism

The performance is something I'll look into asap!  As for those x, y parallel process is also a bug I recently found which is caused because I left them as a float (I think that's why)

Speed was changed from the default so I may have broke something, I'll do some testing on that.

And sure I'll add in a default event box instead of events using default player

@Sophism I also have a question for you, I forgot to test this on large maps.  Was there any lag loading in the map?  Since I made it so the tile collision boxes get created once you enter the map.  So that method has to go through every x,y on that map to check each passability.

Thanks for the replies!

 

[Sophism]

I didn't notice too much lag loading the map. At least nothing higher than my usual 1-2 second(s) load, no.

 

[Susan]

This script is really good!

Collision can even be set to more than 32 pixels thus eliminating the need for multiple events to achieve the same result.

This is great for achieving line-of-sight events as well.

Are the 'Tileboxes' section in lines 123-138 related to the tileset or something else? If so, will you be making it possible to set separate collisions for different tilesets?

The odd thing about the Region Boxes is, if you set one with [0, 0] to a tile that has no passability, the player can somehow pass through the impassable tiles next to it too (in limited capacity).

It has been mentioned earlier, but the followers' speeds are much slower compared to the player when moving diagonally. They tend to get 'caught' and slowed down by collisions because of that.

Also, once the party leader has moved out of the 32 x 32 grid, the follower(s)'s movements become very weird and jerky while trying to catch up with the party leader

I tried this script on a 300 x 300 map with only one parallel event and a few action button trigger events with no slowdown. Even setting huge collisions did not cause a slowdown.

Will you be implementing 'show boxes' collision for the region and tiles too later on?

I know this is asking a lot, but are you planning to implement dynamic collision changes for events one day?

For example :

The event is 64 x 32 pixels when looking up or down. Collision has been set accordingly during eventing.

When the event turns left or right, it becomes 32 x 64 instead. In the current script version, the collision will still remain to detect 64 x 32. Will it be possible to change it at the time of movement to 32 x 64? I tried conditional branches to try this, but received an error due to conflicting collision settings.

I will testing this script out some others later. Excellent work!

 

[Quxios]

The tileboxes relate to the tilesets passage (4 DIR) as well as the passage for autotiles.  Not sure I understand that issue with the regionbox correct.

As for showing boxes for regions/tiles, that might be a little trickier since I wrote it for the boxes to only exist when checking for collisions , but this may be one of the issues causing lag for Sophism, so I'll see if creating all the tile and region boxes on map start instead would be more efficient.  If it does work out then I'll be able to add an option to show those boxes.

That's a pretty good idea!  I'll add it to my list.

As for the lag, I've added in 2 extra settings which you can turn off/on.  One is for "Smart move", which should only be true if you're doing pixel movement.  What this does is whenever you try to move, if it failed it will keep trying again at lower speeds until speed reach 0 and then return move failed.  So with pixel movement this allows you to get even closer.  And the other one is for "MidPass" which checks if the passability of the midpoint from that move, which is more useful with higher grids like 32 grid.  With a small box there's a chance that you can walk over a small box because before you moved you weren't touching and after you moved you still aren't touching.  With 32 grid you should be using bigger boxes anyways.  With these both set and true on a big map with like 50 random events scattered I was getting like 20 frames with diagonal movement and like 40 when standing still, with them on false I wasn't getting lower then 30 and was pretty noticeable difference.

I'll probably put up the updated one sometime next week.  Still need to look into the follower issues.

 

[Susan]

Cool! It looks like you have very high ambition for this script!

Regarding the problem with the region boxes passability, I have uploaded a minimalistic project with the passable region box set into the lower forest so that you can check out what I mean.

https://www.dropbox.com/s/163mfa9mhtygn3g/Region%20Passability.7z?dl=0

Thanks for the great script!

Off topic : Your Screen Scrolling script appears to be inaccessible.

 

[Quxios]

@susan - Oh my site just had a bad link, it's fixed now.

Updated version is finally out!  I was planning on releasing it on thanksgiving but ending up getting really sick over the weekend and didn't get to finish the new instructions.

The links are the same and have been updated with the new version

Movement

Quasi Module

(New version of the quasi module is required, since there was a bug with the event comments only reading the first line)

Quite a bit of changes in this last one.  I changed over the tiles/region boxes to be created at the start of the map instead of when you step on them.  Which allows us to display them now and fixed some bugs.

Added Susans suggestions to allow different box depending on the events direction.

Started to work on followers, the distance is now fixed, but they don't exactly follow in a line.  Just need to add a straightening method.

Plus a bunch of other smaller stuff added in.

 

[Susan]

Hope you are feeling much better now, Quasi.

I saw your links, thanks!

Great job with this script!

Tested out your latest version :

Working:

Dynamic collision boxes changes appropriately.

Bounding boxes for tiles and region boxes are now visible.

Region boxes work properly now.

Followers appear to follow the leader at a proper speed.

 

Bugs:

Event boxes with above or below player priority blocks player movement.

Followers tend to walk right through tiles with collision if they are diagonal from the player.

 

[Quxios]

Felling much better!
 

Event boxes with above or below player priority blocks player movement.

 - Fixed!  Thanks!  I honestly would probably have never noticed that and I feel that's used very often!

 

Followers tend to walk right through tiles with collision if they are diagonal from the player.

 - Followers actually have through set to true by default, Since it assumes the follower will take the exact same path as the player, which should have been collision free.  So this shouldn't be noticeable once I straighten out followers so they're following in a line again.  Thinking of adding a bbox note field for actors so you can have each actor have a different box, but that'll bring up this problem again if a follower has a bigger box then the leader

 

[Archeia]

Super excited to test this out

 

[Quxios]

Alright updated version is up.

- Fixed event priority (hopefully, not even sure how exactly they work lol)

- Following is more accurate

- Random move works again

- Added some vehicle support, still buggy when getting on/off with pixel movement

- Made a simple optimization script.

 

[Susan]

The Event priority work very well now!

Event trigger while in the ship or boat works properly.

Current issues:

[SIZE=14.4444446563721px][/SIZE]

Spoiler

Quasi Movement v1.1.5 script:

- Vehicles

-> Cannot move when disembarking from the ship or boat from the up and left directions. [SIZE=14.4444446563721px]Adjusting the bounding box size and x, y coordinates does not help the issue.[/SIZE]

-> Continuously boarding and disembarking the ship or boat while moving the same direction will 'move' the vehicles as well, until they are out of the water.

-> Although followers' bounding boxes appear while in the vehicles during play testing, there is no adverse effect regarding 'event touch' priority events (just mentioning here in case someone else reports this as a 'problem').

Quasi Optimize v0.5 script:

- states that is is missing an 'end' in line 273. After placing one at the end of the script and play testing, the game crashes with a 'stack level too deep' error.

This is an excellent script.

Sorry to to always post bug reports, Quasi.

Side note:

Spoiler

"Quasi Shop" and "Quasi Title" scripts state that they need the "Quasi Core" in order to run.

Quasi Core v0.4 has been installed above all Quasi scripts with no other 3rd party scripts.

 

[Archeia]

Quasi, just a question since I didn't see it in the instructions, is there a way to see a region's collision box?

 

[Susan]

@Archeia:

The bounding boxes for regions show up on the map as well when the 'Showboxes' in line 148 is set to 'True'.

Setting it to 'False' will remove all visible bounding boxes.

 

[Quxios]

@Susan - No need to be sorry I really appreciate it!

Also for that optimize error, that seems really weird because I noticed that like 2 minutes after I had uploaded it and fixed it right away, but I guess you somehow managed to get the one before my quick fix lol.

As for quasi shop, that was rewritten to work with quasi module instead but apparently I forgot to add it to github, but here it is now! -link-

-> Cannot move when disembarking from the ship or boat from the up and left directions. Adjusting the bounding box size and x, y coordinates does not help the issue.

-> Continuously boarding and disembarking the ship or boat while moving the same direction will 'move' the vehicles as well, until they are out of the water.

Both these are related to the same problem which I just needs revision in the math for finding the distance to get on / off the ship.

-> Although followers' bounding boxes appear while in the vehicles during play testing, there is no adverse effect regarding 'event touch' priority events (just mentioning here in case someone else reports this as a 'problem').

Yeah does look pretty funny, but it should be harmless.  The issue with this is that I didn't add in any update for visibility on the show boxes.  So on that case I'm guessing if you add in a new follower the new followers box wont show up.