[FE8] Expanding the supply convoy with the str/mag split expanded modular save

Questions
2

As it turns out, there is no way.

Supply200 is possible in FE8U because break save is also available in FE8U.
However, break save was developed for FE8J, so it is not compatible with FE8U SkillSystems.
Nor does it support the FE8U str mag split. (This is because FE8J and FE8U have different implementations of str mag splitting.)

An example of using SkillSystems is Vision Quest, which has achieved Supply 150.
However, the source code is not yet available to the public.
//One month has passed since I asked for it to be released, but it has not been released yet.

Therefore, there is no other way to do this than to write your own code using ASM.

If the format of the save file changes, existing save data will no longer be available.
However, there is a possibility that data can be inherited using SQ.

1 Like
3

EMS changes the saving and loading of data only, it doesn’t change how the engine treats this data in any other respect.

The supply is programmed to read a specific number of items from a specific place in ram, no ammount of changing save data is going to affect this, only an asm patch can.

Essentially, with EMS you can change which chunks are saved and to where in sram they are written, as well as their size, but that’s not going to change how the game itself treats the data.

If you want to expand the convoy then you are going to have to find a place in ram that can hold all that data, repoint the convoy so that it reads from there, change the number of items the convoy reads, make sure all of it works and once all that’s done, then you can go into EMS and give this new data space in the save and routines to save and load it.

I actually haven’t looked into EMS much because I kinda moved on to hacking other things about around the time it came out so I don’t know a lot of how it works, but that’s what it looks like to me: you can change where in sram things are saved, and how they are saved and loaded, that’s it.

1 Like
4

I see. I guess that explains why I couldn’t find much documentation on this subject.

So if I can figure out how to create a new routine for reading and storing from the convoy, I can use EMS to define where to save that data?

5

Yeah, that’s what it’s for.

But considering Vision Quest already has that it’d probably be a waste to replicate the effort instead of just waiting/asking for it, I guess.

1 Like
6

I wrote the new save scheme (though teq did the heavy lifting with the actual convoy rework) for VQ by working with @pandan to get a buildfile EMS installer to what he wanted. If pandad’s okay with it, of course, I could send you what we used.

7

I would appreciate it if he did, but that’s up to him. I still need to get all the stuff in my hack in a publicly accessible form for release as well…

8

For anything technical, it’s not up to me to release it - I didn’t write it.

The convoy piece (ie ability to split convoys and combine items) is Tequila. There is still some glitchiness being worked out because it is not 100% perfect yet. Note that this work does not expand the size of the convoy, but only how the existing space is partitioned.

Anything that you did Snek in general is fine to release to everyone.

3 Likes
9

https://drive.google.com/drive/folders/1oI5B0503pIOi8k1EFsYyRxRvaYCvrZ3S?usp=sharing

This is what I wrote to save an expanded convoy. It saves as 200 items * 1 short per item = 400 bytes. You can just #include the .lyn.event file and refer to MSa_SaveConvoy for its saving routine and MSa_LoadConvoy for its loading routine.
shoutouts to pik, sme, and teq fixing my mistakes in VQ’s EMS scheme

1 Like
10

I’m not exactly sure what you mean by this. So I have to call these routines somewhere in the code that writes to and reads from the save data?

11

Stan’s ExpandedModularSave is in this post. It modular-izes how save data is saved and loaded by making save modules. Things like units, the convoy, event IDs, etc are handled in chunks, and their saving and loading behavior is determined by their saving and loading routines. I’d recommend reading through how it’s used, then I’d be happy to help if you have questions or help.

1 Like
12

So adding in the labels like so:

