[FE8] Skill System v1.0 - 404 skills done, more on the way

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
Xjd1lONZDw
NhdFiQl0Hf
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.
SkillsTest_01 SkillsTest_02

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.

1 Like

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.

image
image

4 Likes

I solved it, good ol brute force, attacked it once before the game could crash and it just disappeared!