Is there any known way to have a “Capture Quote” or on-capture flag trigger that’s different from a regular death quote? I understand this is going to be some weird ASM shit, but was just curious if someone had already tried this.
Can someone make a skill that allows to auto heal?
Lemme explain, you open the command menu. You select “heal”. So far so good.
The unit will recover 10 Hp like he uses a vulnerary. What do you think? Can be made with the actual system?
If this is an FEBuilder-specific issue, then this thread isn’t the place for this report. This is for issues that can be reproduced on the Skill System master buildfile.
Yes there’s a way to do anything that’s not limited by the machine. I wouldn’t consider this weird ASM shit, but since this is not behavior that exists to my knowledge, you would need to write new code to accomplish this. Maybe you could replicate the behavior with event ID shenanigans, but you would need to work with ASM for the real deal.
This is absolutely possible, but if you want results, I suggest learning ASM so that you can do these kinds of things yourself.
4 Likes
@Flare: Halve enemy resistance (Skill% activation)
@differs from Luna in that it only negates res
.thumb
.macro blh to, reg=r3
ldr \reg, =\to
mov lr, \reg
.short 0xf800
.endm
.equ CoronaID, SkillTester+4
.equ d100Result, 0x802a52c
@ r0 is attacker, r1 is defender, r2 is current buffer, r3 is battle data
push {r4-r7,lr}
mov r4, r0 @attacker
mov r5, r1 @defender
mov r6, r2 @battle buffer
mov r7, r3 @battle data
ldr r0,[r2] @r0 = battle buffer @ 0802B40A 6800
lsl r0,r0,#0xD @ 0802B40C 0340
lsr r0,r0,#0xD @Without damage data @ 0802B40E 0B40
mov r1, #0xC0 @skill flag
lsl r1, #8 @0xC000
add r1, #2 @miss
tst r0, r1
bne End
@if another skill already activated, don't do anything
@check for Corona proc
ldr r0, SkillTester
mov lr, r0
mov r0, r4 @attacker data
ldr r1, CoronaID
.short 0xf800
cmp r0, #0
beq End
@if user has sure shot, check for proc rate
@check if we are hitting res with our attack
mov r0,r4
add r0,#0x4C
ldr r2,[r0] @r0 = weapon ability word
@is magic weapon: bit 0x00000002
@is magic sword: bit 0x00000040
@either mean we hit res
mov r0,r2
ldr r1,=#0x00000002
and r0,r1
cmp r0,r1
beq ActivateSkill
ldr r1,=0x00000040
and r0,r1
cmp r0,r1
bne End
ActivateSkill:
ldrb r0, [r4, #0x15] @skill stat as activation rate
mov r1, r4 @skill user
blh d100Result
cmp r0, #1
bne End
@if we proc, set the offensive skill flag
ldr r2,[r6]
lsl r1,r2,#0xD @ 0802B42C 0351
lsr r1,r1,#0xD @ 0802B42E 0B49
mov r0, #0x40
lsl r0, #8 @0x4000, attacker skill activated
orr r1, r0
ldr r0,=#0xFFF80000 @ 0802B434 4804
and r0,r2 @ 0802B436 4010
orr r0,r1 @ 0802B438 4308
str r0,[r6] @ 0802B43A 6018
ldrb r0, CoronaID
strb r0, [r6,#4]
NegateDefenses:
@if so, recalculate damage with def/2
ldrh r0, [r7, #6] @final mt
ldrh r1, [r7, #8] @enemy def
lsr r1,#1 @/2
sub r0,r1
ldr r2, [r6]
mov r1, #1
tst r1, r2
beq NoCrit
@if crit, multiply by 3
lsl r1, r0, #1
add r0, r1
NoCrit:
cmp r0, #0x7f @damage cap of 127
ble NotCap
mov r0, #0x7f
NotCap:
strh r0, [r7, #4] @final damage
End:
pop {r4-r7}
pop {r15}
.align
.ltorg
SkillTester:
@POIN SkillTester
@WORD CoronaID
Naive fix for Flare bug pointed out by @blood . I tested it and it seems to work, however I’m not 100% sure it works for magic swords.
2 Likes
It has been reported that Skill Forager and Aptitude have stopped working.
str / mag split may be involved.
these have been fixed for a while
2 Likes
In SkillSystems passive booster, the setting position of STAT_CON and STAT_MOV is opposite to the regulation.
This proposal solves that.
#define STAT_HP 0x00
#define STAT_POWER 0x01
#define STAT_SKILL 0x02
#define STAT_SPEED 0x03
#define STAT_DEFENSE 0x04
#define STAT_RESISTANCE 0x05
#define STAT_LUCK 0x06
-#define STAT_CON 0x07
-#define STAT_MOV 0x08
+#define STAT_MOV 0x07
+#define STAT_CON 0x08
If search with STAT_CON, STAT_MOV, it will also hit asm.
It just doesn’t seem to be referenced.
However, it is not good that the values are different, so I think that it should be corrected.
-.equ STAT_CON, 0x7
+.equ STAT_CON, 0x8
-.equ STAT_MOV, 0x8
+.equ STAT_MOV, 0x7
The asm instances are unreferenced, but their corresponding locations are reversed,
1 Like
Discussed in the Discord channel: Personal skills set to level 255 do not load if the unit spawns as a promoted class. Seems to be treated the same as level 1 skills which, due to the mutually exclusive nature of personal unpromoted (up to level 20 only) and promoted (above level 20 only), makes it not load.
The discussion included whether there’s any reason to keep it mutually exclusive.
1 Like
Arch, Dan and I were talking today and we had a pretty good idea to address the criticisms ghast had of default skill system usage.
Dan mentioned that when installing the skill system in FEB, so many things happen that it can be overwhelming for new hackers to realise everything they’ve installed. And part of that is that every class gets a big skill list with like, 4 skills. So by default, we have new hackers throwing in the skill system and getting a mess of skills which maybe they’re intimidated by and don’t know how to handle.
My suggestion is to remove most of the skills from the class level up lists. Some should be left there as an example on how to actually set up level up lists but if we remove most of them, beginners will have less things to initially worry about. This would also be good for newer buildfile hackers since building up skill lists instead of paring down defaults means that developers have to make a conscious decision to put a skill in rather than make the decision of removing a skill.
I guess it’s possible that we could just pass over a much emptier level up list when FEB builds the patch for it but I also feel that there’s merit in just paring down that list anyway. I do feel that getting developers to create their skill lists would encourage people to actually customise things.
6 Likes
I think the best way to do this would be to just have a definition so people can choose to include or not the default skill lists. I don’t think going halfway and making a reduced list makes sense.
6 Likes
I don’t see how this is of concern to the skill system development. If you don’t personally like the skill lists, you can change them. It’s not the skill system’s goal to police what people decide to do with the skill lists. An option for a “clean” install with no skills applied by default (except the vanilla ones I guess) would make the most sense and is something I’ve written for myself already.
11 Likes
I believe I have found a solution to the capture bug.
.thumb
.global Item_TURange
.type Item_TURange, %function
.global Item_TURangeBuilder
.type Item_TURangeBuilder, %function
.include "_TargetSelectionDefinitions.s"
@.equ RangeBuilder, OffsetList + 0x0
@parameters:
@r0 = char pointer
@r1 = targeting condition routine pointer
@r2 = item id
Item_TURange:
push {r4-r5, r14}
@mov r4, r0
mov r4, r1
mov r5, r2
ldr r2, =#SelectedUnit
str r0, [r2]
ldr r0, =RangeMapRows
ldr r0, [r0]
mov r1, #0x0
ldr r3, =FillMap @clear out range map
mov r14, r3
.short 0xf800
mov r0, r4
mov r1, r5
@mov r2, r6
@ldr r3, RangeBuilder
@_blr r3
bl Item_TURangeBuilder
pop {r4-r5}
pop {r3}
bx r3
.ltorg
.align
@.equ GetItemRange, OffsetList + 0x0
@.equ ConditionCheck, OffsetList + 0x4
.equ DrawRange, OffsetList + 0x0
.equ Is_Capture_Set, OffsetList + 0x4
@parameters:
@SelectedUnit = char pointer
@r0 = targeting condition routine pointer
@r1 = item id
Item_TURangeBuilder:
push {r4-r7, r14}
mov r7, r0
mov r6, r1
ldr r5, =SelectedUnit
ldr r5, [r5]
mov r0, r5
ldrb r0, [r5, #0x10]
ldrb r1, [r5, #0x11]
_blh RefreshTargetList
@check for capture
ldr r0, Is_Capture_Set
cmp r0, #0x0
beq NotCapture
mov lr, r0
mov r0, r5
.short 0xf800
cmp r0, #0
beq NotCapture
ldr r4, =0x00010001 @capture is always 1 range
b GotRangeC
NotCapture:
mov r0, r5
mov r1, r6
@ldr r3, GetItemRange
@bl Jump
bl ItemRangeGetter
mov r4, r0
b GotRange
GotRangeC:
ldrb r0, [r5, #0x10]
ldrb r1, [r5, #0x11]
mov r2, r4
ldr r3, DrawRange
bl Jump
ldrb r0, [r5, #0x10]
ldrb r1, [r5, #0x11]
mov r2, r4
ldr r3, DrawRange
bl Jump
b End
GotRange:
ldrb r0, [r5, #0x10]
ldrb r1, [r5, #0x11]
mov r2, r4
ldr r3, DrawRange
bl Jump
mov r0, r7
cmp r0, #0x0 @skip check if no targeting condition
beq End
@ldr r3, ConditionCheck
ldr r3, =CheckUnitsInRange+1
bl Jump
End:
pop {r4-r7}
pop {r3}
Jump:
bx r3
.ltorg
.align
OffsetList:
The issue is with the Item_TURange logic. Specifically, the CheckUnitsInRange routine gets run again when you try and capture an enemy, messing up the targeting array. The fix I’ve provided attempts to skip over that extra routine check. I’m not exactly sure why everything in this routine gets run, so I’ve tried to only have it slightly deviate from the norm. From my initial testing, it does the job, but I am not sure if it results in other issues.
1 Like
I noticed myself while testing staff related stuff that range getters were running twice
SkillSystems Berserk glitch.
Enemies in Berserk state do not kill each other.
20191022 <- Work.
20200211 <- Glitch.
It seems that something happened last winter.
About Bersek Glitch
This is a Shade+ Skill bug.
It’s happening because Shade+ hooks 0x3d5a0.
If you remove the Shade+ hook, Berserk will work correctly.
I don’t know what the cause to this actually was, it doesn’t seem emulator-specific so probably just some stack trickery or smth
2 Likes
FEBuilder version - “Shade” skill doesn’t seem to work, at least not following similar logic as “Provoke” skill. Enemies will target “Shade” unit even with other targets available.
Shade+ is the inverse skill of Provoke. Shade only lowers their priority on the enemy’s kill list; it doesn’t remove them outright.
3 Likes
Focus doesn’t work properly on enemies, they always receive the bonus even if there are other enemies within 3 spaces.
It seems that it only checks for ally units, even if the skill is on the enemy.
Edit:
Anathema seems to reduce the C. Avoid beyond 0. Is that intended?