DeclSaveChunk($0000, $004C, MSa_SaveChapterState, MSa_LoadChapterState, EMS_CHUNK_CHAPTERSTATE)
DeclSaveChunk($004C, $0038, MSu_SaveActionState,  MSu_LoadActionState)  // Action State
DeclSaveChunk($0084, $0018, MSa_SaveDungeonState, MSa_LoadDungeonState) // Valni/Lagdou permanent data
DeclSaveChunk($009C, $0200, $0A6370+1,            $0A638C+1)            // Trap data
DeclSaveChunk($029C, $00B0, MSa_SaveConvoy,            MSa_LoadConvoy)            // Convoy Items
DeclSaveChunk($034C, $0460, $0A4264+1,            $0A421C+1)            // BWL Entries
DeclSaveChunk($07AC, $00C0, $0A4288+1,            $0A4248+1)            // Previous chapters turn count & time & stuff
DeclSaveChunk($086C, $0010, MSu_SaveMenuRelated,  MSu_LoadMenuRelated)  // "menu related list" related
// Gap here of 9 bytes, this is because of a previous mistake in allocation
DeclSaveChunk($0885, $0005, $0A3130+1,            $0A3170+1)            // Temporary eids
DeclSaveChunk($088C, $0024, MSa_SaveWMStuff,      MSa_LoadWMStuff,      EMS_CHUNK_WMDATA)
DeclSaveChunk($08B0, $000C, MSu_SaveDungeonState, MSu_LoadDungeonState) // Valni/Lagdou active run data
DeclSaveChunk($08BC, $0004, MSu_SaveEventCounter, MSu_LoadEventCounter) // Event counter

To both the save and suspend data, I still need to modify the other convoy writing routines to actually expand it?

The size mentioned in the ASM you wrote is in reference to the size of the save data, not the convoy, correct? Do I need to expand that to be greater than B0 as well?

13

I think the size of the convoy and the save data should both be 400 bytes since I didn’t bother to compress the save data or anything. The suspend and chapter save schemes are different and behave differently, so you’ll need to edit both of them yes. You don’t need to edit any routines- you just need to update the master event installer.

14

Unless I am not understanding you correctly or not seeing something in the master installer, I think something is still missing.

I have included your save routine in the save and suspend writer as below:

	DeclSaveChunk($0000, $004C, MSa_SaveChapterState, MSa_LoadChapterState, EMS_CHUNK_CHAPTERSTATE)
	DeclSaveChunk($004C, $0008, $0A59E0+1,            $0A5A00+1)            // World map skirmish RNG state
	DeclSaveChunk($0054, $00B0, MSa_SaveConvoy,       MSa_LoadConvoy,            EMS_CHUNK_CONVOYITEMS)
	DeclSaveChunk($0104, $0460, $0A4264+1,            $0A421C+1,            EMS_CHUNK_BWLENTRIES)
	DeclSaveChunk($0564, $00C0, $0A4288+1,            $0A4248+1,            EMS_CHUNK_WINDATA)
	DeclSaveChunk($0624, $0019, $0A3150+1,            $0A3198+1,            EMS_CHUNK_EIDS_PERMANENT)
	DeclSaveChunk($0640, $0004, MSa_SaveBonusClaim,   MSa_LoadBonusClaim,   EMS_CHUNK_BONUSCLAIMDATA)
	DeclSaveChunk($0644, $0024, MSa_SaveWMStuff,      MSa_LoadWMStuff,      EMS_CHUNK_WMDATA)
	DeclSaveChunk($0668, $0018, MSa_SaveDungeonState, MSa_LoadDungeonState) // Valni/Lagdou permanent data
	DeclSaveChunk(0, 0, 0, $0177C4+1) // Clear units on load

	DeclSaveChunk($0000, $004C, MSa_SaveChapterState, MSa_LoadChapterState, EMS_CHUNK_CHAPTERSTATE)
	DeclSaveChunk($004C, $0038, MSu_SaveActionState,  MSu_LoadActionState)  // Action State
	DeclSaveChunk($0084, $0018, MSa_SaveDungeonState, MSa_LoadDungeonState) // Valni/Lagdou permanent data
	DeclSaveChunk($009C, $0200, $0A6370+1,            $0A638C+1)            // Trap data
	DeclSaveChunk($029C, $00B0, MSa_SaveConvoy,            MSa_LoadConvoy)            // Convoy Items
	DeclSaveChunk($034C, $0460, $0A4264+1,            $0A421C+1)            // BWL Entries
	DeclSaveChunk($07AC, $00C0, $0A4288+1,            $0A4248+1)            // Previous chapters turn count & time & stuff
	DeclSaveChunk($086C, $0010, MSu_SaveMenuRelated,  MSu_LoadMenuRelated)  // "menu related list" related
	// Gap here of 9 bytes, this is because of a previous mistake in allocation
	DeclSaveChunk($0885, $0005, $0A3130+1,            $0A3170+1)            // Temporary eids
	DeclSaveChunk($088C, $0024, MSa_SaveWMStuff,      MSa_LoadWMStuff,      EMS_CHUNK_WMDATA)
	DeclSaveChunk($08B0, $000C, MSu_SaveDungeonState, MSu_LoadDungeonState) // Valni/Lagdou active run data
	DeclSaveChunk($08BC, $0004, MSu_SaveEventCounter, MSu_LoadEventCounter) // Event counter

