Secret of Mana, Turbo - Beta 231108

[lexluthermiester]

Recently SNES emulators (bsnes, mesen-s) have introduced the overclock function which may help.

Unfortunately many others do not. Most actually.

[Chicken Knife]

A small request! I've done some playing with an aggressive selection of included hacks but given the way I am, I've shifted gears to building a conservatively tweaked version of the game with all the bug fixes and a few conveniences that don't alter the game much. The fact I can do this with your project is absolutely wonderful. One of the conveniences I'm using is the change directions while running hack. Since I'm still using the stamina system for combat, running continues to trigger stamina use which makes me have to wait at times before dashing or wait to attack after dashing. I think it would be great to have an option to make dashing not effect the stamina guage at all, just like in Trials of Mana.

**EDIT

Strange issue: when cycling through the rings, the item rings are not coming up even though the weapon and config menu rings are coming up just fine. I applied the option to store up to 9 items as well as the boy not taking nuts.

[Queue]

A small request!

It looks like it'll be a 4-byte change to make running not check stamina before activating, plus the 3-byte change to make it not cost stamina. So yeah, that'll be in the next release.

Strange issue: when cycling through the rings, the item rings are not coming up even though the weapon and config menu rings are coming up just fine. I applied the option to store up to 9 items as well as the boy not taking nuts.

Can you post your SoM Turbo.ini file, either to somewhere like pastebin.com or here in spoiler tags? I think that'd save some trouble on back-and-forth questioning to figure out what combination of features being on and off is causing that.

Off the top of my head, the main feature that could affect item ring visibility is Bug_Fixes\No_Blats_To_Sell, especially if mixed with some combination of Items\Item_Limit_Increase and Technical\Validate_Items.

Quality_of_Life\Boy_Dislikes_Nuts shouldn't be relevant (it changes the code when you use an item, which shouldn't affect item visibility, which is likely what's affecting the item ring not showing).

Okay, thinking this through, it has to be the combination of No_Blats_To_Sell and Item_Limit_Increase. Item_Limit_Increase changes the format of owned item data (from 3 bits quantity, 5 bits ID, to 4 bits quantity, 4 bits ID), and No_Blats_To_Sell checks for invalid owned item data (if the item ID is >= the max valid item ID). I'll verify that this afternoon.



Edit to link new version.



Version 2019-08-11:
https://ufile.io/cdffjy7o

