Indented blocks?
IFAT 0xoffset
Stuff
ELSE
Stuff
And we can generate event ID and mark them with a $. E.g.
AFEV $Reinforcements TalkEvent $TalkAFEV
(the syntax is probably wrong but you get the idea)
I was hoping for something more akin to like
if (DEAD::Eliwood) {
stuff
}
else {
stuff
}
e:
for that matter it shouldn’t be too hard to jank something together that asm’s simple math conditions
and then other event IDs and stuff can be syntax’d out later
How would the indent system handle looping conditionals? FE8 uses them sometimes and I think it’s possible to do it in FE7 where you have an ENIF appear before its associated condition.
I guess you’d use While and For loop syntax?
… what’s this now? This is new to me. Get Arch to add it to the Eventing guide.
the eventing tutorial is super outdated (again) and doesn’t have FE8 support (and never really did)
Here’s an example of a code in Eirika Chapter 10 that changes the AI of multiple enemies by coordinate, one after another:
ENIF 0x0
IFLE 0x1 0xD 0x0//Checks if queue is empty (slot 0xD is queue counter)
SLOTS_ADD 0x21//Moves new AI to memory slot 0x1 (required for next command)
ADVANCEQUEUE 0xB//Shifts first entry in queue to memory slot 0xB
CHAI2 0xFFFF//Changes AI of unit at coordinates stored to slot 0xB
ELSE 0x0
ENIF 0x1
ENDA
It runs through a bunch of sets of coordinates saved to a queue and changes the AI of the enemy at those coords for each sets of coords it reads.
Yeah I guess we can generate that with for and while. Possibly not doable in FE7 though.
I think I get it though, ELSE acts as a goto. I think there’s a better way to do this but I can’t thikn right now.
that’s so dirty though…
i guess stuff like compiler optimizations (ha!) could probably replicate that, but otherwise I think it might be easier to just compile that to CALL and GOTO
Looks awesome (Y)
Good luck to everyone working on it XD
Just thought I’d share a complaint here that came across my desk this morning.
[8:40:55 AM] FPzero: Hey Arch, I’m running into a major problem with FEditor, surprise surprise
[8:40:55 AM] FPzero: Have you ever had FEditor refuse to expand the rom any more?
[8:41:21 AM] FPzero: Basically, I’m trying to insert some text for character names and it continually writes the names over each other
[8:42:03 AM] FPzero: They characters have different name IDs, but I can write the name on one ID, go to the 2nd ID and change the name there, then go back to the 1st one I just changed and it will now show the second name
[8:43:40 AM] Arch: THat
[8:43:43 AM] Arch: is pretty nuts
[8:44:13 AM] FPzero: I looked at the debug output, it appears to be applying the name change to the same 8 bytes of space
[8:44:41 AM] FPzero: weirder yet is that they aren’t even at the end of the rom, they’re just randomly somewhere in the 15xxxxx range
[8:45:03 AM] FPzero: this is also how I discovered FEditor stores all its text data uncompressed
[8:45:17 AM] Arch: MMmyeah
[8:45:37 AM] FPzero: it’s a very inefficient program
[8:45:58 AM] Arch: anyways the free space allocator functions like it was coded in the middle ages
[8:46:28 AM] FPzero: it’s weird, I’ve just been letting it do its own thing with free space after I blocked off a bank for myself
[8:46:40 AM] FPzero: but suddenly it stops at like, 21.8 MB
[8:47:01 AM] FPzero: which is a non-standard rom size, so it’s not even like it hit 32MB and can’t handle anything bigger than that
[8:47:17 AM] Arch: EN’s at 24.5
[8:47:27 AM] Arch: and I took the same approach
http://puu.sh/fE2Ft/bd78a2ccbd.png
What the fuck does any of this even do? It’s a shame because this really should be one of the most important simple tools (free space management), and literally I’ve never successfully used it and just let FEditor run rampant through my ROMs, and apparently it’s just decided to stop doing so altogether for @FPZero. Literally, all I need is a list of ranges (clicking that button didn’t even DO anything!) and a range input to mark as free space. The current interface is the absolute opposite of “intuitive design.”
That button outputs to the Debug Output window. Speaking of which, let’s see where FEditor says my free space is!
That’s…
Yeah that’s not free space. Good job!
Working with FEditor makes my brain look like this randomized castle whenever I have to use it.
3 Likes
[10:52:08 PM] Crazy Colorz: Also, we should have a external hack file
[10:52:14 PM] Crazy Colorz: With part of it being a script file
[10:52:24 PM] Crazy Colorz: And you do all your hacking and it writes there by cam’s package manager or idk
[10:52:35 PM] Crazy Colorz: It could just do xor diffs or ups or something for each step
[10:52:36 PM] Crazy Colorz: idc
[10:52:38 PM] Crazy Colorz: But4 point is
[10:52:42 PM] Crazy Colorz: The hacking is separate from the rom
[10:52:45 PM] Temp Mael: i am down with this
[10:52:57 PM] Crazy Colorz: and when you want to make a release there’s an export button on FE Editor Suite
[10:53:16 PM] Arch: ohman so when I lose that
[10:53:17 PM] Temp Mael: just converts it into a patch then?
[10:53:18 PM] Arch: I’m rip’d
[10:53:24 PM] Crazy Colorz: Well
[10:53:31 PM] Crazy Colorz: You can also import previous things as the base rom
[10:53:32 PM] Crazy Colorz: Just that
[10:53:40 PM] Crazy Colorz: Then we don’t track what data has been used and what is free
[10:54:09 PM] Temp Mael: i like it
[10:54:36 PM] Temp Mael: you wouldn’t have to worry about allocations until you’ve finished up your hack really
[10:54:49 PM] Crazy Colorz: So FE Editor suite needs
-> Save .hack File
-> Save As .ups
-> Export As ROM file
[10:54:54 PM] Temp Mael: it sounds like it would be more of a project file then?
[10:55:16 PM] Crazy Colorz: And the EditorModule interface needs a
getInfoFromHackFile(string identifier, ???);
saveToHackFile(string identifier, ???);
[10:55:22 PM] Crazy Colorz: Yeah that’s the idea
[10:55:24 PM] Temp Mael: that you could always work on whenever you choose
1 Like
[11:01:10 PM] Crazy Colorz: How about this
[11:01:25 PM] Crazy Colorz: Anything before 0x01000000 is implicitly assumed to be allocated
[11:01:30 PM] Crazy Colorz: Beit for ASM hacks or whatevs
[11:01:46 PM] Crazy Colorz: And anything after, if it’s marked in metadata then is also allocated
[11:01:51 PM] Crazy Colorz: Like
[11:01:59 PM] Crazy Colorz: If we load the rom the first time in FE Editor suite and
[11:02:00 PM] Crazy Colorz: Actually
[11:02:02 PM] Crazy Colorz: You know what
[11:02:07 PM | Edited 11:02:08 PM] Crazy Colorz: Let’s just assume everything is allocated
[11:02:11 PM] Crazy Colorz: Just to be safe
[11:02:14 PM] Crazy Colorz: Because better safe than sorry
[11:02:23 PM] Crazy Colorz: And you can explicitly tell FE Editor suite what IS free
[11:02:30 PM] Crazy Colorz: And it’ll save that in external metadata
Could just auto-expand new roms to 32MB upon first save and let it allocate into the space past 0x1000000 by default.
I’m thinking of having it implicitly free without explicitly expanding it.
i would rather not auto-expand to a specific size just as a design thing
the system i envision would be “if no suitable block in existing free space, append to ROM instead”
Should definitely add an “expand file” option to the hex editor interface too that’ll ask how many bytes of data to tack on at the end of the file; the only functionality clearly lacking from HxD, imo (at least I’ve never found it). I’d be pretty against autoexpansion to 32MB because then all patch sizes are unnecessarily inflated like to an average of 16+MB.
the system i envision would be “if no suitable block in existing free space, append to ROM instead”
This. (An explicit expansion option is also a decent idea, but I think “expand to X total size” is more user-friendly than “add Y bytes”.)
Also it should only automatically mark freespace that’s freed as a result of any work done by the editor, whether by autopatches (if we still have those?) or manual repointing of tables or whatever.
Actually, regarding autopatches, I’m thinking maybe there should be an explicit “apply leet hax” option that allows for adding in whatever stuff. It should be able to do tons of work safely on a base ROM, but give people who’ve already done some work the security of knowing that it won’t accidentally get fucked up by an ASM hack that’s somehow incompatible with some other ASM hack they got someone else to do for them years ago.
I didn’t think of patch sizes and now that I think about it, adding another 16 MB to everything is way bigger than I thought about. All my previous hacking has been on SNES games where the biggest they get to is 4MB.