886
Final Fantasy IV Research & Development / Re: Developing a comprehensive editor for FF4
« on: March 18, 2014, 09:47:30 AM »
Yup
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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 »
887
Final Fantasy IV Research & Development / Re: Final Fantasy IV: Playable Baigan Edition
« on: March 17, 2014, 11:27:21 PM »
Or, you could do it with Tellah's Recall instead...
888
Final Fantasy IV Research & Development / Re: Developing a comprehensive editor for FF4
« on: March 17, 2014, 11:26:09 PM »
Hmmm... It looks like the same problems are still happening - the graphics glitches as well as the treasures not redistributing right. Which is odd because as far as I can tell, the indices did change appropriately. It must be changing something else, too...?
889
Final Fantasy IV Research & Development / Re: Developing a comprehensive editor for FF4
« on: March 17, 2014, 07:30:38 PM »
Cool. I'll try again in a bit. Will let you know.
890
Final Fantasy IV Research & Development / Re: Developing a comprehensive editor for FF4
« on: March 17, 2014, 10:57:18 AM »
I got the same results as Grimoire LD. It looks like only a modified treasure list causes the glitching issue. Saving without making changes seems to be fine.
OK, I've had a chance to investigate, and I think what should be happening is this: When adding a treasure to any given location, the way to make that treasure active is to increase byte 0C of the properties of each subsequent location by 01 (or by an amount equal to the amount of chests you're adding). Keep byte 0C of the map you're editing the same.
For instance, the treasure index byte of Baron Town is 00, meaning when searching for treasure contents in Baron, the game starts by looking at the first treasure. But it also references the treasure index of the next map, Village Mist. Mist's treasure index is 07, meaning once the game has accounted for 7 treasures in Baron, it will stop counting. By changing Mist's treasure index to 08, you activate all of Baron's chests, but negate one Mist chest, because you haven't yet adjusted the treasure index of the next map, Kaipo. Therefore, in order to add a chest seamlessly, you have to increase all subsequent locations' treasure indices by 01 (or remove a chest somewhere).
You are right, though, that the counting resets with map 0x100 (Kokkol's smithy). I think it's safe to presume that those indices can be left alone
heh - I just re-read what I wrote... I mean they can be independent of the first set of maps, not entirely left alone.
OK, I've had a chance to investigate, and I think what should be happening is this: When adding a treasure to any given location, the way to make that treasure active is to increase byte 0C of the properties of each subsequent location by 01 (or by an amount equal to the amount of chests you're adding). Keep byte 0C of the map you're editing the same. For instance, the treasure index byte of Baron Town is 00, meaning when searching for treasure contents in Baron, the game starts by looking at the first treasure. But it also references the treasure index of the next map, Village Mist. Mist's treasure index is 07, meaning once the game has accounted for 7 treasures in Baron, it will stop counting. By changing Mist's treasure index to 08, you activate all of Baron's chests, but negate one Mist chest, because you haven't yet adjusted the treasure index of the next map, Kaipo. Therefore, in order to add a chest seamlessly, you have to increase all subsequent locations' treasure indices by 01 (or remove a chest somewhere).
You are right, though, that the counting resets with map 0x100 (Kokkol's smithy). I think it's safe to presume that those indices can be left alone
heh - I just re-read what I wrote... I mean they can be independent of the first set of maps, not entirely left alone.
891
Final Fantasy IV Research & Development / Re: Basic Sprite editing
« on: March 15, 2014, 11:24:53 PM »
If you've jumped to ED5C0 and you don't see anything that even remotely resembles character portraits, then you're probably in 4 bitplane mode instead of 3 bitplane mode.
SNES has two different ways of interpreting data to display images - I don't fully understand it myself, but a notable difference between the two is whether the system is using an 8 color palette or a 16 color palette.
If you're using Tile Layer, you can change image mode in the view menu:
view > mode > SNES 3BPP
This will yield a screen that looks like the one in my post here.
SNES has two different ways of interpreting data to display images - I don't fully understand it myself, but a notable difference between the two is whether the system is using an 8 color palette or a 16 color palette.
If you're using Tile Layer, you can change image mode in the view menu:
view > mode > SNES 3BPP
This will yield a screen that looks like the one in my post here.
892
Final Fantasy IV Research & Development / Re: Developing a comprehensive editor for FF4
« on: March 15, 2014, 02:37:52 PM »
... Yeah, damn. I was hoping that was info known but not by me. I'll have to fiddle around a bit. I'll let you know when I figure it all out.
893
Final Fantasy IV Research & Development / Re: Basic Sprite editing
« on: March 14, 2014, 10:19:13 PM »Here you go:Code: [Select]688D0-689CF Character Portrait Palette Data
ED5C0-EEF3F Character Portrait Graphic Data (3 bitplanes, composite, 384 bytes per class id)
If you jump to ED5C0 in your graphics editing program and scroll down, you'll find it pretty easily.
894
Final Fantasy IV Research & Development / Re: Developing a comprehensive editor for FF4
« on: March 14, 2014, 11:08:40 AM »
Hi Pinkpuff - I discovered something that's not working right with FF4kster.
It seems the program isn't properly referencing (or editing) locations' treasure contents indices (byte 0C of location properties). It seems to work fine when changing/moving/adding treasure in rooms that already have treasure, but adding treasure to rooms that normally have no treasure is where the problem crops up.
For example: I'm adding a treasure chest in the Agart Inn, which normally has none. The Agart Inn's map index is 20 (hex), but its treasure contents index is 1F (for no discernible reason). When I edit the triggers in FF4kster, the treasure chest stays inaccessible unless I manually change the treasure contents index to 20 with a hex editor.
looks like I'm wrong about how this byte works (I guess it's a running total of how many chests have been counted so far... ?), but the fact remains that it needs to be changed in order to add treasure chests where there previously were none.
It seems the program isn't properly referencing (or editing) locations' treasure contents indices (byte 0C of location properties). It seems to work fine when changing/moving/adding treasure in rooms that already have treasure, but adding treasure to rooms that normally have no treasure is where the problem crops up.
For example: I'm adding a treasure chest in the Agart Inn, which normally has none. The Agart Inn's map index is 20 (hex), but its treasure contents index is 1F (for no discernible reason). When I edit the triggers in FF4kster, the treasure chest stays inaccessible unless I manually change the treasure contents index to 20 with a hex editor.
looks like I'm wrong about how this byte works (I guess it's a running total of how many chests have been counted so far... ?), but the fact remains that it needs to be changed in order to add treasure chests where there previously were none.
895
Final Fantasy IV Research & Development / Re: Basic Sprite editing
« on: March 14, 2014, 10:02:43 AM »
I use Tile Layer. I recently detailed the entire process I use here (scroll about halfway down the page).
I've heard a couple of people talk about YYCHR lately though, which apparently cuts through a lot of the tedium I'm used to.
I've heard a couple of people talk about YYCHR lately though, which apparently cuts through a lot of the tedium I'm used to.
896
Final Fantasy IV Research & Development / Re: Final Fantasy IV: Playable Baigan Edition
« on: March 14, 2014, 01:31:58 AM »
I'm a little too bogged down with my own hack to get involved in another right now, but I'm happy to help you figure out how to do stuff if/when you ask. Grimoire LD's usually good for that kinda help, too.
897
Final Fantasy IV Research & Development / Re: Basic Sprite editing
« on: March 14, 2014, 01:27:36 AM »
I'm guessing you're talking about the one Zozma posted to this thread back in 2010?
I think you can download it from that post. It can be imported using most spriting tools, I'm pretty sure.
Judging by what he said in the post ("I doubt anybody will ever use it"), I get the impression he'd be ok with you doing so, but he hasn't posted on the forum in about a year so you might have to figure out how to get in touch with him.
I think you can download it from that post. It can be imported using most spriting tools, I'm pretty sure.
Judging by what he said in the post ("I doubt anybody will ever use it"), I get the impression he'd be ok with you doing so, but he hasn't posted on the forum in about a year so you might have to figure out how to get in touch with him.
898
Final Fantasy IV Research & Development / Re: Final Fantasy IV: Playable Baigan Edition
« on: March 12, 2014, 09:36:27 PM »
FF4kster has made event editing a snap. You can download it here.
899
Final Fantasy IV Research & Development / Re: Grimoire LD's Notes, Patches, and Hacks (1 Party Member Switch Item Created!)
« on: March 05, 2014, 06:46:00 PM »
That's cool! New to me, anyway. How does the game react if the target is "immune" to a different element?
900
Final Fantasy IV Research & Development / Re: Final Fantasy II: A Threat from Within (The Preview)
« on: March 05, 2014, 12:20:15 AM »
Oh, sorry, that was meant to be rhetorical. It's Mysidia.