јAslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;u=278;area=showposts;start=795e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index992d-2.htmlslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;area=showposts;u=278e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index992d-2.html.zxахg^џџџџџџџџџџџџџџџџџџџџШрўOKtext/htmlISO-8859-1gzip8:жўџџџџџџџџTue, 10 Mar 2020 19:25:27 GMT0ѓАА Ў0ЎPЎ€ЇВ№ЎЯхg^џџџџџџџџ[$ў Show Posts - chillyfeez

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 - chillyfeez

796
I... Don't remember, tbh.
I think I may have just taken your word for it that it worked at the time, because I was looking for a way to make Phoenix work, and parsing your disassembles I found the necessary change to be made in RAM to actually revive fallen characters, at which point I stopped being concerned with whether this would work.
I can't really look into it tonight, but I should have some time tomorrow to test it out. I'll let you know.

 :edit: Sorry, Grimoire, this fell by the wayside today in favor of Shadow Party R&D. I've got a three day weekend coming up tomorrow, though, so I should have plenty of time to look into this.

797
So I've got shadow storage complete. That's the easy part. I'm sort of tackling things in order, so next up is awarding experience to shadowed party members. This will be a two-part process - rewriting the experience awarding routine to store experience awards in the right places, as well as rewriting the level-up routine to ignore shadow data (TNL is not stored, and leveling up will instead occur when a character is loaded FROM the shadow). I expect this to be a relatively quick process, but the character loading sequence (from the shadow) will be a massive rewrite.

798
I did that once, but then a new version of FF4kster introduced new command modification possibilities, which introduced new ways for it to misinterperet my custom code.
Filling with FFs creates a fix for this and all future versions of the editor

799
Grimoire, I have the same problem with my hack, so here's what I did:
1) make a copy of your hack (with the commands all working properly)
2) open one of the two copies in your hex editor and jump to offset $01/8200 (this is where the $03/8000 block begins in LoROM)
3) overwrite $01/8200 through $02/01FF with all FFs (effectively erasing all battle code entirely)
4) create a patch using this messed-up copy as the "unchanged" file, and your properly working ROM as the "changed" file
This will yield a patch that rewrites the entire battle code of the ROM. You can apply this patch every time you're done editing with Ff4kster and it will undo any changes the program made to your custom commands.

800
Well, no, I meant bit 3 of byte 9 (background movement byte), but it must be something else entirely if it works using the cave tileset... Perhaps it's a tile property instead of a map property? You could try changing the tile properties of your custom mist tile to match those of the cave mist tile... Or you could just keep it as is since you found something that works. :-)

801
There's a "mystery bit" in the background byte... Bit 3 I believe. Did you try toggling that one?

802
Ok, well, I can't figure out how to make the item window bigger, but I have some new ideas for how to use the normal 320 bytes of shadow data...
if every character has his/her own shadow slot, then anything that doesn't change doesn't need to be saved in the shadow. The character loading routine can simply run a check on which character it's loading, and fill in the necessary information from a table somewhere.
As far as I know, bytes 2D-2F are in that category of data. I just cheated P. Cecil from level 11 to 99 in a single battle, and these bytes did not change.
Furthermore, I think I can work into the character loading routine a jump through the level-up subroutine, so that the shadow wouldn't need to store the three bytes of TNL data.
The necessary bytes to store, then, would be:
Code: [Select]
offset stat #bytes
------ ---- -----
02 level 1
09-0A max hp 2
0D-0E max mp 2
0F base str 1
10 base agi 1
11 base vit 1
12 base wis 1
13 base wil 1
30 helmet 1
31 armor 1
32 gauntlet 1
33-34 right item 2
35-36 left item 2
37-39 exp 3

total 20 (14h)

With 20 bytes needed per character, and 320 bytes total, that's enough for 16 characters.

1 DK Cecil
2 Kain
3 Child Rydia
4 Tellah
5 Edward
6 Rosa
7 Yang
8 Palom
9 Porom
10 P Cecil
11 Cid
12 Teen Rydia
13 Edge
14 FuSoYa

That gives us enough space with 40 bytes to spare!

It'll take a massive load of coding - I'll have to completely rewrite the shadow loading and storing routines, plus edits to the experience awarding routine... probably more.

Not gonna start immediately, but I'll keep you guys posted on progress as it comes.