Changes:
- Implemented Balance\Run_When_Tired
- Implemented Quality_of_Life\Inverted_Ring_Menu_Rotation and Quality_of_Life\Inverted_Shop_Menu_Rotation (both off by default)
- Implemented Bug_Fixes\Northtown_Ruins_Better_Rope
- Implemented Technical\Fake_50Hz (off by default, this one's sort've a joke feature)
- Quality_of_Life\Run_On_Trigger_Tiles now includes running on stairs (since running on trigger tiles didn't work without it)
- Compatibility fix between Items\Item_Limit_Increase and Bug_Fixes\No_Blats_To_Sell

Technical Changes:
- Two new FastROM JSR patches and three compatibility fixups
- A handful of minor optimizations
- Changed mnemonics for event commands 0B, 0C, 0D (related to Magic Rope Door)
- Implemented event command 3E, Set Rope Door, for Northtown_Ruins_Better_Rope
- A few more compat markings for documentation purposes

[Chicken Knife]

It appears to be a perfect fix with the item rings and the running. Thank you for tackling this so quickly. I'm in the mood for a complete playthrough so I'll let you know if I come across anything else.

** EDIT

I'm really asking a lot now, but there's one last tiny thing to make the dashing exactly like Trials of Mana: would it also be a relatively painless fix to only have dashing activate when you are holding a direction and the A button? In other words, it would be cool if you didn't automatically dash forward by pressing A.

This is way less of a big deal than the the stamina aspect so I'm in heaven either way. 

** EDIT2

Just noticed another small problem with dashing. When you leave a screen while dashing and are still holding down A, you revert to walking instead of dashing in the next area. Would be nice if the game checked to see if A was being held when you enter a new area and maintain the dash.

** EDIT3

Had an issue during the fight with the Biting Lizard (that hatches from tadpole) just before getting Undine. Boy got swallowed by the lizard at the beginning of the fight and immediately after popping out he remained frozen in place the rest of the battle. He was able to show the dash animation and attack but he continued to remain in place. Had to switch to controlling the other characters. Here's my ini if you want to look it over.

https://www.dropbox.com/s/4bvni9402cn7mkf/SoM%20Turbo.190811.ini?dl=0

** EDIT4

So I was doing some spell grinding around the water temple like I've done for years and I had an idea. What about eliminating the need to spell grind altogether? I've always held to the practice of leveling up all my spells to the max after each seed and the process of doing so is nearly as tedius as Final Fantasy 2's spell grinding. Spell grinding has been my single biggest complaint about the game over the years. I went back and compiled a new rom with the faster spell grinding option to alleviate this. It was notably less tedious but I'd personally enjoy just cutting out the spell grinding aspect altogether. I'd propose simply leveling up each elemental to the max as soon as you touch a new mana seed. New elementals would join you at max level (per seeds activated). I suppose this would make the game easier in a sense, but for someone who *always* maxes their spell levels at the first opportunity, the difficulty stays the same. As far as the technicals, I'd guess that this would be a far more complex modification than any of the dash tweaks.

[Queue]

Edit: Wrote this before your EDIT4; for EDIT4, probably all doable via the game's event system, which is easy to modify, just a little tedious to make compatible with VWF and Relocalized.

Changes to required inputs or inputs persisting on a screen change are a taller order. I'll look, but the former may be a serious pain (primarily in this case making it stop running when you stop holding a direction, then start again without re-pressing A) and the latter may have side effects without significant safeties added to input code. If you really want it to be like Trials of Mana, I'd also need to disable running when in combat (which would also necessitate adding an in-combat and out-of-combat state... which I mention as a bad joke, no way am I doing that; I hate both of those aspects of Trials of Mana). Anyway, to elaborate, the game has... I think 3 variables that maintain input states per controller (currently pressed, currently held, acknowledged / used, etc.), plus some temporary variables used mid-input logic, and probably some action-specific state variables, and messing with the input held / used variables often has far-reaching side effects. Running is triggered by acknowledged input state and lots of things try and clear that state (and it's not reset until you release then re-press said button), including an area change. Anyway, I at least would want the latter capability for my own use, so there's a good chance of it happening if it's reasonably doable, just, even if I decide on a way to get it working I could then deem it more trouble than its worth if I then have to hammer down bugs it creates; I love fixing bugs, I hate creating bugs I then have to fix.

As for Biting Lizard, I'm not managing to reproduce the issue (of a stuck character), using your INI file, completely Vanilla SoM, Turbo defaults, my debugging settings, etc. In Vanilla SoM his eating attack has some serious visual oddities (you basically get to run around invisibly before the attack is visually finished, for example), so there's a significant chance you hit some Vanilla animation bug related to his attack. Regardless of cause, it's something I want to fix, just need to figure out what happened.

[ShockwaveS08]

Just loaded the latest revision to SOM:T, and the optional adjustments to the ring menus are making things much easier to navigate! There are two bugs I encountered while I was busy acquiring Shade, Luna, and Wisp (in that order).

B1: In one single instance, sleeping at the Gold Isle Inn and immediately opening the Save Game menu afterward will cause the menu's graphics to turn into a garbled mess. Exiting the menu, and then opening the menu again via the innkeep seems to solve the issue. Not sure if this bug is reproducible.

B2: In the region of Mandala, there are certain stairs that are mildly-difficult to navigate, all of which are surrounded by slopes to the left and right; when pressing the D-Pad in a diagonal direction towards a slope adjacent to the stairs, whoever you're controlling will not move onto the stairs, but will instead travel horizontally towards the opposite slope.

B3: Whenever Salamander's spells are used by the girl, he somehow gains a purple-ish hue, yet he maintains his original color palette when summoned by the sprite.

S1: When traveling via Flammie, is it possible to have the sky's color palette match what lies on the Mode 7 ground's current timezone, assuming that the Day/Night cycle is enabled?

Addendum 1: As soon as I hit R on the Global View, I immediately saw why the map-speed suggestion from before wouldn't be feasible, as the full map was drawn to the screen, line-by-line. Nevertheless, this screen would be a good place to enable waypoint-placing, assuming that's in the cards...

[Chicken Knife]

Changes to required inputs or inputs persisting on a screen change are a taller order. I'll look, but the former may be a serious pain (primarily in this case making it stop running when you stop holding a direction, then start again without re-pressing A) and the latter may have side effects without significant safeties added to input code. If you really want it to be like Trials of Mana, I'd also need to disable running when in combat (which would also necessitate adding an in-combat and out-of-combat state... which I mention as a bad joke, no way am I doing that; I hate both of those aspects of Trials of Mana). Anyway, to elaborate, the game has... I think 3 variables that maintain input states per controller (currently pressed, currently held, acknowledged / used, etc.), plus some temporary variables used mid-input logic, and probably some action-specific state variables, and messing with the input held / used variables often has far-reaching side effects. Running is triggered by acknowledged input state and lots of things try and clear that state (and it's not reset until you release then re-press said button), including an area change. Anyway, I at least would want the latter capability for my own use, so there's a good chance of it happening if it's reasonably doable, just, even if I decide on a way to get it working I could then deem it more trouble than its worth if I then have to hammer down bugs it creates; I love fixing bugs, I hate creating bugs I then have to fix.

Yeah, I definitely wouldn't be proposing disabling running during encounters like Trials of Mana. That would be a bit like coding Secret of Mana to freeze all actions during spell casting. 

As far as the other points on running, not a big deal. While it would give the game a touch more immediate finesse, it didn't take long for me to adapt to working around either issues. I hardly notice them at this point. 

**EDIT

I frankly don't remember if this is an original bug or not, but I've noticed twice now instances where I selected to cast a spell and for whatever reason the character did nothing. It seems that if the character is in the middle of the animation for getting up off the ground, the cast command totally fails. Coming back to this after another hour of play, I think it's not a bug but intentional. When in an injured state, spells aren't going to cast. Trials of Mana handled a bit more elegantly where you couldn't even select the character to do anything if they were in such a state.

**EDIT 2

Probably an issue from the original game, but these guys guarding the stairs on the ship that picks you up in the desert create a very bizarre 6 second delay when you talk to them. If it can be fixed easily, it should be fixed.

[Queue]

Version 2019-08-14:
https://ufile.io/6lk7mirf

Changes:
- Added a note about dependent feature options to the [Information] description
- Implemented Balance\Level_9_Weapon_Perk; level 9 weapons don't slow player movement while charging up
- Implemented Quality_of_Life\_Run_Requires_D-Pad; Trials of Mana-style running controls, requires Run_Freely and probably shouldn't be used with _Gradual_Turns_Only
- Implemented Quality_of_Life\Run_After_Area_Change; hopefully no bugs
- Implemented Quality_of_Life\Sand_Ship_Guard_Pause; changes a timed pause after they yell at you to a wait-until-button-press



ShockwaveS08
B1) Only have the weakest hypotheses about what could have caused that, but unless it's reproducible, nothing realistic to do about it; will keep my eyes peeled, but brute force attempts to reproduce were fruitless

B2) The ones just south of town outside the dark palace cave? I honestly didn't notice any especially onerous behavior when mounting the staircases. They're not the most user-friendly, but not something I'd change unless there's a genuine collision bug with them.

B3) Not a bug. The girl and sprite have different palettes for their elementals for whatever reason. Just seems to be some sort of aesthetic choice on the part of the game's designers. Personally, I'd always noticed the difference with Dryad due to casting the two Mana Magics back-to-back.

