I apologize, I don’t think I understand. After testing the item still does not display the stat changes on the stat screen. I don’t believe I have applied any patch concerning stat boosters.
If you have the skill system installed, the passive boosters are already integrated with it. Sme seems to already have made a fix for the Mag stat boosters, so just give 7743 some time for him to import it to FEBuilder.
:hector:
In the future, questions about the FEBuilder patch menu would probably be better off in the FEBuilder thread, though. Better to keep this thread clean for skill system stuff, makes it easier to browse.
I made a patch.
Fix Passiv Magic StatBooster Glitch for SkillSystems 20200223
6 Likes
After the Skill System update and the strenght/magic split, we encountered a problem regarding healing staves. Basically, even though, for example, the range of Physic is determined by the magic stat, the amount of healing does not scale on magic but rather on strenght, for all staves. And I can’t understand why. Is there someone here that could help us?
strength and magic are literally the same stat in vanilla
If this is happening then it probably means that whoever did the str magic split forgot to update the routine for calculating the amount healed by staves to make it get the new magic stat.
either that or you somehow broke something
If that really is the problem then you can use this to change what stats are used to calculate the heal amount
If you use this and change the second pointer to whatever the mag getter is then it should work
I can certainly try, but we tried on a “clean” ROM, and it was working normally
Yeah i just checked and it seems to be working properly in the default skill system
So you probably broke something on your end?
I recommend checking to see if you made any edits to the routine for doing the heal amount
Where exactly do we have to look for that?
Also, do you think the first method you suggested could work anyway, even though the problem is in our ROM?
If you’re already familiar with asm the routine for getting the heal amount is at 0x16fb8; you can compare the routine from your rom to the routine from a clean rom to see what has been altered
iirc if you’re using build files you can use ASSERT or PROTECT to figure out what is trying to edit the routine
and i don’t really use febuilder but i assume it has a thing for keeping track of the edits you’ve made
Yes, I believe it should still work
thank you, we’ll try.
So regarding this
We always used FEBuilder for everything, we know nothing about asm. So, we don’t really know how to do what you told us.
If it’s not suspected that this is a Skill System bug now, then this is pretty off topic for this thread. 
2 Likes
Seems it could be worthwhile to have a separate thread specifically for the FEBuilder patch. There’s an awful lot of discourse regarding that version cluttering both this and 7743’s threads up. Or maybe a mod can edit the OP here (since Circles seems pretty inactive) to include a link to the main FEBuilder thread to redirect FEBuilder users if 7743 doesn’t mind.
I understand responsibility for it is a little grey - I don’t think anyone wants to own that patch lmao. Just my two cents.
I thought this was a bug in skillsystems, so I told him to ask a question in this thread.
I’m not using SkillSystems, so I’m not familiar with it.
According to Teraspark’s explanation, this did not seem to be a problem with SkillSystems.
So I think it is a Gorgonath ROM-specific problem.
Knowledge is needed to find out if it is a bug.
Now that the problem has been revealed to be ROM-specific, I’d like to solve it in the FEBuilderGBA thread from now on.
1 Like
I disagree with splitting the SkillSystems thread.
The bug found in SkillSystems of FEBuilderGBA is because it needs to be reported to SkillSystems, so it takes double time.
Also, like this time, if not sure if it’s a SkillSystems bug, you’ll end up reporting this symptom in this thread.
So I don’t think it makes sense to separate threads.
2 Likes
I looked into it in detail.
This is a bug in SkillSystems.
Str or Mag Damage.asm
mov r0,#0x5A
strh r5,[r4,r0]
mov r0,#0x4C
mov r7,#0x14
ldr r0,[r4,r0] //weaponAttributes
mov r5,#0x2
tst r5,r0
beq IsStr
Magic:
mov r7,#0x3A
IsStr:
ldrb r7,[r6,r7]
This routine gets the “weaponAttributes” of the Item and checks if the bit flag of 0x02 (Attacks Res) is valid.
And this routine is the source of the bug.
There are three mistakes in this routine.
Look at these two images.
Heal Staff does not have the “Attacks Res” flag set.
In vanilla, the Staff does not have this flag set.
So when trying to recover with a Staff, this routine refers to power, not magic.
This is one of the causes of the bug.
There is still more.
The Staff seems to have a special routine, and weaponAttributes may be set to 0 when using the Staff.
Of course, bool r = (0 & 0x2); is false, so the power is referenced, not magic.
This is the second mistake.
In addition, vanilla rules are not good for writing this check.
“Attacks Res” flag has been translated as IsMagic by Nightmare.
However, this is incorrect.
The meaning of this flag is to refer to res, not enemy def.
It is very easy to verify this.
Try removing the “Attacks Res” flag from the Fire magic.
The enemy Def should now be used for Fire damage calculations.
In other words, you can create magic that refers to def, not res.
With this routine of the current SkillSystems you cannot make it.
This is the third mistake.
So how do implement this routine correctly?
is to use “weaponType” instead of “weaponAttributes”
You also need to check for the possibility of “Magic sword”.
@BattleUnit@4C word weaponAttributes
@BattleUnit@50 byte weaponType
Let’s actually make it.
Str or Mag Damage.asm
.thumb
.org 0x0
mov r0,#0x5A
strh r5,[r4,r0]
mov r7,#0x14
mov r0,#0x4C @weaponAttributes
ldr r0,[r4,r0]
mov r5,#0x40 @Magic Sword
tst r5,r0
bne Magic @IsMagicSword?
mov r0,#0x50 @weaponType
ldrb r0,[r4,r0]
cmp r0,#0xB @B=Monster's weapon
beq IsStr
cmp r0,#0x4 @0=sword 1=lance 2=axs 3=bow
blt IsStr @IsPhysicalWeapon? 4=staff 5=anima ... 0xff = staff(when alone)
Magic:
mov r7,#0x3A
IsStr:
ldrb r7,[r6,r7]
mov r5,#0x5A
ldrh r0,[r4,r5] @current damage
add r0,r7
strh r0,[r4,r5]
b End
End:
add r4,#0x5A @for stone
bx r14
Also, there was one problem in OE490 actual.
This patch is not compatible with str mag split.
Healing Formula: Staff Might: MAG/2 + Staff Might = Heal
This patch does not work correctly because it calls PowerGetter directly.
–
I forgot to check Monster Weapon in str mag split.
I also my modified the code suggested yesterday.
1 Like
So was this a problem with the skill system itself or some kind of febuilder patch conflict?
The two problems are occurring at the same time.
“Healing Formula: Staff Might: MAG/2 + Staff Might = Heal”
It is true that this patch does not work.
However, even if you do not install this patch, it will not work properly due to the above bug.
I am writing in discord’s FEBuilderHelp,
There is a bug in Skill Boon.
DragonVine also has a bug.
Skill Boon:
On maps with Eggs, incorrect hooks from Boon Skill will destroy enemy stats.
this monster has 204 res and 212 luck
This is a bug in SkillSystems Boon.
//Boon
ORG $188F6
BYTE $40 $B4
callHack_r6(Boon)
Vanilla.
080188F4 D004 beq #0x8018900 //Fixed Skill SkillSystems 20200211 (スキル拡張)@000188F4.bin@BIN
080188F6 0918 lsr r0 ,r3 ,#0x4 //Uninstall SkillSystems Boon@Uninstall SkillSystems Boon_188F6.bin@BIN
080188F8 3801 sub r0, #0x1
080188FA 0100 lsl r0 ,r0 ,#0x4
080188FC 4310 orr r0 ,r2
080188FE 7008 strb r0, [r1, #0x0] //Unit@味方[5].状態とターン
08018900 7809 ldrb r1, [r1, #0x0] # pointer:0202BFE4 (Unit@味方[5].状態とターン ) r1=UnitForm r1=UnitForm
callHack_r6 and a hook with a length of 2 bytes break conditional branches.
Therefore, 0x80018900 and later will be destroyed.
SkillSystems
080188F4 D004 BEQ #0x8018900 <<<<
080188F6 B440 PUSH {r6}
080188F8 4E01 LDR r6, [PC, #0x4] # pointer:08018900 -> 08BC860D
080188FA F0B8 FFED BL 0x080D18D8 //_call_via_r6
080188FE E001 B 0x8018904
08018900 860D 08BC //LDRDATA <<<<
08018904 4008 AND r0 ,r1
修正案
#ifndef jumpToHack_r0
//Hook with r0 for compatibility.
#define jumpToHack_r0(offset) "BYTE 0x00 0x48 0x87 0x46; POIN (offset|0x1)"
#endif //jumpToHack_r0
//Boon
ORG $188F6
BYTE 0x00 0x00
jumpToHack_r0(Boon)
Also change boon.asm.
https://cdn.discordapp.com/attachments/470029781795078175/698344354284306512/Fix_Boon.7z
DragonVeins.event
#define HealTileTrapID 0xC <<<<<<<<<<<<
#define HealTile(XX,YY,HealPercent) "BYTE HealTileTrapID XX YY 0x0 HealPercent 0x0"
#define HealTile(XX,YY,HealPercent,EventID) "BYTE HealTileTrapID XX YY 0x0 HealPercent EventID"
TrapID 0xC is Egg.
@TrapEntry@00 byte x pos
@TrapEntry@01 byte y pos
@TrapEntry@02 byte trap type id 0=Nothing (unused entry) 1=Ballista 2=Wall/Snag 3=Map Change (yes those are actually traps) 4=Fire Trap 5=Gas Trap 6=Map Change too? game supports them but idk where it might be used 7=Arrow Trap 8=? (used?) 9=? (used?) A=Light from Torch Staff B=Mine C=Gorgon Egg? (needs investigating as to in which circumstances) D=Light Rune
@TrapEntry@03 byte ext1
@TrapEntry@04 byte ext2
@TrapEntry@05 byte ext3
@TrapEntry@06 byte ext4
@TrapEntry@07 byte ext5
IDs must not be duplicated.
Since 0xE is free, I think that it should be changed to it.
Due to this bug, when an egg tries to hatch, it will display NO DAMAGE or the egg will display as a HealTile.
This is due to the TrapID colliding with the egg.
2 Likes