803
Hmm... There's a block of several hundred bytes near the end of the 7E block of RAM (7E:F600-FE00 or so) that seems to be unused. We could change that to the in-battle location of inventory, and extend back the out-of-battle inventory to be 100 (h) bytes long (begin it at 1390), then move flags and default visibilities up, giving SOME extra space to shadow data. All that's easy enough (though time consuming), except I don't know how to increase the size of the inventory display window.

Thoughts?

804
It would probably work out of battle but not in-battle. The active inventory gets transferred to a different location in battle, which is only big enough for 64 items.

There are only 44 battle ITEMS, but weapons alone, there are more than 64... Plus, shields. I can't think of a way to make that work...

805
This is going to be a bit ramble-y... The whole shadow party would need to be stored in the first 1800 bytes of RAM, because that's all that's copied into a save file - and what's the point of a full shadow party if it's erased every time you turn the game off? I don't think there's any significant amount of free space there. Maybe if you're willing to give up the fat chocobo's inventory... Anybody know what 7E:12A0 - 143F are used for? Something, I presume. If it's used for anything at all, then it can't be used for shadow...

As oit stands, shadow data is 320 bytes long.

There are 12 characters. This assumes there is no going back to young Rydia or DK Cecil.

That's 26 (DEC) bytes per character, IF you include Cecil. 29 if you don't. 32 if you also take out the option of keeping Tellah after he dies.

Character ID and upper byte of MP could, in theory, be combined. Handedness (upper two bits) can be determined and recalculated by ID, and the max value for the upper byte of MP is 03 (two bits).

So...
Sprite/class -1
Level - 1
Max HP - 2
Max MP/chr ID - 2
Base str - 1
" agi -1
" vit - 1
" wis - 1
" will - 1
Crit hit chance - 1
" " bonus - 1
Helmet - 1
Armor - 1
Gauntlet - 1
R hand item - 2
L hand item - 2
Exp - 3
TNL - 3

Total - 26.
So, that should work, unless you can see something I missed?
Steals evade (if that's what it is) shouldn't matter for party members, and I think everything I left out can be calculated based on everything that would be saved, right?

Hmm... Come to think of it, if every character has its own shadow slot, then there's really no need to store the first two bytes of character data, either...

806
Hey Grimoire LD (or anyone else, really), do you happen to have a map of character stat records that is more complete than the Bab-il document?
If I'm not mistaken, that was made by Phoenix, and therefore probably doesn't contain any of the info his shadow party hack ignored.

I'm interested in reworking the hack, but it would be silly to try without knowing which pieces of data are essential.

807
No, sorry.
Well, it must be somewhere because I think Zyrthofar's editor lets you change actual monster position within an arrangement.
But what I was talking about was the formation editor  that already exists in Ff4kster.

808
The plot thickens with the snowy mountains in the world map. I think I discovered this when I was researching landscape changes - the bytes that represent four tiles of snowy mountains (00, 10, 20, 30 I think) sometimes just display one tile. I don't know what conditions alter this behavior.

Regarding the shadow party: I'm pretty confident I've learned enough to implement that, but I'm pretty entrenched with my own hack right now. I expect in a week or two I'll be done with the current chapter, at which point I'll likely welcome a change of pace. If nobody's picked up the shadow party hack by then I'll look into it.

I'm pretty sure at least part of the mystery info in monster arrangements is used in enabling proper cursor movement. As Grimoire has noted before (somewhere... ?), creating monster arrangements from scratch often results in weird cursor movement (it may be difficult to move the finger from the monster in front to the one in back), but if you copy all the mystery bytes/bits from an existing arrangement, that seems to clear it up. If we can confirm this, you'd probably want to take out the option to alter the relevant mystery info and instead have it just change automatically with the arrangement.

809
That works for anything in the 30000 block in LoROM, but the whole story is a bit more complicated than that...
Something like, for every 8000 in ROM address, add an extra 8000 for the LoROM
Code: [Select]
ROM            LoROM
----------------
0000           8000
8000           18000
10000          28000
18000          38000
20000          48000

...I'm pretty sure that's how it works, and of course that's assuming an unheadered ROM

(sorry, Pinkpuff, that was probably borderline off-topic)

810
Just to be clear, Grimoire, are those LoROM offsets?