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.
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.
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.
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.
DefiantCrit Skill conditional expression is reversed.
When HP is full, Crit correction will be applied.
Conversely, if the HP is 1, no correction is applied.
However, the source code DefiantCrit.s is correct.
Only the DefiantCrit.dmp file is wrong.
Perhaps the creator has forgotten to recompile. (ﾟ∀ﾟ)
I’ve implemented the fixes for the issues above as well as written fixes for a number of other issues. Once these are merged in, most logged issues should be resolved.
When HIT exceeds 128, it becomes negative.
This is a display issue only.
If the value is negative, a strange display will occur.
-104
SkillSystems hijacks the Text_AppendNumberOr2Dashes function.
And output negative numbers.
However, HIT can sometimes exceed 128.
At this time, it is processed as a negative value.
To solve this problem, I made a patch that changes the display of HIT to use the original routine.
HIT_rate_unsingned_text.s
.thumb
.macro blh to, reg=r3
ldr \reg, =\to
mov lr, \reg
.short 0xf800
.endm
@Resend the breaking code.
ldsh r3, [r0, r2] @pointer:0203A54C (BattleUnit@gBattleActor.battleHitRate )
mov r0 ,r4
mov r1, #0x24
mov r2, r9
Start:
push {r4,r5,r6}
mov r4 ,r0
mov r5 ,r2
mov r6 ,r3
blh 0x08003e54 @Text_SetXCursor
mov r0 ,r4
mov r1 ,r5
blh 0x08003e60 @Text_SetColorId
mov r0 ,r4
mov r1 ,r6
bl Text_AppendNumberOr2Dashes_Unisngned
pop {r4,r5,r6}
ldr r3,=0x0801E98C+1
bx r3
Text_AppendNumberOr2Dashes_Unisngned:
push {r4,lr}
mov r4 ,r0
cmp r1, #0xff
beq ShowDecNumber
mov r0, #0x1
neg r0 ,r0
cmp r1 ,r0
bne ShowDecNumber
mov r1, #0x8
neg r1 ,r1
mov r0 ,r4
blh 0x08003e58 @Text_Advance
ldr r0, =0x535
blh 0x0800a240 @GetStringFromIndex
mov r1 ,r0
mov r0 ,r4
blh 0x08004004 @Text_AppendString
b Exit
ShowDecNumber:
mov r0 ,r4
blh 0x08004074 @Text_AppendDecNumber
Exit:
pop {r4}
pop {r0}
bx r0
HIT_rate_unsingned_text.event
PUSH
ORG $1E980
jumpToHack(HIT_rate_unsingned_text)
POP
ALIGN 4
HIT_rate_unsingned_text:
#incbin "HIT_rate_unsingned_text.dmp"
After adding this code, the correct numbers will be displayed.
->
Ohhh, I had been wondering what was causing this. Nice job!
Thank you, with this patch magic passive boost is working. However, I also see that move passive boost is not. Is there a similar issue?
Oh, yeah, maybe you already know about this but there’s enough clutter already for me to just put this here, but there may be an issue with Skillsystems doubling the weapon triangle damage bonus and penalty for every unit. I presume this is a carryover with the Triangle Adept skill which is apparently broken from what I have heard.
This isn’t a skill system issue
Looking behind the scenes in a memory viewer for hit,
values here and applied are correct.
Tested on up-to-date skillsys, no units here have Tri Adept nor are they in range of any aura skills.
This isn’t a bug, it’s just vanilla behavior. The way Movement and Constitution stats are obtained in the vanilla game is they are calculated on the spot every time they are needed; this differs from every other stat where there is a specific function dedicated to getting the value, in which stat boosts are checked. Skill System, among other things, includes modular stat getters, which replace the on-the-spot vanilla mov and con gets with proper getters; however, these do not contain by default anything more than the vanilla getters do. For the rest of the stats, there are also dedicated vanilla functions for getting the stat bonus given the item. As there are not these for mov or con and no one wrote them, the vanilla behavior is retained and boosts for mov and con do not function. This carries as well to passive stat boosts, which call the same functions as equip stat boosts under altered conditions. Not a hard thing to add, but not the result of an issue.
thanks for investigating for me.
SkillID 0x12 Discipline Glitch.
The current code forgets to initialize r0.
.equ Skill_ID, SkillTester+4
.equ SkillPlus_ID, Skill_ID+4
.equ DisciplinePlusReturn, 0x802C177
push {r4-r5,r14}
@stuff replaced by callHack
@from $2C138
mov r1, r7
add r1, #0x7B
ldr r1, [r1]
lsl r1, r1, #0x18
asr r1, r1, #0x18
mul r1, r0
@go to skill check
mov r4, r1 @hold that WEXP value for me buddy
ldr r1, SkillPlus_ID
ldr r2, SkillTester
mov r0, r7
mov lr, r2
.short 0xF800 @two byte bl to lr
mov r5, r0 @save vaue in r5 while we check for regular discipline
ldr r1, Skill_ID
ldr r2, SkillTester
+mov r0, r7 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
mov lr, r2
.short 0xF800
orr r0, r5
cmp r0, #0x0
beq NoSkill
lsl r4, r4, #0x1 @double WEXP if you have the skill
cmp r5, #0x0
bne DisciplinePlus
NoSkill:
mov r0, r4
pop {r4-r5}
pop {r1}
bx r1
DisciplinePlus:
mov r0, r4
pop {r4-r5}
pop {r1}
@vanilla code we're skipping over:
add r6, r6, r0
mov r1, #0x0
ldrb r3, [r5, #0x0]
ldr r2, [r7, #0x4]
ldr r0, =DisciplinePlusReturn
bx r0
.ltorg
.align
SkillTester:
@POIN SkillTester
@WORD Skill_ID
@WORD SkillPlus_ID
Does this apply to Discipline+ as well?
This code is very hard to read and , but value be adapted.
The result is saved in the r5 register as orr.
At a glance, it doesn’t look like Discipline+ was broken, but the implementation of it was what broke Discipline.