UBON'S PROFILE

author=halibabica
I wish people were smarter in general. ._.

be the change you wish to see in the world

you've still lost me but I'm pretty sure by now this doesn't matter at all

so do whatever

author=Archeia_Nessiah
for a moment, I thought we're discussing about how RMN can be translated into an anime.

Dibs on Liam O'Brien for my portrayal.

Hello, loves!

So first off, I'm afraid this is a fairly tall order. Besides the jump from RMXP to RMVXA, the only version of this script remaining on the internet is a release candidate and there appear to be some bugs. There is a link to a version that appears to be more up to date, but whether it's still there hinges on whether or not rpg-palace ever comes back online.

Second, let's get this rolling. I'd like to preface this by saying that while there are a decent variety of pixelmovement scripts already on the forum and I greatly respect their creators for undertaking the difficult task of coding them, every single one is created with the graphical complexity of your typical RMVXA RTP game in mind -- which is to say, there is very little control over tile collisions, and everything is generally presumed to be a large cube of some sort. I believe that the adaptation of this script could be of great benefit to those who, like myself, are including a little more variance and complexity in their terrain. For this reason, I'm going to ask that the end result be publicly available under the same terms f0tz!baerchen initially released with, with no particular terms limiting other users' permission to further modify the script. The specific details can be found on the script's download page, which I will link shortly. f0tz!baerchen himself provided a special proviso for commercial projects, the largest point of which is that the user needs to contact him before using the script commercially. Depending on his current availability, this may unfortunately mean that the script would not be viable for commercial projects. It may be prudent to make special note of this in the final product's release topic, considering the increased popularity of commercial development compared to how things were five years ago.
 
the basics
For starters, the script can be downloaded here. You have to click "Demo", the second link -- "Download" doesn't work, for whatever reason. A more complete program might exist at this address, but the site hosting it is presently down for maintenance and I'm not certain when it'll be back, long since having lost touch with rey meustrus.

This is the full demo for the project, and contains the script in the game's editor. You need RPG Maker XP's RTP to play the demo, and at least a trial version of the program itself to open the project file and get at the script. If necessary, I can download the RMXP trial on my other computer in order to extract the script and put it up here. However, I heartily recommend you at least play the demo, as it gives a fairly good overview of the program's functioning. It is still, however, possible to cause an unplayable state in at least one point, by walking diagonally into the outside of the log-lined arrow track in the snow map -- at which point the player is rendered immobile. Multiple builds may become necessary, depending on the tendency of these bugs to crop up.

the features
In the interests of making this request as helpful as possible to anyone who decides to take it up, I'm going to list what I understand to be the script's features, divided into what I consider absolutely necessary and what can be done away with.

the important stuff

• Pixel-based movement and collision - Naturally. Movement is done on a per-pixel basis in eight directions, rather than locking movement to a grid in four. This script allows the user to define the dimensions of a given event for purposes of collision using comments. The "shape" of an event's collision is circular, making events approachable from the diagonals as well as the sides. Additionally, this script supports eight-directional charactersets.

• Image-based collision masks- This is the single most important feature of this script -- the aspect which sets it apart from every other extant pixelmovement script, and the reason why I requested this conversion in the first place. f0tz!baerchen's pixelmovement script draws its collision masks from a separate black-and-white image created by the player, allowing for different tiles to have shaped collisions. Collision masks can be provided for complete tilesets, or for individual maps -- the latter being a massive benefit to developers using parallax mapping.
  
  An important side-note: this system of collision masks allows for diagonal and curved surfaces, which the player character "slides" along if the direction of his movement is at an angle relative to the surface he encounters.

the not-so-important stuff

• Pathfinding - Allows the user to path the player automatically to a certain event or tile. Seems to have a great deal of general utility, but the time the original script takes to calculate a moderately long path makes me think that there are probably better options.

• Forced-movement tiles- Tiles that push the player in a certain direction. Think the Rocket hideout from the first Pokemon games. I can't think of a situation where I'd find them useful, but maybe someone else could use them?

• "Ice physics"- If the player steps onto tiles of a certain ID, they keep moving in that direction until they hit a wall or it takes them back onto normal ground. I'm not crazy about this in games, and it seems odd to include as a hard-coded part of the system.

• True isometric options- Allow the user to alter the angle at which diagonal movement occurs, to simulate maps viewed from an isometric perspective. Seems fairly niche.

There's a bit more, but it's so unnecessary that it didn't even come up in the demo. I'm going to attach f0tz!baerchen's full readme containing a basic rundown of each function, in case you're curious.

the things to watch out for
This is just gonna be some things I've noticed and thought about regarding this script's adaptation to the new set of capabilities the RMVXA editor has. I'm no scripter, so feel free to ignore this bit entirely.

• In RPG Maker XP, passability and a tile's layering priority were handled differently. However, in RMVXA, a tile with an "above player" priority is automatically passable. Ideally, this script would recognize layering priority as defined in the tileset editor, but ignore the passability.

• This script comes with a caterpillar system and a dash button. Both already exist in RMVXA by default, so this should hopefully be easy to integrate.

• There's also an integrated antilag script of f0tz!baerchen's own design, which I hope doesn't cause too much trouble. I can't really say, one way or the other. Hopefully it's not super-entrenched or anything.

I might add more as I think of them, but I already feel as if I'm being sort of a backseat driver.

the last bit
This isn't really much of a last bit. I'd just like to sincerely thank whoever decides to take this up, since as I've said before this could be a pretty huge deal for anyone who'd like a little more versatility in their pixelmovement (albeit at the tradeoff of a great deal more setup time). If I could make one last request, I'd like it very much if anyone who'd like to take this up would let me know once they start working on it, and pop in every now and then to share whatever details or hurdles they find interesting. I'm just kind of a nerd, and I love dev journals. You don't need to humour me by any means, though.

I think that's it. If there are any other details I might be able to offer, just let me know! I'll do whatever I can to help get this thing in working order for VX Ace. Tile-based stuff just doesn't do it for me.

it doesn't look good, is the thing. those tiny Kaduki characters and tiny Kaduki-compatible monsters take up maybe a twentieth of the screen, and the huge amount of wasted space is not nice to look at, especially considering the questionable quality of many of the battlebacks. I'd find some way to use the space more effectively, for one thing, whether it's using larger sprites or changing the interface or what have you.

I think we already talked about a lot of the things that could be changed about Legionwood and so I'm not gonna restate them here, but it's good to know you're really turning an ear to these complaints! good luck, man.