øAslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;u=14;area=showposts;start=390e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index20f8.htmlslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;area=showposts;u=14e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index20f8.html.zxϼg^ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÈ0P.¼ðOKtext/htmlISO-8859-1gzip@øÕ¼ðÿÿÿÿÿÿÿÿTue, 10 Mar 2020 16:30:30 GMT0ó°° ®0®P®€§²ð®μg^ÿÿÿÿÿÿÿÿr'¼ð Show Posts - Pinkpuff

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Pinkpuff

391
Unfortunately I have not located where this additional CMP would be that would search it for Shields...

Or maybe I found it already?

03F36B in LoRom/HiRom (best to use WindHex for finding this) there is still a CMP of 6D when it should read the newly changed range, so you can equip new "shields" in battle.

Changing this didn't allow me to equip the other shield equipment in battle... did it work for you?

392
Success!!  :banonsmash:

Phew! That was the scariest mess-up yet...

393
Confirmed.

Going into the event editor freezes it for me as well. What did I do now...  :isuck:

394
Ah, I see what you mean. The pointer hack should fix that issue as well. I'll give it my best shot. Deleting the last message would probably work but I think you'd have to do it each time you saved which would be annoying.

On another topic, I was messing with the equipment and when I extended the "shield" range and created new off-hand armors, the extra ones seem to mess up the character's attack stats. Can anyone else confirm this? If so I suspect there's some kind of check being made that the left hand equipment is indeed a shield to prevent it from being factored into the attack and hit calculations, which FF4kster neglects to write to when the range is changed...

 :edit: Uploaded the fix to the message range for the last map. Let me know if there are any further issues. I'll update again once I implement the inserting/deleting functionality.

 :edit: And done! Inserting and deleting messages from Bank 2 should work now.

395
Ok I looked at bank 2 and I see what's going on. When it loads, it reads the pointers for the maps, then map by map it scans across, adding a message for each 00 byte it reads, until it hits the pointer for the next map, or in the case of the last map, the end of the data. When it saves, it writes each map's text and computes the pointers appropriately, but when it gets to the end of the dialogue of the last map, it just stops writing, leaving whatever data was past the (new) end of the text there.

The result of this is, if you deleted a bunch of text without adding new text, it will stop writing short of where the old ending point was, leaving whatever was already there still there. So next time it reads the last map, it thinks there are a TON of messages for the last map (I bet that the 45 or whatever messages will scroll down if you try; it's probably a lot more) because it just goes to the end of the data.

The other result of this is that if you just fill up the end with FFs manually, it will get to its fixed ending point and think that all those FFs are one giant message. FF4kster's bank 2 space limit is not set to quite the very end of that segment (901FE not 901FF) so it thinks it doesn't have room to write that no matter how big it is. I think that's why when you backspaced a bunch of them it worked. In fact, I bet that if you had manually put in a 00 somewhere short of the end (say, 901FB or before) it would have worked as well.

In any case, the last world is a glitch world, and as far as I know we don't yet have a way to turn glitch worlds normal, so, does it really matter whether it has 1 message or a billion? If the issue is purely cosmetic/asthetic then I'm not inclined to mess with it. If there is some functional issue, however, I do have an idea for a stop-gap solution:

Ideally what I would like to have is an extra pointer at the end to indicate the end of the dialogue for the last map. However, there's only enough room in that pointer table for the maps themselves. What I could do, however, is hijack the last two bytes of the data and use it for said pointer. In other words, the room for bank 2 text data would be shrunk by two bytes, which would now be used (by FF4kster only, not by the game) to indicate where the actual "end of data" location is. This may have the side effect of the game interpreting these pointer bytes as part of the last message of the last map, but the last map is a glitch world (absent miscellaneous shenanigans), and even if you do somehow turn it into a real map, it should be easy to avoid showing that particular message if it's a problem.

I'm not sure what your plan is exactly for dealing with the end of Bank 2 - I'm thinking the easiest thing to do would have the editor fill up the end with FFs, and know that any amount of FFs at the end can be removed to make room for what comes before.

At any rate, while you're looking at Bank 2, a request: do you think it would be possible to add the ability to insert and delete messages from a map? It seems like the amount of messages within a given map is limited only by the amount of space devoted to that map (by the pointers, which are already moveable), and the only thing needed to define a new message is a 00 at the end of the previous one.

You know what, I honestly thought I had already implemented that, but I just tried it and you're right, you can't currently add or delete messages from Bank 2! This one I will definitely get on right away! Just be careful to make sure your event triggers and NPCs aren't referencing message indexes that no longer exist or who knows how the game will behave...

396
I'm about to head out to the local anime society's premiere event for the new Sailor Moon so I can't look into this right now but thanks for bringing it to my attention. I'll get out the good ol' smashy-smashy bug hammer in the morning.  :sleep:

397
And fixed!   :banonsmash:

It took a while to find; at first I was poring over the Steal code, unable to find anything wrong. Turns out there was a typo in the addresses for Pray causing it to write the message-showing code into the middle of Steal's execution code!

Anyway that should do 'er; let me know if you find anything else!  :childish:

398
Updated again!

This time the command item requirement ranges are being saved in the rest of the locations where they should be (at least I hope), and encounter rates have been added to the Map Info editor. I meant to put those in a long time ago but it sort of fell through the cracks.

There's also one more significant upgrade that will be obvious when you run the program!  :wink:

399
Unfortunately I don't think there's much we can really do. You can try to rework the patch to avoid those addresses... The only other option would be to set up FF4kster to look for your patch specifically somehow, but the design scope I've been using is that it assumes the only program you're using to make changes is this one (and maybe some graphic editors or something) and that if you apply any other changes they're at your own risk.

400
Actually I just had a look at the code for saving and noticed, well, two things. First, I made a mistake in saving the ranges; it's only saving to the locations it read from instead of all the necessary ones (so that's probably not the problem in your case, but I still need to fix it). Second, and I think this is very likely where the problem lies, it's looking at the value it has for the various message pointers for the various songs. If one of those has a value FF, it will write EAEAEA to the appropriate spot to prevent the game from displaying the message; otherwise, if it has any other value besides FF, it writes 8DCA34 to that spot (usually redundant, but needed in case you had blanked the message out earlier). If your modifications moved or otherwise messed with the code for displaying the messages, then FF4kster is writing something (either EAEAEA or 8DCA34) to a spot where it shouldn't be.

