Can you insert manaketes in an fe7 hack

[gster50]

Can you have manaketes in fe7?

[AstraLunaSol]

nope

[Crimson Red]

yes

[JFierce]

I imagine you could since a class is just made of battle animations, some sprite associations like map sprites and stats no? You'd just have to do the work to insert it.

Edited February 26, 2013 by JFierce

[Gryz]

But Manaketes behave differently than normal classes since they have to do that transformation-thingy right at the beginning of battle. I guess "technically" you can have Manaketes, but as far as I am aware, no one yet has done the asm magic ritual necessary to make it happen... or I suppose you could have a battle sprite that is already transformed, but that would be removing the cool part.

[shadowofchaos]

nope

yes

The assumption here is he means the way FE6 and FE8 loads it. If that's what he means, it ain't happening without assembly.

Now as for regular manaketes? Just use an inserted manakete animation.

There will be no transformation. So the "yes and no" answer is correct.

[gster50]

how would you handle dragonstones, specifically making them usable only for the manaketes, and having the manaketes being unable to use anything else? And what is assembly, do you mean event assembler, thanks for the help

Edited February 26, 2013 by gster50

[shadowofchaos]

Do it like the FE7 Final Boss Dragon does.

Dragonstone Weapon Lock.

[Crimson Red]

The question was

"Can you have manaketes in fe7?"

more specifically

"Can you insert manaketes in an fe7 hack"

(yes, the topic title was slightly more descriptive than the actual post)

the answer is yes

I can

naturally the answer changes for the person who answers it

and if s/he wants a better answer, s/he needs a better question, one where there's less assumptions/details left out

[gster50]

The question was

"Can you have manaketes in fe7?"

more specifically

"Can you insert manaketes in an fe7 hack"

(yes, the topic title was slightly more descriptive than the actual post)

the answer is yes

I can

naturally the answer changes for the person who answers it

and if s/he wants a better answer, s/he needs a better question, one where there's less assumptions/details left out

As specifically as possible, I'd like to have a manakete class( a class I'd have to create due to the lack of manaketes in the game) that functions as closely as possible to the class's in 6 and 8(and subsequent games) that basically just means uses dragonstone, which boost stats, and has a manakete animation, it sounds like having the manakete transform on the defensive is impossible( or at least too hard to attempt,) I guess I could just insert the transformation in the attack frames and have the manakete defend in base form, of course they would have to revert to their base form in between a double attack, but I guess it's better than nothing. If anyone has a solution to this I would glad to hear it. Also I forgot about the fire dragons dragonstone, so I guess that would resolve the weapons problem.

Edited February 26, 2013 by gster50

[CT075]

that is workable

[JFierce]

Yerp would be through custom animation. Sadly I haven't learned much on that front. My friends doing the battle animation side of my hack. I imagine it would be in the attack animations though yes. Though I'm not sure how it would work with double attacks, you'd have to know how to get it to stay in form and attack. That might be hard.

Stat boosts, there's an editor in Nightmare, if the fire dragon stone doesn't do it for you, make your own. Item editing is fairly straightforward.

[CT075]

there is no way to make it stay in form between attacks without assembly

[gster50]

there is no way to make it stay in form between attacks without assembly

Does assembly mean doing it through the Feditor, or is it something else? I can insert regular animations via the FEditor, could the FEditor allow the transformation at the appropriate times? If assembly is something else, how do I learn how to do it. are there any tutorials written?

[CT075]

BDRH_ST:
push	{r1-r7, r14}		@ blah blah blah
mov		r5, r0				@
mov		r7, r1				@
mov		r1, r5				@
add		r1, #0x7B			@ data at index 0x7B
ldrb	r0, [r1]			@
add		r0, #0x1			@ whee
strb	r0, [r1]			@ store it back
ldr		r6, =0x0203A50C		@ Location of buffer pointer
ldr		r1, [r6]			@ get the buffer pointer
mov		r0, #0x2			@ r0 = 2
ldrh	r1, [r1]			@ doop
and		r0, r1				@ check second bit
cmp		r0, #0x0			@ If the second bit is set, that means the attack missed.
bne		FINALIZE			@ Therefore, we can skip the rest of this.
mov		r4, r5				@
add		r4, #0x48			@
ldrh	r0, [r4]			@ i am just taking a ton of this from the original
BDRH_CALL	0x08017424		@ Load equipped item data
mov		r4, r0				@ store this data
ldr		r0, [r6]			@ load buffer pointer
cmp		r4, #0x0			@ if there is no data,
beq		NO_STATUS			@ no effect
cmp		r4, #0x8			@ Otherwise...
ble		APPLY_STATUS		@ apply status
cmp		r4, #0xB			@ check for half HP
bne		NO_STATUS			@

HALF_HP:
mov		r3, #0x80			@ blah
lsl		r1, r3, #0x2		@ r1 = 0x0200
b		APPLY_FLAG			@

