Obscure Hacking Tips

[Crimson Red]

^seems more like a hacking obscurity than an obscure tip

@Primefusion sadly I can't offer much insight besides what's there, I pretty much told NL what little I knew that he didn't very early into the EA's development (he's much smarter than me so he figured out a lot more than I did)

I think _0x6E is just a variation of DISA or something but co-ordinate based

I think the _0xA? codes are tutorial-related and probably not that useful/probably would take ASM knowledge to make any real use of

The _LIGHTNING code is pretty particular with its values, for most of these codes it's easier to disassemble the chapters they're mentioned to be in, find the code, and copy it, and aside from the one that changes the color scheme of the entire window, you *probably* won't get to edit them beyond their original intent much. It's not to say that it can't be done but like, I don't really know what those values do either, and it's hard to figure out, and you'd have to really know what it's doing to make practical use of it because they're really like codes used once or twice for some special effects like the ones in cutscenes when you're in Dragon's Gate and stuff.

If it helps I think 0xE0-0xE2 are all related to changing the color with some of the latter values in one of the codes controlling the actual hue and one of the codes is used to like, start the change (0xE1?) and the other is used to end it (0xE2?) but this is all off the top of my head and you could probably deduce the same thing after 2 minutes of looking at it in a disassembled script

tl;dr I would love to help but I don't really know anything XD Sorry about that.

[Aleph]

It's more pragmatic than posting excplicit addresses of random data you've located, which would be more appropriately placed in some kind of collection of notes about memory maps.

Edited September 27, 2013 by Solais

[Crimson Red]

too bad I don't give a crap

[Agro]

If it wasn't already obvious enough, to add to what Blazed said, you can totally use events as death quotes and battle conversations, meaning you can add conditions to them, as well--that way, if you wanted a certain death quote to play if event ID X is triggered etc. then you can do that. Additionally, it means that you can flag more than one event ID when someone dies. Normally this wouldn't have a lot of applications, but there's one particularly interesting use for it. In FE7, if you flag ID 0x04 as "true", then the alternate music as marked in the Chapter Data Editor will play. So, if you wanted to, you could do an FE5-style system where a different song plays when someone dies, and then have a turn event that unflags 0x04 so that the normal music comes back.

You can also find out exactly which offset to put into the event data pointer in the Nightmare module by adding this:

MESSAGE Death quote is at currentOffset

In fact, if you wanted to, you could do all of the death quotes via events in one event file like this. Same goes for battle quotes.

[Auroros]

I don't know how many of you know that, but at least in FE8, the first number before the actual y-coordinate in the chapter unit editors designates the flag the enemy has or if he has one.

I know only 0 or " " (Nothing), 3(last Item drop), and 8 (Monster flag.)

for instance, 38 as y-coordinate is the same place as 8 as the y-coordinate, only the monster has an item drop flag. (Shoutouts to random Berserker dude I made who should drop something but didn't if I deleted the 3.)

This also seems to be a workaround on the Event-assembler random itemchest crash, as you don't have to dissassemble everything just to change the flags. And it *should* (haven't tested yet) work on Reinforcements as well, which event assembler doesn't at all. Also, if you set a flag in event assembler, you have to keep that flag in mind. for instance, Tower of valni 1, Boss dude. He has in my event assembler files a drop flag. if I give him an 8x, he has a correct flag but is moved around a whole bunch. However, if I give him a 11x, he works just fine. everyone else, who don't have drop flags, work with just 8x. <--- disregard that.

...

Please don't tell me everyone knew this already...

I would really dislike to make an ass out of myself...

EDIT:

Okay, it is not *quite* that easy. you have to loop the map vertically once, then you get drop flags. It seems that the farest y-coordinate down is 31, 32 is then essentially 0 + drop flag. (Found out during valni tests).

Monster flag still seems to be 8x (x being actual y-coordinate), though the boss of valni makes trouble there...

Edited October 3, 2013 by Auroros

[Aleph]

The byte simply allocates only some of its bits to the Y coordinate and some to the "Flags". You are not "looping the map".

Now would be a good time to learn binary.

[Auroros]

Well, that is a better explaination XD

this further explains why I need 11x for the valni 1 boss to stand in place and have a monster flag. He has a drop flag and I essentially give him those missing bytes to be a monster.

Still, it works... somehow... at least, and since I don't remember to hear about this before, I thought of an explaination and wanted to share.

That I would an ass of myself was to be expected...

So just to make sure I got it right this time, as soon as I hit 31 or 11111, I am at the last 255 x-coordinates before ending the map, now if I increase this by 1, I would push the last bit into the flag part, right? because only five bits are allowed to keep track on the y-coordinates? And would start again at 0 + flag.

[Aleph]

For the most part yes, but there is no 255 involved. Maps can't be greater than 40x40 because there isn't enough memory. It seems this limit resulted in IS limiting the coordinates to 0-31.

[Auroros]

I use the Chapter unit coordinate system. That is, that one y is 255x to the right.

0 is the first line left, 64 is getting one space down, 128 two, 192 three, and 256, would be four, but there is a new y-coordinate for that. That is what I meant with 31 being the last 255 down. However, if maps can be 40x40 at max, this means at an y-coordinate of 10 we would already be at the bottom.

So with that in mind I made another test. it seems that 1111, 15 or F is the max for the y-coordinate and with the next one you are already pushing a flag again.

So the actual and Correct obscure hacking tip for Fe8 is:

In the chapter unit editor, if you add 16 to the current y-coordinate of a unit, the unit will be at the correct point + Monster flag. add 32 to make the enemy drop something. Similiary, decrease by 16 if you want to get rid of the Monster flag, decrease by 32 to get rid of the drop flag. You obviously cannot add both drop and monster flags. 48-63 is still a monster flag, so there you can decide between decreasing by 48 or increasing by 16. 64 is again normal and from then it loops. (as in, 64 is normal, 80 is monster, 96 is drop, 112 is again monster, 128 is again normal etc.)

It further seems that this is that what event assembler does with flags, because you can disable flags set in the event assembler that way. or this is how flags are normally set. I don't know. It is, however, faster than using event assembler.

[Aleph]

It would be much more accurate and less convoluted to explain these things in terms of binary.

A correctly modified Nightmare 2.0 module could separate the flag bits from the coordinate bits. All the more reason to quit using the crappy old version.

Either way, you're not "adding 16/32/[some other power of 2]" and bit flags are indeed set and cleared by changing them to 1 and 0 respectively (which is what you are actually doing).

Use MS Calculator if you have to. It has a binary mode and can convert between hexadec and binary easily. There are online calculators with the same functionality

http://home.paulschou.net/tools/xlate/

if for some reason you are masochistic enough to use something other than Windows. No, I am not a fan of Windows. I just find having more programs for the stuff I do (vidya games) more important than killing myself over avoiding Windows.

Edited October 4, 2013 by Solais

[CT075]

OVER A YEAR LATER

This is terribly useful! Good job, guys.

But let me guess, there is no UNCM/UNCR equivalent for FE8.... =P

there doesn't exist one in the native functionality; HOWEVER i was asked to do something similar for MK404's hack

the source is incredibly rough and reading through it now i'm not actually sure what i'd do with it; however i'd touch it up and make it better if there's interest

(inb4 there actually is an equivalent in fe8 and i'm wasting my time)

Edited December 29, 2013 by CT075

[Vennobennu]

Looking though 5x's events to see if there is an equivalent, I first found yet another way to load units in FE8:

_0x3242 0x43 0xA0A

This loads the Chapter 15 version of Valter (0x43 being his character ID) at the coordinates (10,10). Note that the event command doesn't define his class; instead, it takes the class to use from his character data, the one which is also used for the support viewer.

But for the UNCM stuff, here are some snippets of code which I think are related:

End of Chapter 5:
MNC2 0x5// 0x5 is the Chapter ID of 5x
_0xA640 0x0 0x0 0x8
ENDA

Beginning of 5x:
ASMC 0x86415

Start of EndingScene of 5x:
ASMC 0x86465

End of EndingScene of 5x:
_0xA640 0x0 0x0 0x5
MNCH 0x7
ENDA

The _A640 code, and these specific ASMC calls, don't appear anywhere else in the game to my knowledge.

[Alfred Kamon]

Vennobennou, I think that ASM makes you change from Eirika's route to Ephraim's route only for that chapter.

I don't know what that code you found for Valter could serve for, honestly.

@ Cam: That'd be nice. I was trying to get around a similar problem in my chapter 8 where I need to make one of my units invisible: if you manage to make an ASM for that it'd be cool.

[Vennobennu]

Well after 5x Kyle and Forde aren't in your party anymore, but their stats and inventory are conserved.

The _0xA640 command and the offsets called by the ASMC commands don't appear in the LordsSplit events, so I don't think they only change you to Ephraim mode for that chapter.

[Alfred Kamon]

Well after 5x Kyle and Forde aren't in your party anymore, but their stats and inventory are conserved.

The _0xA640 command and the offsets called by the ASMC commands don't appear in the LordsSplit events, so I don't think they only change you to Ephraim mode for that chapter.

Oh right.

Well, I think I'll throw this piece of information here, then:

in my hack the "Kyle" and "Forde" characters reappear in chapter 6.

However, when loaded normally, something strange happened.

You must know that I applied the "move again" patch which allows the player to move mounted units after attacking.

Kyle and Forde could move again with no problems in chapter 5x.

But when I loaded them in chapter 6, they acted like normal units; they basically lost the ability to move again.

Moreover, when I advanced to chapter 7, their data wasn't stored in the RAM anymore-- despite having used them in chapter 6, it was like they died during that chapter.

Now, I only made an assumption, but....

If, rather than dead, they were simply invisible? So I disassembled chapter 8, when Ephraim's Group reappears in Sacred Stones, and I found this code:

_0x3421 unitID

_SETVAL 0x1 0x1

_0x3428 unitID

It should be used immediately after loading the unit specified in that ID.

And voilà! They were able to move again in chapter 6 and actually appeared in chapter 7.

I think I just brought you the code to make units visible.

That's half of the work. Good luck finding out the rest. XD

Edited December 29, 2013 by Alfred Kamon

[Vennobennu]

Just to clarify - ASMC 0x86465 disappears Ephraim's party and gives you back Eirika's; without it, you start Chapter 6 with only Ephraim, Kyle, Forde and Orson.

_0xA640 0x0 0x0 0x5 seems to place you back in Eirika's mode, like Alfred Kamon said; without it, Eirika appears stuck on the middle of the world map, with no paths leading from Serafew, three skirmishes appearing around the world, and the game thinking you're at Chapter 5.

[Alfred Kamon]

So basically that ASM must contain something that "makes units invisible".

If someone looked into that he could probably get the right codes / make another ASM for that easily.

I don't understand anything of assembly, so that's not exactly a task for me.

[Crimson Red]

I don't understand anything of FE8, so that's not exactly a task for me.

[CT075]

tbh you guys are just repeating my research

index 0xC in character data is a bunch of bit flags that i don't actually understand other than if the value in there is 0x00010001 (bit reversed), it disappears the unit

the stuff i linked to you for ASD earlier pretty much exactly replicates this process for units of your choice instead of only ephraim/kyle/forde

i can explain to you how it works if you want

[Vennobennu]

Oh oops, guess I didn't look at your notes very carefully.

Just to make sure I'm reading this right, what the routine does is check the character ID of each character in your party, and if they don't match the ID of Ephraim, Forde, Kyle and Orson, it flips two bits in their character data, which tell the game to exclude them from your party, but keep them stored in memory. Then when 5x ends, it does the same thing in reverse, setting the bit flag on Ephraim's team and unsetting it on Eirika's; except it deletes Orson's data from memory afterwards.

Which makes me wonder: are there are any other combinations of bits which do something?

[Aleph]

These tips are too specific. They are NOT B roll.

[CT075]

Just to make sure I'm reading this right, what the routine does is check the character ID of each character in your party, and if they don't match the ID of Ephraim, Forde, Kyle and Orson, it flips two bits in their character data, which tell the game to exclude them from your party, but keep them stored in memory. Then when 5x ends, it does the same thing in reverse, setting the bit flag on Ephraim's team and unsetting it on Eirika's; except it deletes Orson's data from memory afterwards.

that is correct

Which makes me wonder: are there are any other combinations of bits which do something?

i managed to crash things once or twice messing with that :D

[Crimson Red]

bumpity bump

[3:34:14 AM] ballin1337: ha.

[3:34:17 AM] ballin1337: Let's try this...

[3:35:15 AM] ballin1337: 0x0803327C

[3:35:21 AM] ballin1337: You know how to use a hex editor pretty well?

...

[3:36:01 AM] ballin1337: what do you see at that offset?

...

[3:37:11 AM] Alfred Cm'on!: what do I see... mmh... 0F 20 21 E0

[3:37:20 AM] Alfred Cm'on!: seems... stuff regarding Ephraim

[3:37:23 AM] ballin1337: lol

[3:37:24 AM] ballin1337: 0x0F.

[3:37:33 AM] ballin1337: change it to 0x11.

[3:37:33 AM] Alfred Cm'on!: yup

[3:37:36 AM] Alfred Cm'on!: k

[3:37:44 AM] ballin1337: Then reload your ROM and go to the status menu. Tell me what happens.

[3:38:00 AM] Alfred Cm'on!: k

[3:39:12 AM] ballin1337: You know, earlier I was going to make a comment on how sometimes

[3:39:21 AM] ballin1337: it's only one byte that makes a world of difference.

[3:39:31 AM] ballin1337: In fact, a lot of times this is totally true

[3:39:42 AM] Alfred Cm'on!: ......

[3:39:44 AM] ballin1337: Not just in the way of breaking things, but in making them work how you want to. XD

What the heck are we talking about?

In FE8 chapter 5x the game has an ASMC which is kinda mandatory but also very uh... finnicky. Part of the problem is that it's like, hardcoded to autocursor on Ephraim, so if you don't have the exact character of ID 0x0F there, it causes problems. (There are also other problems with it but that's not what we're talking about here.)

I was going to implement a custom ASM hack just for a specific hack so it would work, but my solution ended up not working good enough. Being that I'm somewhat stubborn and didn't want to give a half-baked solution, I took another approach and said "instead of trying to change Ephraim's data so it shows who we want it to show, let's see if we can't just force it to show another character besides Ephraim's data". Lots of debugging later I found it really is just one byte at 0x3327C (in a hex editor) that controls who is the "leader" for that chapter (note that this also affects the Status screen as well).

Of course not a lot of people hack FE8 so... this is still a little bit obscure but yeah, in case anyone ever has problems with chapter 5x's autocursor, try changing that one byte from 0x0F to the ID of the character that you want to appear as leader.

[Agro]

A very small mercy, but perhaps a useful one:

By using the #include command (?) in the EA you can "include" your other event files all in one so that you don't have to keep switching between text files in the event assembler. For example, I like to do my death quotes with events and have to keep updating them all the time, so at the end of my chapter events file I have this:

#include deathquotesviaevents.txt

This makes the EA treat it like they're one whole event file. Of course, you have to watch out for the following:

1. ensure that there's no #defines or #includes listed twice. You have to remove one from either of them if you want to use all of them

2. each txt has its own ORG at the start (or not, if you want them to come right after each other)

3. you don't have any of the same labels/pointers in each text file

[Aleph]

^ That's because the EA is basically just a preprocessor, which I was just telling Zahlman is why I believe that the EA could just as easily be a bunch of .h files that are compiled using the GNU toolchain for ARM. This of course has the benefit that any assembly or C/++ code written for an FE game could have any event data that it is meant to reference be included in the same project and compiled at the same time, thus causing references to be calculated automatically which otherwise wouldn't be and possibly simplifying the build process tremendously.