If this isn't the problem then by all means send along the rom and I'll do some further digging.

 :edit: The locations to look at to verify this are (headered): 1EB19-1EB1B, 1EB26-1EB28, 1EB33-1EB35

401
Alright! Now This was such a substantial update! Everything worked perfectly! The ranges, the command additions, and solo battles all worked out fantastically!

Yay!!  :childish:

If I may make one suggestion though... Can Formations show up with the necessary information on that Formation as well?

So say I set "Formation 229" To the side in a separate box it would show "1 Baigan, 1 Right Arm, 1 Left Arm". That way we have a better idea on what we're choosing without constant cross referencing.

Good idea! Added to the to-do list.

The only issue I saw that appeared was that my custom Sing command broke when I saved in this version... which is a bit major to me, for obvious reasons. I should note that I did not touch the Commands section in this test, I thought at first it might have only crashed because of me going to the Command menu and looking at the data, but just saving breaks it. Does the data save default data somewhere to cause this?

When you save with FF4kster, it saves everything, even if you never viewed or changed it. Thus, if you have a rom which has something modified or moved around so that it isn't where FF4kster expects it to be, then even if you just open the rom and just immediately save it without going into any editors or changing anything, it will try to write to all those places, possibly/probably messing up your rom. Now that sing in particular has a lot of things going on (the songs, the messages, and now even the equipment requirements), there are a lot of potential places for it to mess things up.

Granted, a lot of the time you may still be safe because it is mostly just putting back whatever it read even if it doesn't "make sense", but there are also several assumptions it makes; bytes that it assumes should be the same so it will only read from one place but write to several (the feature ranges are a good example of this). If you like I can try my best to help track down where the source of the problem is and whether we can work around it...?

402
Updated again!  :childish:

Everything from the commands should be implemented now. Let me know if I missed anything, or if anything isn't working correctly.

Yeah, I acquired a different ROM and it works perfectly. Thanks for all of your help and investigation! :)

No problem, glad to hear it!

403
No sweat! Believe me, I'm very appreciative for all the work you've done finding things and compiling it all! The odd typo is nothing to fret over.

The delay (index) has been incorporated into the command editor, as has the statuses under which the commands are disabled. Currently I'm working on the equipment requirement ranges and then there should be an update later today.

404
Looks like the Targeting works perfectly! That is so nice to have in the editor and cuts down on the need to jump to and fro with the Hex Editor and FF4kster. There's also another easy piece (at least I would imagine its easy) to implement that Chillyfeez discovered long ago, but it seems like the info fell through the cracks and that is the Charge Time for the various commands.

Quote from: Chillyfeez
there is a table in ROM at A0189 that contains one-byte-per-command references to the duration set to perform each command. Most of them are 00, which is immediate. 01 is not one second, though. These are pointers. I haven't tested all 256 options (and probably won't) but the following are used:
00: (most commands) immediate
01: (Charge) 5 seconds
02: (Dark Wave, a few others) 2 seconds
04: (Salve, Aim) 1 second
FE: (not used, but I tested it to see if it would crash the game - it doesn't) several hundred seconds

I'm unsure if its with a header or not, but it would make a nice addition.

I can't find that chart... not at A0189, and not at A0389 either...

 :edit: Nevermind, I found it the hard way at A0089; at least I think that's it... it has 0 for Charge instead of 1, but they seem to match up otherwise.

405
I patched it to a clean rom and it works perfectly!

When I patched it to the rom I had with the other two already applied, the game bugged out and froze during battle. Not sure which it's conflicting with, but I would assume it's the X button defer turn patch since it also has to do with battle while the L button dash patch doesn't. A shame too, because those two would have synergy together. Knowing the ATB situation makes turn deferring a more useful ability; likewise, being able to defer turns makes the ATB information more useful.