APPLY_STATUS:
mov		r1, r7				@ \
add		r1, #0x6F			@ - taken from the actual routine
strb	r4, [r1]			@ doop doop
mov		r1, #0x40			@ flag

APPLY_FLAG:
ldrh	r2, [r0]			@ whoop
orr		r1, r2				@ de doo
strh	r1, [r0]			@ Store the flags back into r0

@ This could probably be done much more neatly, but that would mean i trust myself not
@ to screw anything up on accident. Best stick to the original for now.
NO_STATUS:
ldr		r3, =0x0203A3D8		@ get damage offset
cmp		r4, #0xC			@ check for devil
bne		NO_DEVIL			@ hee

CHECK_DEVIL:
mov		r1, #0x19			@
ldsb	r1, [r5, r1]		@ load attacker luck
mov		r0, #0x1F			@ r0 = 31
sub		r0, r0, r1			@ r0 -= r1 (31 - luck)
lsl		r0, r0, #0x10		@ \
lsr		r0, r0, #0x10		@ r0 = (short) r0
mov		r1, #0x0			@ r1 = 0x0
push	{r3}
BDRH_CALL	0x0802857C		@ Most likely checks to see if it procs.
pop		{r3}
lsl		r0, r0, #0x18		@ blah
cmp		r0, #0x0			@ if r0 << 18 != 0
beq		NO_DEVIL			@ apply_devil()

