The asm instances are unreferenced, but their corresponding locations are reversed,
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.
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.
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.
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.
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.
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
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.
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?
Is it possible to have it on FE7 or FE8?
Skill system is FE8 only, if that is what you’re asking.
I got something in what I think is chapter 6 of sacred stones. Here’s everything that happened. It was on hard mode. I had every unit thus far. It was Ephram’s chapter with just him and three others. There was a unit that looked like a tile to step on, and when I went over it the game went nuts for a bit then stopped. And every time an enemy unit made a move it would do the same thing. I was playing the vanilla hack that was just a NUPS thing. Anyone got any causes or fixes for this?
I presume you were playing the link in the first post of just fe8 with skills.
Unfortunately that probably doesn’t give us enough to go on for bug fixing.
I would recommend opening up the game in FEBuilder, creating savestates right before it happens, and explaining the issue as best you can eg. “when I hover over the unit at coords 4x,7y, the game crashes” in a report.7z. See the first post below on creating a bug report file.
Alternatively if you can attach your savestates along with the ups file you used in that thread, that would also work.
Is there a way to disable those letters from showing when a skill is activated? I want just the effect back
Random bit of trivia: The defiant skills in this work differently from how they would in Heroes, as they require the user to have 25% or lower remaining HP. Interestingly, because of this, it seems that Defiant Crit works exactly the same way Scarlet’s personal skill, In Extremis, works in Fates. It even grants the same amount of critical points.
I solved it, good ol brute force, attacked it once before the game could crash and it just disappeared!