I included the one ConvoyStuff.lyn.event file in my RomBuildfile and, without any other changes, it seems the routine works without issue as below:

supply
supply960×430 163 KB

However, it doesn’t do anything to change the size of the convoy as it is still 100 items max. If I change the size of the convoy memory from B0 to E2 (what I assume i need if I want 150 items?) and increment the remaining slots to account for the convoy space now being larger.


DeclSaveChunk($0000, $004C, MSa_SaveChapterState, MSa_LoadChapterState, EMS_CHUNK_CHAPTERSTATE)
	DeclSaveChunk($004C, $0008, $0A59E0+1,            $0A5A00+1)            // World map skirmish RNG state
	DeclSaveChunk($0054, $00E2, MSa_SaveConvoy,       MSa_LoadConvoy,            EMS_CHUNK_CONVOYITEMS)
	DeclSaveChunk($0136, $0460, $0A4264+1,            $0A421C+1,            EMS_CHUNK_BWLENTRIES)
	DeclSaveChunk($0596, $00C0, $0A4288+1,            $0A4248+1,            EMS_CHUNK_WINDATA)
	DeclSaveChunk($0656, $0019, $0A3150+1,            $0A3198+1,            EMS_CHUNK_EIDS_PERMANENT)
	DeclSaveChunk($0674, $0004, MSa_SaveBonusClaim,   MSa_LoadBonusClaim,   EMS_CHUNK_BONUSCLAIMDATA)
	DeclSaveChunk($0678, $0024, MSa_SaveWMStuff,      MSa_LoadWMStuff,      EMS_CHUNK_WMDATA)
	DeclSaveChunk($069c, $0018, MSa_SaveDungeonState, MSa_LoadDungeonState) // Valni/Lagdou permanent data

	// $0680

	// Save 62 blue units (62 * 0x2C = $0AA8)
	DeclSaveChunk($06b4, $0AA8, ESU_SaveGameUnits, ESU_LoadGameUnits, EMS_CHUNK_SAVEUNITS)

For experimental purposes, I only did the save data, not suspend.

The result is below when working with an existing save (that I knew would be broken, but it let me try to fill up the convoy)

supply_2

Essentially, I’m able to get your routine to save and suspend data properly, but it doesn’t change the size of the convoy.

15

That’s correct, it only saves the expanded convoy. To actually have an expanded convoy, you’ll need another hack.

3 Likes
16

So when I try to expand the convoy size to 150, I will likely need to repoint the gConvoyItemArray located at 0x203A81C to a new area in the WRAM(?) as it normally only stores 100 items from what I can see.

Is there any good map of what an FE8 ROMs WRAM looks like? The closest thing I’m aware of are the .sym file that gets generated by the skill system (or FEBuilder?) and jj’s old document, but the former wouldn’t tell me where free space is unless I want to guess after the debuff table and the latter seems incomplete.

1 Like
17

I put Vision Quests’s 200-item convoy at 203B200 and haven’t heard about any glitches arising from it.

1 Like
18

Apparently that’s the location of something called the “Expansion_transporter”? But I didn’t see anything in my build files about that.

Looks like it’s working so far and the main problem I’m running into is that I didn’t fully expand the amount of space I really need in the save data.

I’ll keep experimenting on the matter and if I run into a problem I’ll ask again.

1 Like
19

Expansion_transporter sure sounds like convoy expansion, doesn’t it?

20

It does, but my instinct was more it had to do with data written between transfers made by the GC expansions if I were to make an educated guess.

21

I have supported Supply 200 with SkillSystems of FEBuilderGBA.
The source code is also available.
Please refer to it if you like.
This code is based on gamma’s implementation of Supply200.

3 Likes