APPLY_DEVIL:
ldr		r1, [r6]			@ load data buffer again
mov		r0, #0x80			@ obv
ldrh	r2, [r1]			@ get buffer
orr		r0, r2				@ apply flag
strh	r0, [r1]			@ store back buffer
ldrb	r1, [r5, #0x13]		@ attacker hp
ldrb	r0, [r3, #0x4]		@ get damage
sub		r0, r1, r0			@ r0 = hp - damage
strb	r0, [r5, #0x13]		@ store it back
lsl		r0, #0x18			@ same as regular routine
cmp		r0, #0x0			@ if hp is negative...
bge		label3				@ store 0 as hp instead
mov		r0, #0x0			@ what
strb	r0, [r5, #0x13]		@ store it back
b		label3				@ doop

NO_DEVIL:
mov		r2, #0x13
ldsb	r2, [r7, r2]		@ i swear if this fails
mov		r1, #0x4			@ prepare r1
ldsh	r0, [r3, r1]		@ to reload damage
cmp		r0, r2				@
ble		label2				@ if damage > hp
strh	r2, [r1, #0x4]		@ whoooo

label2:
ldrb	r1, [r3, #0x4]		@ Load damage again
sub		r0, r2, r1			@ r0 = hp - damage
strb	r0, [r7, #0x13]		@ whoop
lsl		r0, r0, #0x18		@ etc
cmp		r0, #0x0			@ ha
bge		label3				@ useless check?
mov		r0, #0x0			@
strb	r0, [r7, #0x13]		@ I dunno

label3:
cmp		r4, #0xA			@ check for HP stealing
bne		FINALIZE			@ blah

HP_STEAL:
@ r1 is still damage
ldrb	r3, [r5, #0x13]		@ Get attacker hp
add		r0, r3, r1			@ r0 = hp + damage
strb	r0, [r5, #0x13]		@ store hp back into attacker
lsl		r0, r0, #0x18		@
ldrb	r2, [r5, #0x12]		@ r2 = max hp
lsl		r1, r2, #0x18		@ dunno
@ Comment the following two lines to apply the "damage <= HP" effect
cmp		r0, r1				@ if new hp > max hp
ble		label4				@
strb	r2, [r5, #0x13]		@ store max hp as new hp

label4:
ldr		r1, [r6]			@ get damage buffer
mov		r2, #0x80			@ hoo
lsl		r2, #0x1			@ doop
ldrh	r3, [r1]			@ get buffer
orr		r2, r3				@ flip bit
strh	r2, [r1]			@ store back

FINALIZE:
ldr		r1, [r6]			@ get buffer
ldr		r3, =0x0203A3D8		@ when in doubt, brute force it
ldrh	r0, [r3, #0x4]		@ damage
strb	r0, [r1, #0x3]		@ hoo
mov		r0, #0x2			@ ha
ldrh	r1, [r1]			@ load halfword
and		r0, r1				@ check if second bit is flipped
cmp		r0, #0x0			@
beq		HIT_ATTACK			@

MISSED_ATTACK:
ldr		r0, [r5, #0x4C]
mov		r1, #0x82
and		r0, r1
cmp		r0, #0x0
beq		END

HIT_ATTACK:
mov		r4, r5
add		r4, #0x48
ldrh	r0, [r4]			@ get weapon data
BDRH_CALL	0x08016730		@ subtract one from weapon usage? Probably not.
strh	r0, [r4]			@ store it back
lsl		r0, #0x10
cmp		r0, #0x0
bne		END					@ This does something with the weapon, dunno what.
mov		r1, r5
add		r1, #0x7D
mov		r0, #0x1			@ "Is weapon broken?"
strb	r0, [r1]

END:
pop		{r1-r7}
pop		{r0}
bx		r0
BDRH_END:

(for those interested, it is the source code for the status swords patch)

this is assembly

it's basically the raw gears and shit of the game

if you want to learn i learned from here and various GBAdev docs and stuff

Edited February 27, 2013 by CT075

[Crimson Red]

there are tutorials in general but none of them are really all that good IMO, they might help a bit but IIRC assembly is a programming language so you'd kind of be learning how to hack the core engine of the game XP

it's generally considered the hardest and most obscure part of hacking, there's actually a good amount of documentation on the ASM for FE7 but even then not everything is known, in fact I think it's safe to say most of the ASM is undocumented...

As for your question, generally speaking it's not very easy to get a full working implementation in. In my hack Sacred Contention, I settled for a simple untransforming Manakete, the reason being that it was simple and I didn't have to give myself a headache for it. While small details can often lead to a much more pleasurable experience in a hack, hacking was also a hobby for me, so I wouldn't want to invest more time/effort into something than I felt it'd be worth (the "reward" being the fun/pleasure of seeing the final product culminate and playing it etc.). If it's something you really want to do know, the only thing stopping yourself is you, really--it's definitely possible to have various transformations and stuff, since FE8 did it, it's just not going to be a walk in the park for most people... or anyone, probably

[CT075]

i think ryru got it but he's a fucking genius so

[gster50]

BDRH_ST:
push	{r1-r7, r14}		@ blah blah blah
mov		r5, r0				@
mov		r7, r1				@
mov		r1, r5				@
add		r1, #0x7B			@ data at index 0x7B
ldrb	r0, [r1]			@
add		r0, #0x1			@ whee
strb	r0, [r1]			@ store it back
ldr		r6, =0x0203A50C		@ Location of buffer pointer
ldr		r1, [r6]			@ get the buffer pointer
mov		r0, #0x2			@ r0 = 2
ldrh	r1, [r1]			@ doop
and		r0, r1				@ check second bit
cmp		r0, #0x0			@ If the second bit is set, that means the attack missed.
bne		FINALIZE			@ Therefore, we can skip the rest of this.
mov		r4, r5				@
add		r4, #0x48			@
ldrh	r0, [r4]			@ i am just taking a ton of this from the original
BDRH_CALL	0x08017424		@ Load equipped item data
mov		r4, r0				@ store this data
ldr		r0, [r6]			@ load buffer pointer
cmp		r4, #0x0			@ if there is no data,
beq		NO_STATUS			@ no effect
cmp		r4, #0x8			@ Otherwise...
ble		APPLY_STATUS		@ apply status
cmp		r4, #0xB			@ check for half HP
bne		NO_STATUS			@

HALF_HP:
mov		r3, #0x80			@ blah
lsl		r1, r3, #0x2		@ r1 = 0x0200
b		APPLY_FLAG			@

APPLY_STATUS:
mov		r1, r7				@ \
add		r1, #0x6F			@ - taken from the actual routine
strb	r4, [r1]			@ doop doop
mov		r1, #0x40			@ flag

APPLY_FLAG:
ldrh	r2, [r0]			@ whoop
orr		r1, r2				@ de doo
strh	r1, [r0]			@ Store the flags back into r0

@ This could probably be done much more neatly, but that would mean i trust myself not
@ to screw anything up on accident. Best stick to the original for now.
NO_STATUS:
ldr		r3, =0x0203A3D8		@ get damage offset
cmp		r4, #0xC			@ check for devil
bne		NO_DEVIL			@ hee

CHECK_DEVIL:
mov		r1, #0x19			@
ldsb	r1, [r5, r1]		@ load attacker luck
mov		r0, #0x1F			@ r0 = 31
sub		r0, r0, r1			@ r0 -= r1 (31 - luck)
lsl		r0, r0, #0x10		@ \
lsr		r0, r0, #0x10		@ r0 = (short) r0
mov		r1, #0x0			@ r1 = 0x0
push	{r3}
BDRH_CALL	0x0802857C		@ Most likely checks to see if it procs.
pop		{r3}
lsl		r0, r0, #0x18		@ blah
cmp		r0, #0x0			@ if r0 << 18 != 0
beq		NO_DEVIL			@ apply_devil()

APPLY_DEVIL:
ldr		r1, [r6]			@ load data buffer again
mov		r0, #0x80			@ obv
ldrh	r2, [r1]			@ get buffer
orr		r0, r2				@ apply flag
strh	r0, [r1]			@ store back buffer
ldrb	r1, [r5, #0x13]		@ attacker hp
ldrb	r0, [r3, #0x4]		@ get damage
sub		r0, r1, r0			@ r0 = hp - damage
strb	r0, [r5, #0x13]		@ store it back
lsl		r0, #0x18			@ same as regular routine
cmp		r0, #0x0			@ if hp is negative...
bge		label3				@ store 0 as hp instead
mov		r0, #0x0			@ what
strb	r0, [r5, #0x13]		@ store it back
b		label3				@ doop

NO_DEVIL:
mov		r2, #0x13
ldsb	r2, [r7, r2]		@ i swear if this fails
mov		r1, #0x4			@ prepare r1
ldsh	r0, [r3, r1]		@ to reload damage
cmp		r0, r2				@
ble		label2				@ if damage > hp
strh	r2, [r1, #0x4]		@ whoooo

label2:
ldrb	r1, [r3, #0x4]		@ Load damage again
sub		r0, r2, r1			@ r0 = hp - damage
strb	r0, [r7, #0x13]		@ whoop
lsl		r0, r0, #0x18		@ etc
cmp		r0, #0x0			@ ha
bge		label3				@ useless check?
mov		r0, #0x0			@
strb	r0, [r7, #0x13]		@ I dunno

label3:
cmp		r4, #0xA			@ check for HP stealing
bne		FINALIZE			@ blah

HP_STEAL:
@ r1 is still damage
ldrb	r3, [r5, #0x13]		@ Get attacker hp
add		r0, r3, r1			@ r0 = hp + damage
strb	r0, [r5, #0x13]		@ store hp back into attacker
lsl		r0, r0, #0x18		@
ldrb	r2, [r5, #0x12]		@ r2 = max hp
lsl		r1, r2, #0x18		@ dunno
@ Comment the following two lines to apply the "damage <= HP" effect
cmp		r0, r1				@ if new hp > max hp
ble		label4				@
strb	r2, [r5, #0x13]		@ store max hp as new hp

label4:
ldr		r1, [r6]			@ get damage buffer
mov		r2, #0x80			@ hoo
lsl		r2, #0x1			@ doop
ldrh	r3, [r1]			@ get buffer
orr		r2, r3				@ flip bit
strh	r2, [r1]			@ store back

FINALIZE:
ldr		r1, [r6]			@ get buffer
ldr		r3, =0x0203A3D8		@ when in doubt, brute force it
ldrh	r0, [r3, #0x4]		@ damage
strb	r0, [r1, #0x3]		@ hoo
mov		r0, #0x2			@ ha
ldrh	r1, [r1]			@ load halfword
and		r0, r1				@ check if second bit is flipped
cmp		r0, #0x0			@
beq		HIT_ATTACK			@

MISSED_ATTACK:
ldr		r0, [r5, #0x4C]
mov		r1, #0x82
and		r0, r1
cmp		r0, #0x0
beq		END

HIT_ATTACK:
mov		r4, r5
add		r4, #0x48
ldrh	r0, [r4]			@ get weapon data
BDRH_CALL	0x08016730		@ subtract one from weapon usage? Probably not.
strh	r0, [r4]			@ store it back
lsl		r0, #0x10
cmp		r0, #0x0
bne		END					@ This does something with the weapon, dunno what.
mov		r1, r5
add		r1, #0x7D
mov		r0, #0x1			@ "Is weapon broken?"
strb	r0, [r1]

END:
pop		{r1-r7}
pop		{r0}
bx		r0
BDRH_END:

(for those interested, it is the source code for the status swords patch)

this is assembly

it's basically the raw gears and shit of the game

if you want to learn i learned from here and various GBAdev docs and stuff

Edited February 27, 2013 by gster50

[CT075]

if you can get it working all the more power to you

i would personally be wary of it because i am a mediocre hacker at best (and the fe8 manakete shit is pretty fucking complicated, especially compared to that simple one i posted) but my limitations shouldn't stop you

[gster50]

Damn, the bastards at nintendo couldn't have put 1 freaking manakete in that game? Any way I'll try and see if I can get the hang of this assembly thing, but it's evident that it will be quite an undertaking provided I even can manage to accomplish it, but I guess nothing ventured nothing gained. Thanks to all who responded it was very helpful, and I think I know how to proceed to pursue this effect, I'm gonna give it whirl, and see what happens. Even if I can't pull it off, a least I'll learn a little.

[zahlman]

They didn't put in manaketes because they weren't part of the story.

Assembly = re-coding the game basically, or at least adding to/modifying the actual game code. Clearly it's possible to have such code, because other GBA games have it. But it's not there in 7 so it needs to be put in. This is not remotely close to being a beginners' task; it's at least as hard as it was for the developers at IS to do it in the first place (they presumably had much more sophisticated tools), and they're paid professionals.