S1) If you search the ZPS file for "AtmoColors" you'll see the preliminary work I've done on that, but changing the sky is harder than changing the ground, so it's just not done yet. It's also not as simple as matching the sky changes to the ground changes (unless I want it to look bad); the direction you're facing also plays a large part in which sky colors to use.



Chicken Knife, the spell casting thing is intentional behavior, even if an unpleasant user experience.

The dialogue pause on those guards appears to be an intentional punishment, but it's just a one-byte change so tossed it in as a quality of life option.

While I was figuring out movement speed while weapon charging I somewhat accidentally implemented the other running stuff you'd inquired about. Neither is thoroughly tested, and the screen transition running needs it, but I just ran out of time (and didn't want to wait another day for something technically somewhat small). I took what should be a safe approach for D-Pad running, where A is still what technically what triggers running, but the running code zeros your speed if no D-Pad directions are currently pressed; this depends on Run_Freely to work as a side effect. The screen transition running was a more complex issue, as three different things all attempted to disable running on a screen change: using a "door" (which includes when you're stepping on ground, etc. that sends you to the next area), primary game logic that tries to clear running every frame whenever you don't have player control such as during the automated walking during an area exit (fade out) and entrance (fade in), and a memory clear function called at the beginning of loading a new area. I changed all three, and hopefully none have side effects I didn't hit during my testing. There are some corner cases that I don't accommodate that still disable running, but nothing that should cause issues (other than having to re-press the A button). The main example being holding A while opening / closing the ring menu will allow you to keep running until you change screens at which point you have to re-press A, but I'm interested if there are other situations with that same behavior.

[Chicken Knife]

Wonderful! My experiences so far with the new run patches are working out perfectly.

I just realized something else that's been irritating me that I wanted to point out. When you are in the field targeting enemies with spells, I've noticed numerous instances where an enemy is in the field of view, albeit on the edge of the screen, but you cannot target them with magic. If one can see an enemy, I think the perimeter for spell casting should be wide enough to include them.

**EDIT

One more tiny thing to take note of when running. Holding run, attacking, and continuing to hold run is just like changing areas was before. You have to take your finger off the run button and press again to resume running. If it would be easy to auto resume running after an attack while the player holds A that would be cool. Note, this issue also occurs when you are attacked while running.

**EDIT2

I find the dark purple line (see bottom area of pic) that appears mostly on the bottom of various screens in the Ice Palace to be out of place.



**EDIT3

This is just an idea to throw out there that would seem to be seriously difficult to pull off. Definitely a product of having just put 100 hours into Trials of Mana. Could code be done to make enemy XP gained pop up like  a damage number on the screen, preferably in green? I absolutely love this feature with Trials and feel very in the dark about how much XP enemies are providing while I play this one.

**EDIT4

Just encountered a bug in the fire temple. Definitely something I never experienced in my many plays as a kid. I would remember this one. I was in the room that has the chest for the Axe Orb. When I started to walk down after retrieving the orb, My characters remained stuck near the chest but the screen scrolled down anyway. Pretty soon no characters were visible on the screen. (I'd post a pic of that but imgur seems to be down. Ask me later if you want to see it) So I continued to try to walk down. Eventually the room started over at the top of the tile map. Thankfully I could now control my characters again and walk around like normal to exit the room. Here's a link to my ini file if you want to look it over.

https://www.dropbox.com/s/x54hk7hdgdr2dm1/SoM%20Turbo.190814.ini?dl=0

[Queue]

I can take a peek at spell target finding code. I admit that has always bugged me too, but for some reason it never occurred to me to change it, seeing it as just a mechanical annoyance of the game.

E1) I'll make the D-Pad running hyper aggressive at keeping you in a run state, but expect some weird corner cases that I don't intend to make accommodations for (things like if used with the Level 9 Weapon Perk of moving at full speed while charging, plus the A pauses weapon charging feature, would let you sprint while charging level 9 weapons but the charge gauge would likely also end up sucky looking given that combination).

E2) While I know what causes that, and I'll likely eventually clean up the Ice Palace with my Tidy Map feature, what you're seeing is almost definitely due to an emulation issue. Speaking of, which emulator are you using? Because those colors look washed out and wrong. Anyway, the Ice Palace uses layer blending to do its shadows (most of the game uses shadows baked into the tile art), and what you're seeing is sloppy unnecessary out of bounds shadows showing mixed with the general out of bounds area, but when I go and check the Ice Palace in Snes9x or bsnes, those stripes (etc.) aren't visible because they blend to the same color (they are visible in ZSNES, but presumably that's because it's doing it wrong).

