Charlie's Mini-Map Extended

[DerVVulfman]

BUMP
to version 1.5

Oooh... It's painting properly now!!!!

Characters didn't fully line up in the mini-map where the actual passable tiles were involved.  That had to be altered.  Not only that, but there were discrepancies in positioning between 'sprite' based objects and 'rect-filled' objects.  Neither were properly aligned, this alignment not counting the actual camera zoom and tile size of the current map.

Tell me I didn't have fun figuring this out.

 Well, now the system will properly figure out and position all the map objects (the hero, your enemies, any allies, etc) in an exact position on the mini-map and be properly lined up to match the passable map's contents.

*  *  *

  Oh, here's a note.  After generating your maps, you may wish to change the palette from RGB to something like 256, 128 or even 64 if you don't have as many collors in the map render.  A very large rendered map (a big map) shrunk from 1.7meg to less than 450 with it turning into 256palette. less than 400 at 128.

[DerVVulfman]

BUMP
to version 1.6

One more little bump, and not really a bad one.

If you are not using image sprites to render your player and/or events, you used colored rectangles.  However, the rectangles had only two sizes... Small or Large.  This is limiting.  And I hate limits.

So now the system allows you to set the size of the rectangle for each event-type.  True, this changes the EVENT LISTS section of the configuration page, but it certainly makes it more customizable.   Events may now have tiny rectangles (2px X 2px) or larger ones (16px X 16px).

Enjoy.

[DerVVulfman]

BUMP
to version 1.7

Okay, one more update. But a fun one with two new features!

First feature is actually a fix. Ever since the original version, a mini-map gets generated whenever you enter a game map. Now this might not be desired. Even with a setting to make a map not show wasn't enough. But now, the system will recognize if a map is set not to show a map will now NOT GENERATE THAT DANG .PNG FILE!!!

And the Second feature is a measure to let the mini-map change position by itself. Sure, you set a position in the configuration page. But now it can shift to the opposite side of the map if you get too close to a map edge. If you reach the left edge of a map, it can shift to the right edge. And visa versa of course. Even a vertical shifting option may be set, though that does look a bit weird in my opinion. Still, this is an option that you can choose to use or ignore.

Happy mapping!

[DerVVulfman]

BUMP
to version 1.8

A couple of minor error-blocking checks have been added to the script itself along with a means to ensure the mini-map is only visible when desired.

Meanwhile, I split off the list of patches into a new post... I was hitting the post-charactersize limit. And with the separate post for patches, I added a new patch.

The new patch I added allows you to hide the mini-map when you are using a menu that uses the field map as a background. It should be useful for anyone who uses the fieldmap as a battleback, or it can be used to let one see how to hide the mini-map if they are using a new script that renders a new menu feature that shows over the fieldmap.

[DerVVulfman]

BUMP
to version 1.9

This is a minor update, a minor fix for those who are using Panorama graphics for their map rather than the tilesets. Oddly, not all map objects from the mini-map would vanish under some very specific conditions, so this new update handles this.

The Main Header and Configuration page need not be replaced (except the version number and date if you want to bother).

[DerVVulfman]

BUMP
to version 2.0

Well, we have an update and a fix combined....

The mini-map has a feature where the map can shift from one corner or edge to another if you get too close to one side of the map. This allows you to make sure certain items or events do not get accidentally hidden by the mini-map itself.

Well,  I just added a little 'buffer' option which can be adjusted with the newly created "DIST_SHIFT" configuration value.  So now the switch doesn't happen IMMEDIATELY after  you cross the center of the map.  Well, it's currently set to '2' so there is a 2-tile difference from the center on either side.... either horizontal and/or vertical.  Your choice.

As to the fix, there was an issue where the mini-map and its border background didn't line up.  Normally, they line up.  But if the player's mini-map shifted from one side to the other and then used a teleport to switch to another map, the two could separate.  Well... that sucked.

However, I noted that some formulas in one method were not 'exactly' replicated in another method.  The two methods were related to either mini-map and the border.  Once the two were made to match.... the issue of shifting mini-map borders was resolved.

[DerVVulfman]

Yes, I know. Another
BUMP
to version 2.1

Mini-Maps operate on the idea that they can show you areas where you may walk, and areas that you cannot pass. But nearly all of them may also display and track events that are near the player, and see what makes them different. This event is a treasure, that event is an enemy, this one is a friend, that one is a door.

Until now, there was a little hangup with the system and how it identified an event as one that could be drawn within the mini-map. To be more specific, if you opted to change the name of an event to that of a mini-map object, you had to be specific. No other content could be in the name of the event. That is until now.

Assuming you designed a Mini-Map object who's key/name is 'Teleport', you were only able to have the name of the event be 'Teleport'. That, and that alone. But now the system looks to see if the name of an event includes the key, so you may have an event with the name 'Brightridge Teleport', and it will be fine.

If you instead opt to use comments to identify a mini-map object, the system still requires that the comment hold only the object's name alone. But that's fine by me.