E3) Probably a huge pain for multiple reasons (e.g. popup numbers can only go to 999, one actor can only have one set of numbers showing so they'd have to wait on or override that actor's damage numbers, etc.). Obviously things that can be overcome with enough new programming, but not something I intend to pursue.

E4) Most likely what happened is while you were opening the chest, your AI buddies were stuck on something running up and down, which was ratcheting the screen down until you were offscreen (which was allowed to happen because you were currently opening the chest which puts you in a state where you're allowed to be left offscreen). I assume this is related to the CPUs_Dont_Block_Screen feature (which isn't my creation, so I only have some idea of what it's doing). Once you were offscreen, the normal screen panning logic wasn't in effect so things were... dumb until you got back on screen. I bet this is something I can improve (probably just stricter logic for CPUs_Dont_Block_Screen to never let a human-controlled character offscreen). Edit: preliminary testing makes it look like a bug in Vanilla screen scrolling logic that makes this happen, just exacerbated by stuff that lets your party spread out more.

[Chicken Knife]

To answer you question on the emulator I'm using, that would be the most current version of SNES9X. It has been rock solid from my point of view over the years.

[Refaze]

Why in the heck is this not mentioned anywhere else on the internet?  What a great job!  Secret of Mana has been my favorite game until recent years.  There was just too many bugs I happened to notice with age.  The work you guys are doing is incredible.  This is one of the best fan patches I have even seen and I played a lot.  Today at work is going to be like being a kid again.  Ill be jotting weapons/armour and characters down on paper excited to come home and play this gem.  Kudos  to everyone involved.  I was wondering in further updates,  do you loose your current game save? 

[Queue]

I was wondering in further updates, do you [lose] your current game save?

Nope, Turbo is compatible with Vanilla save data, saves made when using it are compatible with Vanilla (with one exception, detailed below), and if done carefully, save states are even compatible between versions.

Exception: Items\Item_Limit_Increase, which increases maximum consumable item count to 9, creates save data that Vanilla Secret of Mana cannot use correctly, but Turbo provides a way to sanitize the save data; make sure Technical\Validate_Items is On and Items\Item_Limit_Increase is Off, load then re-save, and that save will then be Vanilla compatible.

Details: Technical\Safe_Save_State allows save states made when using Turbo, if you make the save state while paused via Start (it'll show a little "PAUSE" label in the middle of the screen), to be loaded with any other combination of options / version of Turbo / completely Vanilla. This partly depends on the emulator not having a checksum mechanism between the save state and the ROM, but most emulators do not.

[Refaze]

Ok,  sounds great!  I have noticed a few things while playing;  I had opened a chest that contained the "boxing gloves" (unless this is some kind of trapped chest mechanic) but it is not visible in my inventory.  Also while charging, your characters loose the Armour color palette.  My current play-through is using the latest version of SNES9X.  So far everything else has been great!

Edit* Never mind,  the boxing glove is just a trap.  I don't know what my train of thought was that day.  So the only things I have noticed so far;

*Goblin village is a little glitchy (Expected at the moment)
*Original Armour color palette when charging
*When you get your sword upgrade you still have your weapon even though he takes it (don't believe this is a bug)

[Queue]

Version 2019-08-19:
https://ufile.io/t3flg2if

Changes:
- Made D-Pad running more aggressive in detecting run button state
- Optimizations related to mod-added sound effect calls (stripped out unnecessary register saving code), hopefully didn't introduce any bugs
- Possibly fixed a bug related to screen scrolling, event-controlled characters and Quality_of_Life\Walk_To_Edges_Of_Screen
- Implemented Bug_Fixes\Stereo_Panning_Fix; fixes and unifies lots of faulty stereo panning logic in vanilla sound code, sound effects should no longer come out of the wrong speaker, nor both speakers when it should be only one
- Implemented Quality_of_Life\Damage_Feedback; aesthetic change to how the game alerts you to successful attacks: enemies vibrate slightly and the enemy "damaged" sound now plays when an attack adds damage rather than when accumulated damage causes a damage number to pop up, additionally, enemies become ghost-like when they're out of health but haven't yet played their dying animation, and conversely, if you swing at an enemy but they're currently invulnerable, there will simply be no "damaged" sound (or vibration). Enemy invulnerability periods vary wildly based on enemy appearance since it's generally tied to animations, but given the number of complaints I've heard regarding this aspect of Secret of Mana combat, that doesn't seem to be universally known. While this feature doesn't change when enemies are vulnerable, it should give you better feedback on if your attacks are working or not; this is why I categorized it as Quality_of_Life and not Balance, because it doesn't literally make things harder or easier, but most likely you'll perceive combat as slightly easier due to spending less time attacking already dead or invulnerable enemies.



Refaze, can you elaborate on the Goblin Village? There shouldn't be anything glitchy about it that I'm aware of.

Modifying the player color palette when waiting on stamina (or for that matter other temporary states like poisoned, etc.) is low priority; aside from having to track down where those various palettes are loaded, it would require some form of blending algorithm to mix the equipment color with the status effect coloring, which is only feasible if the palette is a one-time calculation (such as when changing equipment) so will depend on implementation details, and for stamina recharge specifically, I don't especially care, since I only play using Turbo_Mode (and so never see the stamina recharge blinking).

That third issue is pretty minor, just a lack of attention to detail by the original devs. There's likely some way to change that event script to hide the boy's weapon while Watts is ostensibly reforging it, so I may take a crack at it at some point. Nice catch spotting that.

[Refaze]

The goblin village bugs are very minor. I was making my character walk through the pot and he was kind of glitching through it.  Not really a big deal at all.

[zoolgremlin]

Howdy, everyone.  I'm new to this forum, don't know a damn thing about ROM hacking, but I felt I had to register for two reasons.  First of all, I'd like to thank all of the users who have submitted patches to this forum for Secret of Mana.  Truly, you have made the original game a hundred times better than it was, and I have really enjoyed playing through again with your bug fixes and enhancements.  zhaDe, Queue, kethinov, Regrs, Timbo, Binarynova, DarkAkuma, DarkShock, FuSoYa, Masterflow, vivify93 and anyone I missed, you should all be very proud of what you've achieved.

@Queue  The second reason is to offer my help with your [Tidy_Map_Pieces] patch, if you still require it.  I have been playing through the game from the beginning just to see if I could spot any additional map oddities, using a ROM with [Scroll_Hack] and [Tidy_Map_Pieces] enabled, as you requested.  So far I have 14 screenshots showing areas that look like what you want to fix (PNG format, 256x224 resolution).  Some of them you might already be aware of, given how blatant they are, but I was half-expecting to find a lot more!  You must've already caught a lot of them.   

Anyway, currently I've only checked maps up to the point of the first part of the Lofty Mountains (the one with the cave going to the Palace of Darkness).  Unfortunately I forgot to check the ones for the Sandship and the desert area just before it.  I can't get back there without starting the game again, sorry about that.  Will play through a second time to check those areas.   

Many thanks, Queue, for your hard work on the Turbo patch, it's very convenient having all of these different patches in one place to pick and choose from.  Looking forward to the next stage in your work.  Here's the link to my screenshots, hope this works 'cause I've never used Google Drive like this before...

Secret of Mana Screenshots

[Queue]

Refaze, ohh, yeah, some of those little layering oddities (like if you press up against the bottom of the cauldron and get the thin line overlapping your character) are essentially unavoidable without making too severe of changes (such as redrawing the cauldron art -_-). I did what I could to clean up layering issues on that map, but some of the Goblin Village decorations were not designed with the ability to walk around freely, and some changes that would be necessary to fully resolve them would have side effects on other maps that share the same tile set (like the sprite village or turtle island).

zoolgremlin, wow, those are fantastic. I was aware of those trees west of Pandora (that map needs lots of work so I hadn't tackled it yet), and of the issues on Gold Isle (also a pretty complicated one), but had not noticed any of those castle shadow errors, nor the Ice Palace one, and I don't think I actually noticed that specific Northtown Ruins door (I didn't have it in my list of maps that still need work). Though fair warning, those out of bounds doors tend to be harder to deal with since they're there for a reason (will elaborate); if I can fix it, it'll only be by moving it further out of bounds because it needs to exist to keep the trigger count balanced for that map.

The following is unnecessary information, but I felt like typing it anyway:

So basically every map has tiles where when you step on them something happens, whether they're doors, or whip post gathering spots, or spots where stepping there starts an event, etc. They're indexed from left-to-right, top-to-bottom, so if you have a map transition upper left that's 3 wide, a whip post gathering spot center right, a hut lower left, and a map transition lower center that's 4 wide, they'd be numbered as triggers 1 through 9 in the order I described them (so 1, 2 & 3 are the upper left transition, 4 is the whip post, 5 is the hut and 6, 7, 8 & 9 are the lower transition). The map then has a list of events that fire when you step on a trigger tile; this supposed map would have 9 events defined to match up to those 9 tiles, with the first 3 and last 4 being copies of each other. Now, things get complicated if you want to add or remove a trigger tile; lets say you want to disable the hut based on if you'd talked to an NPC. If you simply have a trigger-less hut door replace the usable hut door, trigger entry 5 would still be for the hut door, but since that trigger tile would be gone, the leftmost lower center transition tile would now instead send you into the hut. What you have to do instead, if you want to disable the hut door, is replace the usable hut door with a trigger-less door tile, then replace some other tile (probably out of bounds) with a trigger tile to fulfill that spot in the trigger list. That's what those weird out of bounds doors are doing, they're enabled, and a normal door is disabled, to keep the count of trigger tiles balanced. Some tile sets have invisible trigger tiles that are easy to hide out of bounds, but that's not true of every tile set (among other complications).

[zoolgremlin]

@Queue  Thanks for your response, good to hear that the screenshots helped.  I added 6 more to the folder (numbers 014 to 019), had to put notes on 4 of them because either the location wasn't obvious, or the issue with the map wasn't quite clear.

I also went back and checked the Sandship and desert area before it (where you can go around in circles until you get the "Throat's so dry..." cutscene), couldn't find anything wrong with those.  If I've done things right, it's only the Fortress maps I haven't looked at yet.  Just finished Pure Land.

Concerning the stuff about trigger tiles, that's very interesting.  I did actually find out that the door inside the Northtown Ruins wall was a trigger tile, because I somehow thought to check it after hitting the button nearby (the one that says "A door appeared behind you!" after hitting it).  Sure enough, the door had vanished from inside the wall.  I remember Regrs mentioning on an old GameFAQs thread about how event trigger tiles are defined in the map itself, or something like that.  His posts on that thread really opened my eyes to SoM's inner workings.

I don't think you need to worry much about that door if it's too much hassle to change, at least not straight away or unless you really want to fix it.  Just thought you might like to know.  I suspected you would figure out what was causing that.   

[Mr X]

I like the idea of pallete changes whenever different equipment is worn but I hope the palettes would get reworked in the future, some of it does not look that appealing imo.