#Skill Evolution

1955 messages · Page 2 of 2 (latest)

mild lantern
#

when I check HP levels via console, sometimes I get decimals

boreal apex
#

yeah

#

it's a pain as soon as you create an UI showing such values, because you have to round it the proper way, which changes depending on which stat or modifier you show

mild lantern
boreal apex
#

yeah

ornate belfry
#

I might just be dumb or maybe I need to lower my GUI scaling from 1.5, but is there some way to stop larger skill scaling sections from running off my monitor when it's a big skill lower in the list?

#

Some of these windows are yuge and it'd be cool if I could pin them to my screen.

#

Very bigly indeed lmao

image.png
vale owl
boreal apex
#

Regarding the width, I could add a setting to remove the feat details

ornate belfry
#

Yeah. Scrolling it would probably be a dire feat of GUI engineering. Only thing that comes to mind is having it spawn at a fixed location in the opposite upper corner.

boreal apex
#

Skill Evolution 1.8.1 released!

  • Fixed an error that occurred when manually triggering a mercantile skill uses outside of a merchant dialogue
  • Slightly increased default gains for armor skills, armorer, and mercantile (requires a reset of the Skill Uses Gains setting section)
  • New and more generous formula for weapon skill scaling
  • Fixed Skill Uses Gains setting title and description
  • Improved the settings doc
boreal apex
#

Skill Evolution 1.9 released!

  • Fixed time bugs when passing time for specific skill uses (thx to @heady rock's approach in Time Flies mod)
  • Minimum skill training duration is now 2 hours (vanilla) instead of 0, because rewinding time may cause bugs (we need a new training UI to allow shorter times)
  • When the player tries to train a skill capped by a major or minor skill, he will now lose the 2 hours (no more rewind)
#

Hotfix 1.9.1

  • Fixed the code that updates the settings to v1.9 for the training duration (please fix this setting if you ran v1.9)
#

Sorry 😅

sly rain
#

Hello mym, a lot of people are reporting incompatibility with Skill Evolution which breaks Oblivion Style Spellcasting. Is the mistake on my end or you need to add some code to make them work together properly?


[20:32:49.340 I] L@0x1[scripts/ossc/ossc_player.lua]:    OSSC: Casting burden (Chance: 100 Roll: 58)
[20:32:49.341 E] L@0x1[scripts/ossc/ossc_player.lua] onUpdate failed. Lua error: [string "scripts/skill-evolution/config/settings.lua"]:302: attempt to index a nil value
[20:32:49.341 E] stack traceback:
[20:32:49.341 E]     [string "scripts/skill-evolution/config/settings.lua"]:302: in function 'getSkillUsesKey'
[20:32:49.341 E]     [string "scripts/skill-evolution/config/settings.lua"]:367: in function 'getSkillUseGain'
[20:32:49.341 E]     [string "scripts/skill-evolution/skills/handlers.lua"]:182: in function <[string "scripts/skill-evolution/skills/handlers.lua"]:180>
[20:32:49.341 E]     [string "openmw_aux/util.lua"]:122: in function 'callEventHandlers'
[20:32:49.341 E]     [string "scripts/omw/skillhandlers.lua"]:73: in function 'skillUsed'
[20:32:49.341 E]     [string "scripts/ossc/ossc_player.lua"]:271: in function <[string "scripts/ossc/ossc_player.lua"]:135>
[20:32:49.341 E]     [C]: in ?
boreal apex
#

BTW do your new spells should be scaled by SE?

#

I'd need a cast chance and spell cost

sly rain
mild lantern
sly rain
boreal apex
#

I think I should just not try to override such gains when the use type is not vanilla

boreal apex
sly rain
sly rain
#

For OSSC I don’t have repo created yet, will do in a few hrs

boreal apex
sly rain
boreal apex
sly rain
boreal apex
#

@sly rain you don't provide a useType for your new spells:

Would it be possible to have one, with a mapping to use type keys, so SE could track feat stats on these new skills?

sly rain
# 
I.SkillProgression.skillUsed('enchant', { 
                                    skillGain = xpGain,
                                    useType   = 'EnchantUse'
}
#

like this you want?

# 
I.SkillProgression.skillUsed(mgef.school, { 
                                        skillGain = xpGain,
                                        useType   = 'SpellCast'
                                    }
#

If yes I can implement it in a moment

boreal apex
#

useType are numbers

#

for spell cast success it's 0

#

I.SkillProgression.SKILL_USE_TYPES.Spellcast_Success

#

adding useType = 0 (or the full reference) may fix SE's compatibility issue

#

I'm still adding fail-safe checks to prevent such errors

#

in the doc, they say you have to provide either a skillGain or a useType, so your code is valid, but adding the useType will increase your mod's compatibility

sly rain
#

Sure, adding that right now, thanks

boreal apex
#

For using an enchant, you can use:
I.SkillProgression.SKILL_USE_TYPES.Enchant_UseMagicItem

sly rain
# 
-- [SKILL PROGRESS] Reward XP for successful cast
                            local xpGain = storage.playerSection('SettingsOSSC_General'):get('SkillExperience')
                            if isItem then
                                -- Enchanted items grant Enchanting experience
                                I.SkillProgression.skillUsed('enchant', { 
                                    skillGain = xpGain,
                                    useType   = 1 -- EnchantUse
                                })
                            elseif spell.effects and spell.effects[1] then
                                -- Normal spells grant School-specific experience
                                local mgef = core.magic.effects.records[spell.effects[1].id]
                                if mgef and mgef.school then
                                    I.SkillProgression.skillUsed(mgef.school, { 
                                        skillGain = xpGain,
                                        useType   = 0 -- SpellCast
                                    })
                                end
                            end
                        else
                             ui.showMessage("Your spell failed to cast.")
                             core.sound.playSound3d("spell failure illusion", self)
                        end
#

this can be working or?

#

or it has to be explicitly I.SkillProgression.SKILL_USE_TYPES.Enchant_UseMagicItem and I.SkillProgression.SKILL_USE_TYPES.Spellcast_Success

boreal apex
#

you can use numbers

#

I prefer full references, as they are more explicit when reading the code

ember cloud
#

@boreal apex sorry for the ping.

Have a weird issue, which unfortunately is not the same one skrow was having.

in my #1482416741077356692 . I trigger block and weapon skill gain on parry.

function ParryController.parrySkillGain(self, skillGain)
    I.SkillProgression.skillUsed(self.activeParryConfig.secondarySkillId, {
        skillGain = skillGain,
        useType = I.SkillProgression.SKILL_USE_TYPES.Block_Success,
    })
    I.SkillProgression.skillUsed(self.activeParryConfig.mainSkillId, {
        skillGain = skillGain,
        useType = I.SkillProgression.SKILL_USE_TYPES.Weapon_SuccessfulHit,

    })
end```


skillGain is declared in advance as "10".

Problem being that with skill evolution installed the skill gain doesn't trigger consistently.  Tested with SE disabled and it works properly

What's weirder is that it only triggers in perfect parry path. The only difference between the two being that I add +5 to skillGain in perfect parry path.

A bit stumped. Any idea what it might be?
#

[22:57:36.886 I] L@0x1[scripts/ngarde/player.lua]: [NGarde]:[STATUS]:skillGain:10
[22:57:36.886 I] L@0x1[scripts/skill-evolution/player.lua]: DEBUG: Scale handler: Skill "block", scale nil -> 1.00000, gain 10.000 / 1.000 -> 10.000
[22:57:36.886 I] L@0x1[scripts/skill-evolution/player.lua]: DEBUG: Scale handler: Skill "longblade", scale nil -> 1.00000, gain 10.000 / 1.000 -> 10.000
the only thing I see in logs, but the actual skill progression values don't change

#

And with the latest update it doesn't work on perfect parry either O_o

#

[23:09:38.780 I] L@0x1[scripts/ngarde/player.lua]: [NGarde]:[STATUS]:skillGain:15
[23:09:38.780 I] L@0x1[scripts/skill-evolution/player.lua]: DEBUG: Scale handler: Skill "block", scale nil -> 1.00000, gain 15.000 / 1.000 -> 15.000
[23:09:38.780 I] L@0x1[scripts/skill-evolution/player.lua]: DEBUG: Scale handler: Skill "longblade", scale nil -> 1.00000, gain 15.000 / 1.000 -> 15.000

#

the values are way out of pocket, and are only really that big cause I was testing to see what kind of order of magnitude the skillUsed expects

sly rain
#

For me the whole namings never work, but integers always do the trick

ember cloud
#

tried that

#

the enum values are 0 and 0 anyway

#

but I guess, let me try again

sly rain
#

scale nil -> 1.00000

looks like the scale is not reading correctly and fallbacks to 1.00 value

ember cloud
#

nah, no dice

#

I'm not giving it the scale

#

very much on purpose

sly rain
#

Oh okay then

ember cloud
#

docs say it's either skillGain or scale

#

And may contain the following optional parameter:
scale - A numeric value used to scale the skill gain. Ignored if the skillGain parameter is set.

#

so, way I read it - I don't need to set it

#

and it'll get ignored cause skillGain value is set anyway

#

welp, and the same result with scale set, but no skillGain

#

And that also works with SE disabled

sly rain
#

We need mym help here 😄

ember cloud
#

I mean, I'm looking through SE code already. What trips me up is that originally (before i started screwing with it and updated to latest SE) - it worked with skillGain == 3, but not with 2. Which was the only difference between perfect and weak parry paths

#

I'm baffled

sly rain
ember cloud
#

no idea tbh

#

not terribly likely though, since it works reliably with SE disabled

sly rain
#

Hopefully you'll get it sorted

#

Since lots of people are using SE apparently

ember cloud
#

I do as well :D

#

That's just the thing. Not even sure how I didn't notice till today

boreal apex
# ember cloud > [22:57:36.886 I] L@0x1[scripts/ngarde/player.lua]: [NGarde]:[STATUS]:skillG...

Hey,
Indeed this is weird, because SE's logs stop at the scale handler.
As you set a custom gain, you should see the skill uses handler log:
log(string.format("Skill used handler: Custom base gain for skill \"%s\" is %.2f (instead of input %.2f and vanilla %.2f)", skillId, gainCustom, params.skillGain, useTypeCfg.vanilla))
then the skill-level-based handler log:
log(string.format("Gain factor handler: Skill \"%s\" level %d, range [%s, %s], scale %.5f x scale %.5f -> %.5f", skillId, level, range[1], range[2], scale, factor, params.scale))
then the final handler log:
log(string.format("Final handler: Skill \"%s\", gain %.5f x scale %.5f -> %.5f", skillId, params.skillGain, params.scale, params.skillGain * params.scale))

#

the handler chain should only stop on Lua errors or when one of them returns false, which my handlers don't

#

to know when it stops, maybe you can add logs at the beginning of each of the following handler, just after:

  • local function skillUsedHandlerCapper(_, skillId, params)
  • local function skillUsedHandlerUses(_, skillId, params)
  • local function skillUsedHandlerExternal(_, skillId, params)
  • local function skillUsedHandlerMagic(_, skillId, params)
  • local function skillUsedHandlerLevelBasedGainScaling(_, skillId, params)
  • local function skillUsedHandlerFinal(state, skillId, params)
boreal apex
ember cloud
#

Weirder than that even, it seems.

I've added a print statement at the beginning of each of those handlers "handlerName-enter:skillId" - for this we want longblade and block cause it was triggered off parry with a rapier.

I see that all handlers were entered, but only minimal messages related to the skill itself

📎 message.txt
#

It seems like longblade gets a bit further - it shows the "custom base gain" and "weapon speed" messages. But nothing beyond that, and nothing of the format you've specified above

#

you can see, at the same time I got unarmored gain, cause it was a weak parry and I took some damage, and that seems to have gone through properly, but that's not something I trigger

#

I may have something. I've printed off the params as well, and for block - skillGain switches from 2( base value that I set on invoke) to 0 at some point. Let me read through the logs carefully

ember cloud
#

So, this is weird. And I can't really find where and why it would set use to zero:
I've put in some debug logs, but no dice so far

# 
[10:10:46.485 I] .../player.lua]:    skillUsedHandlerCapper-enter:block
[10:10:46.485 I] .../player.lua]:    skillGain:3
[10:10:46.486 I] .../player.lua]:    scale:1
[10:10:46.486 I] .../player.lua]:    useType:0
[10:10:46.486 I] .../player.lua]:    skillUsedHandlerUses-enter:block
[10:10:46.486 I] .../player.lua]:    skillGain:3
[10:10:46.486 I] .../player.lua]:    scale:1
[10:10:46.486 I] .../player.lua]:    useType:0
[10:10:46.486 I] .../player.lua]:    useTypeCfg.settingKey:skillUse-block-Success
[10:10:46.486 I] .../player.lua]:    useTypeCfg.vanilla:2.5
[10:10:46.486 I] .../player.lua]:    gainCustom:2.5
[10:10:46.486 I] .../player.lua]:    checking areFloatEqual:2.5 and 2.5:
[10:10:46.486 I] .../player.lua]:    2.5 and 2.5 are equal:true
[10:10:46.486 I] .../player.lua]:    checking areFloatEqual:3 and 0.123:
[10:10:46.486 I] .../player.lua]:    3 and 0.123 are equal:false
[10:10:46.486 I] .../player.lua]:    block is not a weapon
[10:10:46.486 I] .../player.lua]:    skillUsedHandlerMagic-enter:block
[10:10:46.486 I] .../player.lua]:    skillGain:0
[10:10:46.486 I] .../player.lua]:    scale:1
[10:10:46.486 I] .../player.lua]:    useType:0
[10:10:46.486 I] .../player.lua]:    skillUsedHandlerLevelBasedGainScaling-enter:block
[10:10:46.486 I] .../player.lua]:    skillGain:0
[10:10:46.486 I] .../player.lua]:    scale:1
[10:10:46.486 I] .../player.lua]:    useType:0
[10:10:46.486 I] .../player.lua]:    skillUsedHandlerExternal-enter:block
[10:10:46.486 I] .../player.lua]:    skillGain:0
[10:10:46.486 I] .../player.lua]:    scale:1
[10:10:46.486 I] .../player.lua]:    useType:0
[10:10:46.486 I] .../player.lua]:    skillUsedHandlerFinal-enter:block
[10:10:46.486 I] .../player.lua]:    skillGain:0
[10:10:46.486 I] .../player.lua]:    scale:1
[10:10:46.486 I] .../player.lua]:    useType:0```
for block^
@boreal apex , when you have time, any ideas?
boreal apex
#

did you set the skill-level-based scaling setting to "100 to 100"?
Otherwise the skillUsedHandlerLevelBasedGainScaling function should log something, except if the skillGain is already 0 at this point

ember cloud
#

Skill Level based Scaling is 125-25. Iirc that is the default

#

let me check for external handlers

#

no, it looks like for _, handler in ipairs(externalSkillUsedHandlers) do loop is never entered

ember cloud
ember cloud
#

Oh

#

Yeah, I've found it

#

@boreal apex in scripts/skill-evolution/skills/scaling.lua in skillUsedHandler you set skillGain to 0 for block, armor and weapon skills:

    elseif mCore.weaponSkills[skillId] then
        if not mS.isSkillScalingEnabled("weaponSkillScaling") then return end
        state.scaled.weapon = {
            handlerParams = { skillGain = params.skillGain, scale = params.scale, useType = params.useType },
            skillId = skillId,
        }
        -- will be handled on hit
        params.skillGain = 0
        return
    elseif mCore.armorSkills[skillId] then
        if not mS.isSkillScalingEnabled("armorSkillScaling") then return end
        state.scaled.armor = {
            handlerParams = { skillGain = params.skillGain, scale = params.scale, useType = params.useType },
            skillId = skillId,
        }
        -- will be handle on hit
        params.skillGain = 0
        return
    elseif skillId == Skills.block.id then
        if not mS.isSkillScalingEnabled("blockSkillScaling") then return end
        state.scaled.block = {
            handlerParams = { skillGain = params.skillGain, scale = params.scale, useType = params.useType },
            time = core.getSimulationTime(),
            attacker = nil,
        }
        -- will be handle on hit
        params.skillGain = 0
        return

Problem is - I'm sending this from onHit, so "will be handled on hit" never happens

#

I see this in your docs:

Mods that alter the player physical damage dealt by enemies should be loaded after Skill Evolution so their handler is loaded before Skill Evolution's, and this mod get the final damage value.

Another way is to use Skill Evolution's AddOnHitHandler interface to add such handlers and be sure they will be called at the right time.
Add your handler in a player script, from both the onInit and onLoad engine handlers, not from the global scope, to be sure Skill Evolution's interface is ready.

But NGarde is loaded way after Skill Evolution. I'll try and add an SE on hit handler though

boreal apex
ember cloud
#

Yeah, not sure it will still work right.

did

local onHitHandler = function (attack)
    attack = parryController:onHitHandler(attack)
end

local addOnHitHandler = nil
if I.SkillEvolution and I.SkillEvolution.AddOnHitHandler then
    I.SkillEvolution.AddOnHitHandler(onHitHandler)
else
    I.Combat.addOnHitHandler(onHitHandler)
end

in my player script - still no skill gain

#

trying to retest now

#

And, do I understand right that it "should" have worked right even before that, if my mod is loaded significantly later than yours?

#

That's one thing I'm not 100% clear on - the order in which handlers resolved as they are added

boreal apex
#

I.SkillEvolution.AddOnHitHandler is only useful if you alter the damage, it's not related to the skill gain

ember cloud
#

I do alter the damage, set it to 0, or reduce it

#

it's a parry mod after all

#

but I trigger block use on weapon parry

boreal apex
#

however I.SkillProgression.addSkillLevelUpHandler may be the solution, because handlers added this way will be called properly once the onHit happens, with the proper gain values

boreal apex
#

loading your mod after SE won't work for onHit handlers, because SE adds them when the player is active, not in onLoad, nor in the script body

#

except if you add your handler in onActive, and load your mod after SE

#

for the skill use handlers, there is no other way than using the SE function to add your handlers (when SE is detected), because of the delayed skill gain

#

for skill scaling, I could not find another way to handle compatibility

ember cloud
#

[12:37:33.999 I] L@0x1[scripts/ngarde/player.lua]: [NGarde]:[STATUS]:registering regular onHitHandler
It's not finding the interface ur.

#

weird

boreal apex
#

don't add your handlers from the script root

#

do it in onInit and onLoad

#

otherwise the compatibility will be load order dependent

ember cloud
ember cloud
boreal apex
ember cloud
#

yeah

boreal apex
#

I'll try manually

ember cloud
#

let me see if just properly registering SE onHit does it

boreal apex
#

hmmm I can reproduce the bug with a manual console trigger

#

let me check

ember cloud
#

L@0x1[scripts/ngarde/player.lua]: [NGarde]:[STATUS]:registering regular onHitHandler
this is from onLoad. Not sure why it doesn't see I.SkillEvolution

#

hmm

boreal apex
#

ok, now I understand the issue

#

for delayed scaled skill gains, SE expects to get a onHit event to process the gain, but it never happens

ember cloud
#

ok, nvm that

[12:46:39.553 I] L@0x1[scripts/ngarde/player.lua]: [NGarde]:[STATUS]:registering SE onHitHandler
just a typo in the readme, you had AddOnHitHandler instead of addOnHitHandler.

boreal apex
ember cloud
#

Right, so looks like with my onHit registered as SE onHit it works

#

let me test both damage paths

boreal apex
#

interface functions used to use a capitalized first letter with NCGDMW, I missed that update

ember cloud
#

ah ffs

#

back to square one

#

works on perfect parry (damage reduced to 0)

#

doesn't work on weak parry - damage reduced but not to 0

#

lmao

#

And doesn't work on longblade, but only on block O_o

#

wat

boreal apex
#

weak parry uses the onHit event?

#

and set attack.damage.health to 0?

boreal apex
ember cloud
boreal apex
#

scaling here depends on the actor you hit, but if nobody is hit, then nothing happens

ember cloud
#

weak multiplies damage by a factor, it can get to 0.

#

"perfect" sets to 0

boreal apex
#

oh I see, if health and fatigue are set to 0, SE thinks the player blocked the attack, but as no block info is provided, then nothing happens

#

I can fix it

ember cloud
#

but..

#

it's the opposite

#

I only gain skill on perfect parry

#

and only block.

I assume longblade gain doesn't trigger because actor didn't hit anyone, but instead used weapon to defend

#

(iirc I set it to public, let me know if it's not)

#

lines 981 down

boreal apex
ember cloud
#

dammit

#

So top level - this is part of the onHit handler, if parry is "perfect" I set attack.damage.health and fatigue to 0. If not I set health to health * defenceMultiplier (0-1) and assign the rest to attack.damage.fatigue.

in perfect parry path I do skillGain+=1. in normal it remains unchanged from what is declared earlier

#

I don't know what other parts of attackInfo you may be relying on though

#

Right, so looking at debug logs.
It seems you prevent block skill gain if damage is not 0, which is expected vanilla behaviour.

And you prevent weapon skill gain if damage is 0 (or nil). Which again, sorta makes sense, but I don't think engine does that in either case

So how do I fake these values so that SE recognizes skill gains on parry, while still maintaining the mechainc. I wonder🤔

boreal apex
#

yeah good question

ember cloud
#

Also not sure - do you even need those checks?

#

Or were they added to fix something? Cause with SE disabled - it doesn't seem like OpenMW itself guards against these cases

boreal apex
#

I use the onHit handler on the player to handle both the armor and block skills. I rely on the damage to know whether it's a block or not.

#

But I could rely on the block skill use trigger only I suppose

#

the damage and fatigue checks may be optional

ember cloud
#

Right, cause on my end, at least for block, the only way I see is to set attack.damage.health = 0 always, and jut edit health/fatigue directly. But that'll break so much other stuff

#

for weapon I assume it's the same assumption but reversed - no damage, hence attack missed, hence no skill gain

boreal apex
#

I think your approach makes sense and SE has to be more permissive

ember cloud
#

Also, I'll need to test, but base game iirc - weapon skill gain still applies if player attack was blocked, doesn't it?

ember cloud
boreal apex
boreal apex
ember cloud
#

I'm happy to answer any questions. But let me actually set that repo so it's visible

boreal apex
#

maybe can you summarize me the steps you do for action?

ember cloud
#

Right,

So on hit for player.

  • We enter onHit handler,
  • if player has something useable to defend with -and is in parry stance -> enter parry handler
  • declare skillGain = 2
  • check if perfectParry timer is active
    • if true: set attack.damage.health and attack.damage.fatigue to 0
    • if false: reduce attack.damage.health by skill defined ratio, set. attack.damage.fatigue to what remains of attack.damage.health
  • trigger block and weapon skill gain ( or block twice if it was a shield)
#

no return false or anything at any point, just return the modified attack back to top level handler itself

boreal apex
#

thx!

#

I'll check that ASAP

ember cloud
#

And I've fixed permissions on the repo

#

so that link from before should work

boreal apex
ember cloud
#

I mean. You can add an event we can send to SE?

boreal apex
#

the params argument doesn't tell about the trigger source

#

I'm trying to support mods without explicit compatibility code

ember cloud
#

yeah, that's fair

#

but right now - any mod that will trigger that "use" manually - will just not work

#

well the skill gain won't

boreal apex
#

one way would be to add a field like "manual = true" to the params argument when you trigger the skill used, which would tell SE to skip the scaling part

boreal apex
ember cloud
#

yeah, since it's jsut a table

#

I can do that

boreal apex
#

yeah but I would prefer a way that works with any mod

ember cloud
#

I mean - registering onHits through SE interface is already kind of "explicit compatibility"

#

definitely doesn't feel implicit

boreal apex
#

maybe I could add a delay: After like 0.5 seconds, if there is no onHit trigger, then I just continue with the handler chain

boreal apex
ember cloud
#

I dunno actually. In my current version, with latest SE from nexus - the skill gain of perfect parry for block didn't trigger until I did that

#

Which it worked on previous version I had installed - so not 100% clear what changed between the two, or if it was my screw up.

But it was

  1. Only perfect parry gives skill
  2. Update SE - nothing does
  3. Add onHits - same behaviour as 1
#

"nothing" in the context of my parries, ofc

boreal apex
ember cloud
#

I saw the conversation with Skrow yeah. But I was providing useType right away.

boreal apex
#

weird

#

maybe I'll need your code to test it locally

#

or maybe a manual trigger from the console will be enough?

ember cloud
mint rapidsBOT
#
.arrean

Actually - also re-enabled more animations that prevent parry

Attachment(s)

NGarde.1.0.0-RC1.zip

Linked by @​.arrean from #N'Garde. Vanilla-Friendly Parry and Active Block. Beta ·
ember cloud
#

gitlab is a bit ahead of that version, too, the zip doesn't have the special addOnHitHandlers yet

#

I also don't currently have debug log switch in settings too, but you can find instances of "setLogLevel" and change OFF in them to DEBUG

boreal apex
boreal apex
#

also, when the player doesn't block the hit, and the parry is active, you reduce (or cancel) the damage, which will reduce (or cancel) the armor skill gain because of SE's scaling being based on incoming damage, but I suppose it's coherent as the player did the parry

#

another thing: When the player blocks the attack but also does a non-perfect parry, will he have health and/or fatigue damage?

mild lantern
#

that I can answer

#

because I've been playtesting the mod

#

partial dmg

boreal apex
# mild lantern partial dmg

as there is no armor skill gain when the player blocks an attack, then SE currently won't convert such a damage into armor skill gain

#

maybe it's the parry mod's responsibility to add such a gain

mild lantern
#

for coherence, there should be some gain for something in case of a weak parry, that's for sure

boreal apex
#

when the player blocks, parry already provides 2 gains for the block skill, even with a weak parry

#

but no gain for armor

mild lantern
#

I definitely noticed the Block bug

#

with the non-gitlab version

#

my Block skill is not advancing with SE

boreal apex
#

bugs are another matter 🙂

#

here I'm thinking on the expected behavior

mild lantern
#

well, that's for @ember cloud to decide. I guess that with Vanilla unscaled levelling, it could be too much to get armor gain (for randomly chosen equipment slot) and weapon skill/block skill gain at the same time in case of a weak parry. With SE it would be less of a problem because you would get less gain because of scaling (lower damage).

ember cloud
boreal apex
ember cloud
#

So, far as I can tell armor gain still happens on a "weak" parry, at least with SE installed

#

looking at debug logs - I see "unarmored" handers entered and applied correctly

ember cloud
ember cloud
boreal apex
ember cloud
#

But it didn't

#

cause block chance is 0

#

both min and max block chance

boreal apex
#

ah!

#

ok, perfect then

ember cloud
#

Since I've added ability to "active block" to NPCs, - I've just disabled native block all together in an omwaddon

boreal apex
#

perfect

boreal apex
ember cloud
#

Perfect. Both weak and perfect parry properly apply skill gain to both main and secondary skills

#

And you can see, medium armor, block, longblade and unarmored all triggered on a weak parry

📎 message.txt
#

Thank you so much!

boreal apex
#

wonderful

#

thx to you for your time and logs

mild lantern
boreal apex
#

SE is improving thx to such feedback

ember cloud
#

And the rest of us and our mods are better off for it

mild lantern
#

I may soon add Ngarde to my main save, then. Hard to go back to Vanilla!

ember cloud
#

^ that's what I want to hear doitswit

boreal apex
#

Note that the skill-level-based and weapon speed scalings are still applied when you manually trigger skill uses

mild lantern
#

But that's expected as it determines global pacing

ember cloud
#

So I'm fine with it just doing its thing

mild lantern
#

I'm not even sure whether weapon speed matters in modern SE or whether it's just hit chance

#

There were revisions along the way...

boreal apex
ember cloud
#

DEBUG: Skill uses handler: "longblade", weapon speed 1.55, scale 1.00000 x factor 0.80322 -> 0.80322
Does seem to do try and do something, not sure if it actually gets applied that 0.80322 -> 0.80322 is a bit odd for that log line

boreal apex
#

The handlers update the scale parameter, the last handler applies that scale on the gain.
Here your weapon is pretty fast, which reduces the scale

ember cloud
#

Got it

mild lantern
#

I'm definitely getting Block exp after the latest update. One thing I noticed, though, is that they blocks often aren't registered as feats when using Stat Window Extender.

ember cloud
#

Hmmm. That may be on my end - but I don't know what they need to be to get registered

mild lantern
#

they are getting registered sometimes

#

I'm wondering whether it's just perfect parries

#

as there is 0 dmg then

#

and maybe the game registers that as vanilla-like block

#

but I'm spitballing here

#

if that's the case, then it can be considered a feature 36vehks

ember cloud
#

SE though, not the game

boreal apex
ember cloud
#

Makes sense

boreal apex
#

It could be possible if n'guarde would use a scale instead of an absolute gain value, and if it would inform SE to interpret that scale as a skill scaling (extra arbitrary param)

#

BTW I think a scale has advantages over an absolute gain, because it adapts to any custom base gain

ember cloud
#

But you don't listen to that param at the moment, right?

#

Yeah, I could/should change it to scale

boreal apex
#

There is no such param currently

ember cloud
#

roger that

boreal apex
#

I do use the incoming scale, because vanilla set it

#

But I don't interpret it as a skill scaling, in the sense of SE

#

It's confusing because there is a vanilla scaling (scale field), then SE has multiple scaling features

ember cloud
#

right

#

Well, for now, at least, I'm pretty happy the two just work alongside without either breaking

#

so anything more - is really not necessary

boreal apex
#

Yeah

#

Would you consider using the scale field instead of skillGain?

ember cloud
#

yeah

#

I'm not clear though on what to set it to

#

naive answer seems to be 1 for weak and e.g. 1.5 for perfect parry

#

but I have no context of what it means

boreal apex
#

A good parry could use a scale of 2 (twice the gain), while a weak parry could be proportional to the timing, between 1 and 2

ember cloud
#

or proportional to the parry defence factor... hmmm

#

that would give me an easy 2 - factor to go between 1 and 2

#

I'll think about it

#

will definitely change to it, but will ponder the values

boreal apex
ember cloud
mild lantern
# ember cloud Well, for now, at least, I'm pretty happy the two just work alongside without ei...

Indeed. However, I treat it all as elements of a larger whole. Ideally, everything works cleanly with each other. In fact, since I expect that it's impossible to combine changes to skill descriptions made in more than 1 mod without a patch, I'm already considering a mini submod for NCG and N'Garde which will keep all the info from NCG's changed descriptions (skill X contributes to growth of STR, END, AGI etc.) and also include all the relevant changes related to N'Garde, e.g. proper info about Block affecting both ranged and melee attacks and not always protecting from all damage todd

ember cloud
mild lantern
boreal apex
ember cloud
mild lantern
#

parrying is always active

#

no passive blocks

ember cloud
#

Yeah, but I think Mym means that scaling skill gain with skill level is silly

#

so timing is better

#

(which just means that my local timers class was a worthwhile time investment)

boreal apex
#

The damage reduction could also be partially based on the timing

#

Now I realize I already use the vanilla scale field with mercantile to make it a feat (SE does no scaling for this skill). It would then be easy to generalize the approach

ember cloud
mild lantern
#

yeah

ember cloud
#

Not sure I want to mess with that formula more though

ember cloud
boreal apex
boreal apex
#

Like { scale = 1.5, stats = { timing= 0.75, skill= 43 }}

boreal apex
#

With readable stat keys as they will be displayed in skill tooltips

boreal apex
#

You can even have spaces in keys: ["Defence Factor"] = 0.75

ember cloud
#

Hmmmm. In an inverse (1-x) of defence factor probably? Or just total "damage negated"? The latter would make more sense and would cover both perfect parry and "weak" parry. Can't really think of anything else that is easily described with a number that would make sense

#

For the feats - what kind of number do you expect? Based on what you've posted above it seems like it would be between 1 and 0

mild lantern
ember cloud
#

aha

#

can do that

mild lantern
#

Yeah

#

Raw meaning before AR

ember cloud
#

yeah, not sure if damage as it shows up in onHit is before or after AR... Hmmm

#

I do not apply AR, but I also don't interrupt the handler chain, so it can be applied above or below

#

Mym, lemme know if this works:

skillUsed(self.activeParryConfig.mainSkillId, {
            scale = scale,
            useType = SKILL_USE_TYPES.Weapon_SuccessfulHit,
            stats = { 
                damage_negated = damageNegated, -- raw damage number
                skill = self.currentStats[self.activeParryConfig.mainSkillId].value, -- current skill level
                timing = timing -- value between 1 and 0, depending on how close to perfect the parry was. 1 is best
            }

        })```
boreal apex
ember cloud
#

Ah

#

How about

stats = {
    damage_negated = { value = damageNegated, interpretation = "raw" },       -- raw damage number
    skill = self.currentStats[self.activeParryConfig.secondarySkillId].value, -- current skill level
    timing = { value = timing * 100, interpretation = "percent" }             -- value between 1 and 0, depending on how close to perfect the parry was. 1 is best
}

Or annoying on your end?

boreal apex
# ember cloud Mym, lemme know if this works: ```lua skillUsed(self.activeParryConfig.mainSkill...

I would use readable keys instead, and we may need a unit info:

skillUsed(self.activeParryConfig.mainSkillId, {
            scale = scale,
            useType = SKILL_USE_TYPES.Weapon_SuccessfulHit,
            stats = { 
                ["Damage Negated"] = { value = damageNegated, unit = "HP" }, -- raw damage number
                Skill = [ value = self.currentStats[self.activeParryConfig.mainSkillId].value }, -- current skill level
                Timing = { value = timing, unit = "%" } -- value between 100 and 0, depending on how close to perfect the parry was. 100 is best
            }
        })```
ember cloud
#

right, so unit instead of a vague "interpret this as" string. Yeah, can do that

boreal apex
#

or, you're right

#

the value could be a string

#

including the unit

#

simpler

ember cloud
#

oh, even better

#

but you'd need to parse it then, won't you?

#

to compare feat a to feat b

boreal apex
#

I compare using the scale

ember cloud
#

ah

boreal apex
#

not the stat info

ember cloud
#

then I should adjust the scale based on all the info

#

otherwise feat won't make sense

boreal apex
#

ah yes, that's the scale purpose

#

the scale will define the gain, and thus the feat

ember cloud
#

Right. So I'll then modify scale by both timing and percent of damage negated, and provide raw values with units in stats

#

Actually, maybe even raw negated damage /100 or something. So that a 100HP attack parried is worth more than a 3hp attack

#

And done. Love me some interop and compatibility

ember cloud
#

Mym, a question. I've been looking at the way NCG/SE does tooltip integration with Stats Window Extender - thinking of updating the skill description to block like Cybvep suggest.

Am I reading it right that it's not really possible without overriding the tooltip builder? Or am I missing something?

boreal apex
#

I did override the builder, but I don't know whether there is another way

#

we would need another way to not override our changes on the same tooltip

ember cloud
#

Yeah, I was looking at what's going on in StatsExtender API and don't see a way to just poke the description either

#

Well, it was just a "nice to have " anyway

boreal apex
#

Ralt's would certainly improve on that, IF he was available

ember cloud
#

He is somewhere - he did post that projection spell video to youtube a few days back. Not here though 36vehks

boreal apex
#

yeah I saw that impressive spell

#

what may be missing is a way to define a unique ID for the feat. I use such IDs to filter feats based on specific contexts, like when fighting with the same enemy, I don't want many feats weapon feats from this enemy, I only keep the best one

#

because with a very strong enemy, you may get all your long blade feats talking about him

#

I use:

  • spell ID for magic scaling
  • enemy record ID for weapons, armors and block
  • merchant record ID for mercantile
  • container record ID for security and locks
  • container record ID and spell ID for security and traps
  • ingredient record ID list for alchemy
#

in your case, there is an enemy, which record id could be used for that

#

maybe a convention could be to add an "id" field to the stats map, which I could use

#

also, you could add the enemy name as a stat

ember cloud
#

That would make sense yeah, since I'm parrying someone. Let me try this

boreal apex
#

hmmm, we may have an order issue: Curently the stats are a map (unordered) so the order will be random

ember cloud
#

Well, got something.

image.png
#

Bumped the enemie's strength so that it'c clearly visible what the attack was

#

Doesn't register on weak parry though, I don't think. Hmmm

boreal apex
ember cloud
#

I believe so

#

the entire tooltip

image.png
boreal apex
#

I tested locally with things like:
I.SkillProgression.skillUsed("lightarmor", {scale=3.5, useType=0, stats={Factor="350%", Heatlh="30"}})

boreal apex
ember cloud
#

that works

image.png
#

hmm, let me see if I send it correctly

#

Ah, that was my bad

#

however - you just expect a string, I see

#

let me change it on my end

#

Beautiful

image.png
#

I may need to tune down the gain values a bit though

#

However, for that much damage it may be fair

#

but 200 for a 1hp perfect parry - not sold

boreal apex
#

and maybe a round on the values 😄

#

is the stats order constant for you?

#

it may change each time you open the tooltip

ember cloud
#

yeah, same order I've added them to the table I send

#

Doesn't change fror me at all, even if I close/reopen the menu

#

Doesn't chage on reload either

boreal apex
#

weird, map traversal is enigmatic

#

is it in the order you wrote it?

ember cloud
#

If it does change, I'll let you know. But so far yeah - same order I wrote it in. damage, skill, timing

boreal apex
#

I think it would be best to use a list instead of a map

#

this would ensure the order

ember cloud
#

Aren't they both tables in lua?

boreal apex
#

like:

{
  { name = "Damage Negated", value = "83 HP" },
  { name = "Skill", value = "53" },
}
#

lists can be enumerated in their original order

#

for maps, there is no guarantee

#

I had this issue many times in my mods

#

both answer "table" with type(myList)

#

but internally they are different

#

and they can be boths, like spell records in core.magic 🙂

ember cloud
#

Interesting - never ran into that

#

reading the lua docs told me that a table is a table is a table, except when it's a userdata

boreal apex
#

try to use pair or ipair for loops on the wrong table and you'll see

#

pair -> maps
ipair -> lists

ember cloud
#

ah

#

right, yeah. Got it. Can't do ipairs on an key:value table, can do pairs on both, but pairs doesn't guarantee the order

#

well, at least so far - order has been preserved, as I send it

#

One thing. Do I need to pass the skill level for you to do anything with?

Cause it doesn't make much sense the way it is displayed now. "Feats all time" display skill level anyway, and "recent" and "current level" probably don't need it

boreal apex
#

yeah, no need

#

I only display it in "all time" because it makes sense there

ember cloud
boreal apex
mild lantern
mint rapidsBOT
#
.arrean

And we have integration with Skill Evolution's Feat system. Pending official SE Update:

Attachment(s)

image.png

Linked by @​cybvep from #N'Garde. Vanilla-Friendly Parry and Active Block. Beta ·
ember cloud
boreal apex
boreal apex
#

but if you agree on this new contract I can implement it

mild lantern
ember cloud
mild lantern
#

There will be more LUA mods which do things with skills. This is good testing ground 😄

ember cloud
#

I wasn't even aware there's a cap, we wouldn't even seen it if I didn't send it with 1000 strengh guard

mild lantern
ember cloud
#

very much why

#

also was testing roundTo helper function that is conspicuosly absent from both base lua and opnemw.util

#

Now, imma get back to the bloody raycasting

boreal apex
#

doc details:

Mods that manually trigger a skill used can provide stats to record the gain as a feat (visible in skill tooltips).

To make it work, the options argument needs:

  • A scale value (vanilla param) that will define the feat percent
  • A stats list, with items matching { name = string, value = string }
  • Optionally, if a statsId is provided, then only one feat per ID value will be recorded

Example:

I.SkillProgression.skillUsed("spear", {
  useType = 0,
  scale = 1.5,
  stats = {
    { name = "Damage Negated", value = "83 HP" },
    { name = "Timing", value = "100%" },
  },
  statsId = "arrille"
})
#

@mild lantern also, the gain caps are applied

mild lantern
#

thank you

#

now we can get maximum coherence

ember cloud
#

Excellent, thank you. Give me a few to modify my code and test

#

Also, was meaning to ask? Why do you fomod-pack it?

#

(or at least do the 00-core thing, withot the actual fomod file)

boreal apex
#

I use a BAIN structure for all my mods

#

I never understood the fomod thing 😅

ember cloud
#

right, it's bain, blanked on that

boreal apex
#

I'll probably off my laptop for 10 days, please tell me if the last version works for you so I can publish it

ember cloud
#

Yeah, jsut a minute

#

Looks like works exactly as specified

boreal apex
#

do you use a statsId?

#

the enemy name is missing

#

but be careful with the total line lengths!

mild lantern
# ember cloud

I think that you don't have to type Parry two times. Once before Damage Negated and then with Parried With

ember cloud
#

Yeah, I didn't send a stats Id, or the enemy, and the stat names are placeholder

boreal apex
#

statsId is just to improve the feat diversity

ember cloud
#

So it doesn't show up the same thing 5 times yeah

mild lantern
#

probably better to display an enemy than the weapon/shield

ember cloud
#

will play around with it

mild lantern
#

I mean, it's not that we don't know what's happening there. It's not dancing

ember cloud
#

Yeah, and with vanilla block disabled - makes sense

#

but on weapon skills - want to be able to tell it apart from attacks

mild lantern
#

hm, maybe a separate tab

#

for parries

ember cloud
#

I'll figure it out, for now - the main thing is htat it works and w can let Mym publish and do his thing

#

^me avoiding making UI

mild lantern
#

POV: player with high Sanctuary vs a skeleton

ember cloud
boreal apex
#

Per skill too

#

I added the info just before publishing 😁

ember cloud
#

Excellent, thank you

#

hmmm

[17:24:13.188 E] Unrecognized argument type for key "Parry Damage Negated" when formatting message "featWeapon"
[17:24:13.188 E] Unrecognized argument type for key "Skill" when formatting message "featWeapon"
[17:24:13.189 E] Unrecognized argument type for key "Timing" when formatting message "featWeapon"
[17:24:13.189 E] Unrecognized argument type for key "Skill" when formatting message "featWeapon"
[17:56:48.419 E] Unrecognized argument type for key "Parry Damage Negated" when formatting message "featWeapon"
[17:56:48.419 E] Unrecognized argument type for key "Skill" when formatting message "featWeapon"
[17:56:48.419 E] Unrecognized argument type for key "Timing" when formatting message "featWeapon"
[17:56:48.419 E] Unrecognized argument type for key "Skill" when formatting message "featWeapon"

#

Should've looked at logs

#

doesn't break, but spams a bit

boreal apex
#

Ah, that must be the feats recorded with the previous beta version

ember cloud
#

ah, makes sense

ember cloud
boreal apex
ember cloud
#

Yeah, not for handlers though, I don't think. Just the load order should be enoguh for that.

#

But got it

#

Would be cool if we could set "dependencies" for omwscript files

boreal apex
#

Handlers can be added at different places, anf the location and load order both impact the application order

ember cloud
#

Right, am aware now :D

boreal apex
#

If the mods add the handlers at different parts, then the load order may not have the expected result

ember cloud
#

Yeah, which is why I've been told:

If we could police this - we would
by the devs

#

Cause adding handlers every which place will invariably be weird

boreal apex
#

Police how?

ember cloud
#

Mads meant "if we could enforce only registering handlers in script body - we would"

boreal apex
#

Ah

#

First I did that, but then I had issues with compatibility, or things not yet ready

ember cloud
#

Yeah, I think their idea is that should only ever be managed by load order

#

Which would make sense if there was an easier way to enforce dependencies and ordering for pure lua mods

#

and does make sense anyway, but can be tricky sometimes

boreal apex
ember cloud
#

I mean, I can probably imagine something like that

#

Probably

boreal apex
#

Our mods is the perfect example: we want your skill handlers to be executed after mines, but the on hit handlers executed before....

ember cloud
#

Well, but I don't have skill handlers

#

But I get what you mean

boreal apex
#

Ah, right 😅

ember cloud
#

As I said - I can imagine that happening, but then imo one of the mods should be split because it's doing something it shouldn't

#

Anyway, thanks again for all the help :P. I think I need a tea and a break from the screen

boreal apex
ember cloud
#

Recent versions are mostly stable, so feel free when you have time and inspiration. There are a couple things I need to work on still however

wooden halo
#

Question: everytime I start a new game I have to enable the settings in skill evolution to allow skill increases from books. Is there a way to change the data files to have this setting enabled automatically on my end?

wooden halo
#

Would I just turn the default from true to false?

boreal apex
wooden halo
#

ah, thank you for the insight!

#

That was my issue, thank you!

acoustic heath
#

Hey mym, I was wondering if you’d consider factoring the Base Modifier from abilities into the Skill Cap. So, I reduced the Skill Cap to 100 in the settings to replicate vanilla behaviour, and I made two separate characters. With the first character, I chose the Lover birthsign which, using Birthsigns RESPECted, fortifies Acrobatics 15pts and with the second, I chose the Shadow which shares the same fortify Agility 15pts as the Lover but has no fortify skill effect. I then proceeded to only raise the acrobatics skill of both characters to 100 and captured the resultant level and attributes of each:

#

As you can see, the first character has reduced level and attribute values compared to the second despite both achieving the Skill Cap of 100 for Acrobatics. Also, on https://en.uesp.net/wiki/Morrowind:Skills I saw that the formula for the required skill gain to raise a skill includes the current skill value. Do you know if the Base Modifier is factored into the Skill Requirement? If so, you have the double whammy of constant fortify skill effects not only hamstringing potential character growth, but also skill progress, making what should be a positive into a negative.

Morrowind:Skills

There are 27 skills in Morrowind, each of which determines how well you can perform various tasks. Each skill is governed by an attribute; there are three to five skills governed by each attribute (except Luck). Each class has five major skills, five minor skills, and seventeen miscellaneous skills. Each time your character increases any combina...

boreal apex
#

But, well, a cap is a cap

acoustic heath
# boreal apex Hey, I think it's easy to do. I don't recall why I excluded base modifiers from ...

Idk, considering that only skillups contribute to level and attribute progress, having a positive Base Modifier "eat up" some of those potential skillups without simultaneously raising the Skill Cap makes constant fortify skill effects seem like strictly a negative. It would be interesting if they had the side benefit of raising the maximum effective skill level, so in the aforementioned example the first character could achieve a mighty Acrobatics of 115 while the second would be bound to the measly 100.

acoustic heath
#

Also, say you raised Sneak, Athletics, Acrobatics, Hand-to-hand, Unarmored, Mysticism, Illusion, and Destruction to 100 as part of your class skills and then became a vampire mid-playthrough, with NCG/SE and the way Skill Caps work, wouldn't you massively hemorrhage attributes and player level?

boreal apex
boreal apex
#

Excluding base modifiers would ease skill progression in addition to the higher skill. Not sure it would be balanced

boreal apex
#

Skill Evolution 2.0 released!

  • Support custom skills added through the Skill Framework mod
  • Skill fortifications on base modifiers (abilities) are now excluded from cappers
  • Optimized the setting management for better performances, stability and maintainability
  • Multiple settings will be reset to their default value, check the setting page
  • Fixed 0 mercantile gain set by the engine when the player's offer is too close to the merchant's
  • Fixed best feats wrongly replaced by less good ones, for feats using unique ids (e.g. potions created with the same recipe)
  • Fixed wrong health ratio (doubled) in acrobatic fall feats
  • Can be installed or updated mid-game
acoustic heath
#

Hey mym, I noticed on the mod page and in the docs that you write "I.SkillEvolution.AddSkillUsedHandler" when it should be "I.SkillEvolution.addSkillUsedHandler", just wanted to let you know

boreal apex
earnest linden
# 
[23:55:03.492 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Level-based handler: skill "restoration" level 179, range [125, 25], scale 20.20000 x factor 0.09047 -> 1.82754
[23:55:03.492 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Final handler: skill "restoration", gain 0.75000 x scale 1.82754 -> 1.37065
[23:55:03.492 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Skill restoration gain 1.371 (requirement 135.000), progress 0.99393 -> 1.00408, excess 0.551
[23:55:03.525 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Skill "restoration" has changed from 122 to 123
[23:55:03.525 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Skill restoration gain 0.551 (requirement 135.750), progress 0.00000 -> 0.00406, excess 0.000```

not sure what's going on but it looks like new versions (2.0.1 and 2.0) aren't communicating skill ups to newest version of ncg, downgrading skill evolution to version 1.9.9 fixed the issue
sterile mason
# 
[00:02:51.126 E]     [C]: in ?
[00:02:51.142 E] L@0x1[scripts/skill-evolution/player.lua] onUpdate failed. Lua error: [string "scripts/skill-evolution/util/helpers.lua"]:166: attempt to index local 'vector' (a nil value)
[00:02:51.142 E] stack traceback:
[00:02:51.142 E]     [string "scripts/skill-evolution/util/helpers.lua"]:166: in function 'v3xy'
[00:02:51.142 E]     [string "scripts/skill-evolution/util/helpers.lua"]:170: in function 'groundDist'```
#

white line only appears when the errors are going

#

though could be my own error knowing how ive been fkn up my installs as of late 🚬

acoustic heath
#

Also mym, would you mind adding an interface function for setting the skill max value? Decay is probably the hardest feature to wrangle for compatibility.

earnest linden
boreal apex
boreal apex
boreal apex
earnest linden
#

or 9.6 skill levels negative

boreal apex
sterile mason
earnest linden
#

it's almost like it's an overflow, hang on ill send a video

boreal apex
boreal apex
earnest linden
boreal apex
earnest linden
#

actually now that you mentioned that, it's probably character traits framework- hang on

boreal apex
#

I see multiple other skills going down at the same time!
Please enable Skill Evolution debug messages, do it again, and send me the full openmw.log

earnest linden
# 
[03:21:14.634 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Skill used handler: custom base gain for skill "restoration" is 0.75 (instead of current 1.00 and original 1.00)
[03:21:14.634 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Magicka skills scaling: no spell cast detected, no scaling
[03:21:14.634 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Magic handler: no spell cast detected
[03:21:14.634 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Decay handler: "restoration" decay is reduced by (gain 0.750 x scale 1.000 x recover factor 0.50) / (time factor 336) = 0.1116%
[03:21:14.634 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Decay handler: related skills decay "restoration" is reduced by (gain 0.750 x scale 1.000 x recover factor 0.50 x synergy factor 0.050) / (time factor 336.000) = 0.0056%
[03:21:14.634 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Level-based handler: skill "restoration" level 146, range [125, 25], scale 1.00000 x factor 0.13121 -> 0.13121
[03:21:14.635 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Final handler: skill "restoration", gain 0.75000 x scale 0.13121 -> 0.09841
[03:21:14.635 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Skill restoration gain 0.098 (requirement 110.250), progress 0.28448 -> 0.28537, excess 0.000```

"scale nil"

turning off faction perks and ctf stopped the skill reduction issue, but the skill level up message never shows up
#

[03:28:00.674 I] L@0x1[scripts/skill-evolution/player.lua]: DEBUG (player): Decay handler: "incantation_skill" decay is reduced by (gain 0.250 x scale 1.000 x recover factor 0.50) / (time factor 336) = 0.0372% [03:28:00.674 I] L@0x1[scripts/skill-evolution/player.lua]: DEBUG (player): Decay handler: related skills decay "incantation_skill" is reduced by (gain 0.250 x scale 1.000 x recover factor 0.50 x synergy factor 0.050) / (time factor 336.000) = 0.0019% [03:28:00.674 I] L@0x1[scripts/skill-evolution/player.lua]: DEBUG (player): Level-based handler: skill "incantation_skill" level 26, range [125, 25], scale 1.00000 x factor 0.98394 -> 0.98394 [03:28:00.675 I] L@0x1[scripts/skill-evolution/player.lua]: DEBUG (player): Final handler: skill "incantation_skill", gain 0.25000 x scale 0.98394 -> 0.24599 [03:28:00.675 I] L@0x1[scripts/skill-evolution/player.lua]: DEBUG (player): Skill incantation_skill gain 0.246 (requirement 33.750), progress 0.99895 -> 1.00624, excess 0.211 [03:28:00.682 I] L@0x1[scripts/incantation/player.lua]: INCANTATION SKILL MOD: Cast custom spell 'Companion: Greater Restore Fatigue' (+10.1 XP, +27 magicka [13.5% refund]) [03:28:00.715 I] L@0x1[scripts/skill-evolution/player.lua]: DEBUG (player): Skill "incantation_skill" has changed from 26 to 27 [03:28:00.715 I] L@0x1[scripts/skill-evolution/player.lua]: DEBUG (player): Skill incantation_skill gain 0.211 (requirement 35.000), progress 0.00000 -> 0.00602, excess 0.000

incantation_skill does have a debug message o_O(for levelling)

boreal apex
boreal apex
boreal apex
earnest linden
#

as shown in the video(i clipped that out) yes

boreal apex
earnest linden
#

yeah I don't see anything else, there's some weird math issue going on with the skill tracker in the corner but I don't think it's related to skill evolution o_O

sterile mason
# boreal apex it should be fixed after a save/load

Happens on that character still, even after a full computer reboot (just to make sure)

but at the moment the same lines are running on the debug, but no white flashing graphics error - genuinely no clue what ive managed there (New character)

boreal apex
#

Skill Evolution v2.0.1 and 2.0.2 released!

  • Fixed skill gain errors with custom skill registering after the player becomes active (e.g. Sun's Dusk Cooking)
  • The skill use gain settings have been reworked again and will be reset to their default values
  • Fixed custom skill max level for uncapped skills
  • Fixed NCG description tweaks overridden by this mod's additions to the skill tooltips
  • Removed permanent debug logs
boreal apex
acoustic heath
boreal apex
boreal apex
acoustic heath
acoustic heath
boreal apex
acoustic heath
boreal apex
acoustic heath
#

Just resetting the decay essentially

boreal apex
#

maybe 2 interfaces, with an optional resetProgression param:

    resetDecayedSkill = function(skillId, resetProgression)
        state.skills.max[skillId] = state.skills.base[skillId]
        if resetProgression then
            state.skills.decay[skillId] = 0
        end
    end,
    resetDecayedSkills = function(resetProgression)
        for skillId, base in pairs(state.skills.base) do
            state.skills.max[skillId] = base
            if resetProgression then
                state.skills.decay[skillId] = 0
            end
        end
    end,
boreal apex
# 

If you don't want the decay anymore, or something goes wrong with decay, you can:
- either set the `Skill Decay Rate` setting to `None` to restore all skills to their max value and remove the decay progressions
- or use one of the 2 interfaces to reset the decayed levels, while conserving the current skill values, and optionally reset the decay progress:
  - `I.SkillEvolution.resetDecayedSkills(resetProgress)`, where `resetProgress` is a boolean
  - `I.SkillEvolution.resetDecayedSkill(skillId, resetProgress)`, where `skillId` is a string identifying a skill

1. Press \` to bring down the console
2. Type `luap` and press enter to enter the Lua mode on the player
3. Depending on what you want to reset:
- Type `I.SkillEvolution.resetDecayedSkills()` and press enter to set all the decayed skill levels as the new base values
- Type `I.SkillEvolution.resetDecayedSkills(true)` and press enter to do as above, and also reset the decay progression of all skills
- Type `I.SkillEvolution.resetDecayedSkill(skillId)` and press enter to set the decayed level of the skill identified by the provided ID as the new base value
- Type `I.SkillEvolution.resetDecayedSkill(skillId, true)` and press enter to do as above, and also reset the decay progression of the skill identified by the provided ID
4. Optionally type `exit()` and press enter to quit the Lua mode
earnest linden
# 
[04:41:21.004 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Skill "jewelcrafting" has changed from 19 to 0
[04:41:21.004 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Skill "hauling_skill" has changed from 64 to 0
[04:41:21.004 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Skill "incantation_skill" has changed from 26 to 0
[04:41:21.004 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Skill "evasion_evasion" has changed from 15 to 0
[04:41:21.004 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Skill "climbing_skill" has changed from 20 to 0
[04:41:21.004 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Skill "crafting_skill" has changed from 15 to 0
[04:41:21.820 I] L@0x1[scripts/hauling/player.lua]:    HAULING v9: PICKUP +1.000 (accum 1.000)
[04:41:21.821 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Scale handler: skill "hauling_skill", scale nil -> 1.00000, gain 1.000 / 1.000 -> 1.000
[04:41:21.821 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Level-based handler: skill "hauling_skill" level 0, range [125, 25], scale 1.00000 x factor 1.25000 -> 1.25000
[04:41:21.821 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Final handler: skill "hauling_skill", gain 1.00000 x scale 1.25000 -> 1.25000
[04:41:21.821 I] L@0x1[scripts/skill-evolution/player.lua]:    DEBUG (player): Skill hauling_skill gain 1.250 (requirement 1.000), progress 0.54615 -> 1.79615, excess 0.796```

turning off decay seems to reset all the custom skills to 0(except, oddly enough, incantation- ~~probably because it had data~~)
#

went to level up a different custom skill, like jewelcrafting, turned decay off and it reset every custom skill to 0 except that one o_O

boreal apex
#

I just found a bug where the skill max value (excluding decayed levels) for custom skill was initialized with 0, and it's not updated to the correct value until you raise the skill, which leads to 0 when disabling decay before any skill raise

#

in the mean time, you can fix it by manually setting the max value with the console, before disabling decay, for example:

luap
I.SkillEvolution.getState().skills.max["crafting_skill"] = 40
earnest linden
#

The recent one on Nexus, 2.05?

boreal apex
boreal apex
#

Skill Evolution 2.0.{3,4,5,6} released!

  • Fixed custom skill max value (excluding decayed levels) set to 0, leading to a skill level 0 when disabling decay before any skill raise
  • Fixed Lua errors about "vector" on a new game
  • Added 2 new interfaces to reset the decayed skill levels, and optionally reset the decay progressions
  • Improved the Skill Use Gains setting by including custom skills into base skill categories
  • Fixed the reset button not working for the Skill Use Gains setting
  • Improved the Skill Uses Scaled setting descriptions (modifiers are excluded for success chance formulas)
  • Fixed multi-school spell skill scaling error
  • Fixed decay error with custom skills
  • Fixed custom skill use gains not properly initialized
  • Fixed custom skills not properly configured by previous released
#

Sorry for all the bugs and updates. The Skill Framework integration is trickier than I thought

#

All known bugs (from here and Nexus) are now fixed

earnest linden
#

Lol no worries, just thought I'd point them out before nexus did

boreal apex
boreal apex
sweet rampart
#

Hey, quick question re: you and Cybvep's magic mod: for the Area Effect Arrows patches, would Unofficial Morrowind Official Plugins Patched be considered modded?

#

Just wondering since you since specifically Expanded Vanilla and Total Overhaul lists, but Unofficial Morrowind Official Plugins Patched is only in the more vanilla modlists.

mild lantern
sweet rampart
#

awesome, thanks cybvep

quaint hound
#

I'm not sure if it's just me, but it seems like every version from 2.0 onward introduces a noticeable lag upon initializing a new game or loading a saved game. Otherwise the mod works perfectly.

Wanted to bring this up in case it's not just a problem on my end. Love this mod, mym. Thank you for making it!

boreal apex
sweet rampart
quaint hound
sweet rampart
#

I see, that's strange. You're right that scripting adds up, but I wonder what changed so much between versions.

quaint hound
#

From the changelogs, 2.0 was when handling for custom skills was added, so I assume that's the culprit

sweet rampart
#

I was also having some stutter whenever NPCs would talk to me (not the menu, I mean in the world), which I wasn't able to isolate either.

#

that could be unrelated, but making a note of it

sweet rampart
quaint hound
#

It's weird too, because mym added custom skill handling to NCG as well lately, but I've noticed no problems from updating that one

sweet rampart
#

With all likelihood it's just some happenstantial error. I'm sure it'll be fixed

quaint hound
#

Yeah probably, doesn't need to be rushed anyway

boreal apex
#

@quaint hound @sweet rampart I did many tests until I could understand from where the lag on game load was coming

#

it seems that declaring the Skill Evolution setting page takes almost one second to the engine!

#

I delayed the declaration to the first time the main menu is shown, and it seems to be good that way

#

please try v2.0.7

quaint hound
#

Working great on my end! Thanks so much

boreal apex
#

I think I put too much effort (and too many settings) in my setting pages....

#

still, this is weird, because I don't remember such a lag in previous OpenMW versions.
My settings did get a bit more complex, but not that much.
I counted the time required by my settings to build, and it's like 0.005s all included, but then I suppose OpenMW needs time to generate the rendering

sweet rampart
#

I have no idea, but pushing it to the main menu sounds like a good idea. Probably just compounding factors or a runaway function or something makes it take longer than expected—but I'm no programmer, so idk

#

Thanks for the fix, great stuff

acoustic heath
#

mym, I've noticed that skills lowered by Character Traits Framework are counted as decay by SE. I was wondering if you might add something like: lua return { eventHandlers = { CharacterTraits_traitSelected = function() I.SkillEvolution.resetDecayedSkills() end, } } unless you've already got a solution worked out. Also, could you call updateStats() in the resetDecayedSkills interface function like so: lua resetDecayedSkills = function(resetProgress) updateStats() for skillId, base in pairs(state.skills.base) do state.skills.max[skillId] = base if resetProgress then state.skills.decay[skillId] = 0 end end end, just to ensure that base is up to date before setting max?

boreal apex
acoustic heath
#

I didn't have the opportunity to test mid-game, but SE doesn't currently have any way of accounting for external modifications that decrease skills in determining state.skills.max, right?

boreal apex
#

max skills -> number of decayed levels

quaint hound
#

So I'm not yet sure if it's Skill Evolution or NCG causing it since I updated both at the same time and have been lazy about troubleshooting, but I've noticed that occasionally when I pause the game to bring up the main menu, there will be a short delay before it's able to be interacted with

When I get some time later I can do some more thorough testing if it will help, but I felt it worth mentioning for now

boreal apex
# quaint hound So I'm not yet sure if it's Skill Evolution or NCG causing it since I updated bo...

I recently fixed a lag on game loading, and the fix was to delay the setting page declaration to the first time you access the main menu.
I did not notice any lag with this new approach, but I suppose this could be felt depending on your system.
I don't know why the Skill Evolution setting page takes almost one second to be registered by the engine, and I don't know how to improve it currently

quaint hound
#

I appreciate you sharing your work with the community. I always felt like Morrowind's leveling system was busted by default, and in the past on the old engine I'd always use Galsiah's Character Development as a replacement. Your work with NCG and Skill Evolution feels like a successor to that.

boreal apex
#

when I have some time, I'll try to do more invsetigations on this topic

mild lantern
#

I'm another OG GCD fan. It always felt like the way things should work. NCG is like GCD next gen 36vehks .

quaint hound
boreal apex
#

Skill Evolution 2.0.9 released!

  • Fixed decayed levels increased when the base skill value is reduced by a mod, the console, or any other external source
  • Fixed no skill up notifications above skill level 100
  • Fixed residual decay applied when re-enabling decay
  • Fixed skill gains broken after resetting the Skill Use Gains settings
quaint hound
#

Is there any chance we could get an option for a per-level training limit in the future? Something similar to how Oblivion and Skyrim only allow buying five sessions per level

acoustic heath
# boreal apex The decayed level issue should be fixed in 2.0.9. Also I added an updateStats in...

mym, the new skill decay works great for compatibility. It's able to weather skill decreases from both Character Traits Framework and UL. My only problem at the moment though is this line in your skillLevelUpHandler: if state.skills.decayedLevels[skillId] > 0 then mCore.modSkill(skillId, 1, { recovered = true }) return false end You return false to prevent the normal skill levelup message, right? It's just that it makes it a nightmare to workaround as any mod that relies on detecting the skill levelup will fail to function including something like Reading is Good, unless its skillLevelupHandler is added after SE's

boreal apex
#

I'm not sure what we want when a player reads a skill book while having decayed levels

#

I think it should increase the level without reducing the number of decayed levels

acoustic heath
#

Are there any mods that would be disadvantaged by not returning false?

#

And the other instances where you return false for example the skill cap, would it be preferable for compatibility to instead do params.skillIncreaseValue = 0

#

and just return

boreal apex
acoustic heath
boreal apex
#

I'll fix all that tomorrow if I find time

acoustic heath
boreal apex
acoustic heath
boreal apex
acoustic heath
#

You're still returning false here: if source == I.SkillProgression.SKILL_INCREASE_SOURCES.Usage and state.skills.decayedLevels[skillId] > 0 then mCore.modSkill(skillId, 1, { recovered = true }) return false end

#

and wouldn't it be preferable to mod the skill by options.skillIncreaseValue?

#

especially here: if skill.base >= 100 then mCore.modSkill(skillId, 1) end

acoustic heath
boreal apex
boreal apex
acoustic heath
#

But doesn't jail with it's negative options.skillIncreaseValue still go through the same skillLevelupHandler?

#

Does jail affect skills that are over 100?

#

Because if this condition is met:if skill.base >= 100 then wouldn't it increase the skill value by 1 regardless whether the option.skillIncreaseValue is positive, negative, or 0?

boreal apex
acoustic heath
# boreal apex I'll have to check that, thx for heads up

mym, just one more thing I've been meaning to ask you, I know that MOMW lists load SE fairly late, and SE waits until onActive to add its skill handlers. Is there a reason that SE wants to act first? Because I was thinking with the interface function that allows external handlers to insert before SE's final handler, surely SE would prefer to act last and have the final word? And surely it would be better from a compatibility standpoint as well? I'd be curious to hear your thoughts

boreal apex
boreal apex
boreal apex
#

Also, as SE can alter skill base gains (setting page), if another mod's handler comes first and applies a percent on the gain (like double gain) before SE's handlers, then SE won't know how to properly apply the custom gain

#

It's also good that SE has the last word, specifically for the "carry over excess gain" feature

#

It's tricky and that's why I recommend other mods to use the dedicated interface to be called at the right time

#

I could also have split the omwscripts addon into one to put early in the load order, and another late. But I would make the code more complex I think

boreal apex
boreal apex
#

I think I should do it too, to allow other mods to get the skill book and training events

#

Skill Evolution 2.1 released!

  • Stop restoring decayed levels for skill increases coming from training or skill books
  • Compatibility: Don't stop the skill level up handler chain when a skill raise is blocked by a cap, a disabled skill book, or a capped training (just set the increase to 0)
  • Fixed jail decreased skill levels not properly handled, and added a notification and decrease sound
quaint hound
#

Fantastic work, thank you!

acoustic heath
acoustic heath
#

That way SE could have the first and the last word

#

It would only need to load after Skill Framework is all

#

I've also found that because SE loads so late in MOMW lists, I'm unable to call SE's interface onLoad to add my own skill handlers

ember cloud
acoustic heath
#

I've had to use an eventHandler with an event sent onLoad just to catch it

ember cloud
#

Handlers is one thing that should always happen in the script body. Otherwise you're subsribing to resolution order nightmare

#

And yes, we've talked about it with Mym as well. Load your script after if you depend on the interface and register handlers in the body.

#

#lua-scripting message

mint rapidsBOT
#
.foll

It's never correct to add handlers anywhere besides the body. If it were reasonably possible to police this i think we should

Linked by @​.arrean from #lua-scripting ·
acoustic heath
ember cloud
#

give me a sec

#

This is probably the main problem for you:
#lua-scripting message

mint rapidsBOT
#
.foll

engine handlers are handlers like onUpdate(), onFrame(), etc. They are run in load order because they are run independently of one another.

Linked by @​.arrean from #lua-scripting ·
ember cloud
#

And also why Mads was so adamant about never registering handlers in onLoad, or anywhere beside script body.

#

But also, specifically for SE itself. - with "other mod came in and did somethin" - I'm not sure that's that big of an issue

acoustic heath
# ember cloud And also why Mads was so adamant about never registering handlers in onLoad, or ...

I will say the only skillUsedHandler I've done that with is this: ```local function updateSkillHandlers()
local function getSkillUsedHandler()
return function(skillId, params)
local unmod = state.skills.unmod[skillId]
local maxValueUnmod = ulSet.getSkillMaxValue(skillId)
if unmod >= maxValueUnmod then
local skillStat = state.skills.stat[selfId][skillId]
skillStat.progress = 0
params.skillGain = 0
ulLog(string.format("Preventing skill "%s" progress from usage due to Max Value Unmod %d", skillId, maxValueUnmod))
return
--return false
end
end
end

if I.SkillEvolution and I.SkillEvolution.addSkillUsedHandler then
    ulLog("Skill Evolution added skillUsedHandler")
    I.SkillEvolution.addSkillUsedHandler(getSkillUsedHandler())
else
    I.SkillProgression.addSkillUsedHandler(getSkillUsedHandler())
end

end```

#

Which is supposed to negate the skill increase if a condition is met

ember cloud
# 
local function registerHandlers()
    if I.SkillEvolution and I.SkillEvolution.addOnHitHandler then
        logging:debug("registering SE onHitHandler")
        I.SkillEvolution.addOnHitHandler(onHitHandler)
    else
        logging:debug("registering regular onHitHandler")
        I.Combat.addOnHitHandler(onHitHandler)
    end
    I.SkillProgression.addSkillLevelUpHandler(skillLevelUpHandler)
end

registerHanlers()

same/similar on my end - in the script body. I mean, you can probably do the same. Zero out the gain/scale - and if you load after SE - you should be before it in handlerChain

#

it will get 0, and iirc Mym has added a "do nothing if you got a 0" several updates back

#

^ though that last one may need doublechecking, cause before it definitely broke with 0 at one point

# 
          --return false

I see it's commented out, but definitely don't do that though :O

acoustic heath
#

I'm only threatening to do it angyfargoth

#

But, Arrean, I was referring to the problem of SE wanting to act both first and last

ember cloud
mint rapidsBOT
#
.arrean

But also, specifically for SE itself. - with "other mod came in and did somethin" - I'm not sure that's that big of an issue

Linked by @​.arrean from #Skill Evolution ·
ember cloud
#

That it needs to act first and last

#

But that's up to Mym to decide.

acoustic heath
#

Could SE load early and add some of its handlers in its body acting first and add some of its handlers onActive acting last?

#

Is the reasoning correct at least?

#

It would definitely benefit SE to act last as it handles the skill gain and it carries over any excess

ember cloud
#

but yes, that may work

acoustic heath
#

Body last; onActive first

ember cloud
#

Hold up a second

#

Handlers registered in the script body - are registered first to last in the order scripts are loaded and resolved in the opposite order

#

onActive - will run fuck knows when, probably when the game is loaded and simulation starts ticking - meaning the handler registered there will be registered dead last, and resolved first

#

engineHandlers like onLoad/onActive - etc run in load order as they are not mutually dependent

#

Do go over my converstation with Mads that I've linked above too

acoustic heath
#

Yeah precisely, I was reasoning that SE should load first allowing its interface to be called by any mod that follows and add it handlers first allowing them to act last

ember cloud
#

It's fucking confusing though, I agree

#

So, yeah, based on that - still up to Mym, but I think just having SE load early - and anything else that depends on it, or alters skill gains after - should be enough

#

I kinda fail to see the reason to split the handlers

acoustic heath
#

mym said something about SE needing to act first otherwise it results in odd skill gains

ember cloud
#

Yeah, but I don't know why that is a problem

Also, as SE can alter skill base gains (setting page), if another mod's handler comes first and applies a percent on the gain (like double gain) before SE's handlers, then SE won't know how to properly apply the custom gain

#

Can't it just act on whatever value came in?

#

Odd gain then would still not be SE's fault

acoustic heath
ember cloud
#

Yeah

boreal apex
# ember cloud Can't it just act on whatever value came in?

Skill base gains are defined in GMSTs. SE's trick is to replace the incoming gain by the one defined in SE's settings.

However I don't want to override a gain altered by a mod or custom gains manually triggered.

My approach is to compare the incoming gain with the gain set by the GMST (vanilla or modded), and if it matches, then I can safely override the gain. If not, I choose safety and I ignore the SE's setting override.

Then, if SE's handler is called first, I'm sure I'll get either the GMST gain (override ok) or a manual trigger with custom gain (ignore ok).

#

If a mod doubles the gain before SE's handler, then I cannot know whether it was an absolute value (should not override), or a relative one (+100%), where I can apply SE's custom gain on top of it.

#

Example:

  • SE gets a gain of 2 on a skill that's supposed to get 1 (GMST)
  • the player sets a get of 1.5 in SE's settings
    -> did a previous handler doubled the gain? Then I can apply the player's setting: 1.5 x 2 = 3
    -> did the previous handler just wanted to set 2? Then I should not alter the gain
ember cloud
#

That I guess makes sense. If you want to consider other mods like that.

acoustic heath
#

You could also just always adopt the first approach and just do (1.5 / 1) * 2

boreal apex
boreal apex
boreal apex
acoustic heath
boreal apex
#

Using SkillProgression.skillUsed(skillid, options)

#

Anyway, if you guys think my absolute value scenario is uncommon enough, then maybe I could just set the handlers at the script root and ask the MOMW team to move the mod up in the load order

boreal apex
#

It would also be good for the on hit handlers

boreal apex
#

Maybe a better skill use gain setting could be a simple percent, instead of an absolute gain, which would be more explicit regarding the new approach

boreal apex
#

@ember cloud @acoustic heath @mild lantern would a percent factor for skill use gains would work for you, instead of an absolute override value?

ember cloud
#

I send scale downstream from my use handlers, not gain valuie

#

so not sure if it applies

boreal apex
mild lantern
boreal apex
mild lantern
#

% would probably be less intuitive as I assume you would use Vanilla rates as base, so some stuff would seem to have much higher values, e.g. you greatly increased enchant skill gain and lowered recharge skill gain and it would show as high/low % by default. Gameplay-wise it wouldn't matter as long as the result is the same.

boreal apex
acoustic heath
boreal apex
#

The problem is I cannot tell whether the gain is a natural one, altered by a mod, or a manually triggered one, in which case I should just let it as is

acoustic heath
#

The override seems to me worse for compatbility. The percentage seems better for customisation

boreal apex
acoustic heath
boreal apex
acoustic heath
boreal apex
#

There is a big issue though: there are 2 skills which have a vanilla gain of 0
0 x 200% = 0 😅

#

Like enchant for on strike use type

ember cloud
#

But should on strike enchant even grant xp - that's one area of vanilla that I kinda agree with

#

you're using a weapon someone else enchanted, and the use of it doesn't involve magical skill

acoustic heath
boreal apex
#

Not sure. Speechcraft fail maybe

boreal apex
ember cloud
#

That's fair

restive walrus
ember cloud
#

Nah, that's fair. More settings for the god of settings :D

restive walrus
#

Speaking off, I've noticed a while ago that buying and selling stuff without negotiating the price increased mercantile skill. I'm pretty sure it didn't in the old NCGD I used to use (required modifying the trader's offer at least by 1 gold). I would appreciate (yet another) customisation option for that too huhu

#

Similar to enchant, to be able to set how much (if any) xp would be gained from successfully negotiating a price, and same with non-negociated transactions.

mild lantern
restive walrus
#

Strange

#

I have zero mod related to trading or mercantile

#

Only mods I installed recently were magic-related, or UI (time HUD, all the "-extended" collection..) and the perks and traits mods

#

And of course, switching from NCGD to SE+NGC

#

Which is why I thought it came from SE

mild lantern
#

NCGD is quite old. Were you on that old stuff before? 😄

restive walrus
#

Yes

mild lantern
#

the split happened a long time ago

#

like months

restive walrus
#

Back from 0.49

#

Yes

#

I hadn't played since like, a year ago or so

#

Didn't want to make a new install yet

#

Just picked up my old one

mild lantern
#

ok

#

I think that SE doesn't change anything about Mercantile except standard modifiers (so global skill gain rate and the possibility to change the base skill gain in the mod settings)

#

so it seems like a different mod

#

maybe one of the UI ones you mentioned has some features related to that

#

@boreal apex Does SE do anything with Mercantile besides the usual stuff?

restive walrus
#

The UI stuff is just TimeHud and all the "window extended" collection (magic, inventory, stats..)

mild lantern
#

Magic Window Extender and Stat Window Extender don't change this, that's for sure

#

not sure about IE

restive walrus
#

Tbh, I've been playing with GCD then NCGD then SE+NCG for so many years, I have no idea what vanilla is like any more huhu

mild lantern
quaint hound
#

GCD was so good back in the day

restive walrus
#

The only thing I know is that I liked that mercantile leveling required actual negociation. Then thought about it, and figured if it was customizable, I'd probably set it like with enchanting : a minimal gain on non-negociated trades, just so that it's not nothing but significantly more on negotiated trades.

#

Now it seems more related to how much money is transferred, regardless of any haggling taking place or not

restive walrus
restive walrus
mild lantern
#

yep, it changed TES experience forever to me

#

just felt the "right" way for that system to work

#

and now I'm so used to this that I consider it Vanilla

quaint hound
#

Yeah, definitely. There's no way I can go back to the vanilla system.

restive walrus
#

It ruined vanilla leveling for me. Once I tried it, I could never play vanilla ever again

restive walrus
mild lantern
#

I usually doze off during discussions about levelling, modifier optimization and such, because it's been "solved" by GCD years and years ago. I consider NCG+SE to be modern version of GCD, pretty much.

quaint hound
#

Yeah. It's funny how Oblivion gets blasted a lot for the leveling system when it's almost exactly the same as Morrowind's. Folks just started to notice it more because of the poor world scaling, lol

mild lantern
#

in MW, it's not a big issue

quaint hound
#

Yeah, exactly

restive walrus
#

Oblivion's big problem wasn't the character leveling, it was the rest of the world's leveling huhu

mild lantern
#

and ironically, it's never been the rats

#

this is always the meme

#

but it's not rats

#

it's the fooking bandits

#

IMO playing OB without a mod that handles level scaling one way or another is pointless

quaint hound
#

Yeah. Certain enemy types in Oblivion have hard caps where they stop leveling. Bandits and marauders are awful though. And if I remember correctly, the world spawns start throwing more mountain lions and crap like that at you the higher you level.

mild lantern
#

I wonder what they were thinking when they gave daedric armor to bandits

restive walrus
#

When I first played the game, I realised something was wrong when I became champion of the arena at lvl 3. Then I joined the TG and Dark Brotherhood. I had a blast setting up "accidents" for my assassination targets, while sneaking around.
Then I had to enter the gates of Oblivion and realised my stealth character was fucked.

ember cloud
mild lantern
quaint hound
#

Oh yeah for sure. I know in Morrowind, dungeons can start spawning crazy stuff at higher levels. The ancestral tomb outside of Caldera is a good place to see that, if you go back every so often as you level, there will be more dangerous daedra.

mild lantern
#

yep

#

but the weaker ones never stop spawning

#

the concept of levelled lists wasn't changed too much in TES3-5

#

but level scaling became a thing from TES4 onwards

ember cloud
#

bloodmoon onward

mild lantern
#

ok, they had one level scaled enemy in Tribunal. Gedna Relvel. The script was broken, though, so it didn't work 🙂

restive walrus
#

Skyrim does it too. It's just that TES IV was awfully balanced, when TES III and V nobody complained

quaint hound
#

I always thought level scaling wasn't the worst idea in the world, but the way Bethesda handled it was awful. The premise is to keep the game challenging, but in practice it all just ends up bullshit nonsense.

restive walrus
mild lantern
#

oh, and Tribunal also had levelled DB assassins

#

everybody loves those

quaint hound
#

Tribunal is all over the place as far as balance goes. It's such a weirdly designed expansion. I like the city of Mournhold though.

mild lantern
#

no daedric armor bandits in Skyrim

ember cloud
#

Skyrim still suffers from wet-noodle-itis

mild lantern
#

they reigned the system in

ember cloud
#

but not as bad

mild lantern
#

they increase stats

#

but keep equipment in check

#

and they have area-based level ranges

#

so not every area is the same

#

in OB everything is fucking same

#

no matter where you go, everything is level scaled

#

like wtf

ember cloud
#

Yeah

#

as I said, not as bad

quaint hound
#

Yeah. Skyrim is much better designed than Oblivion. It's just a shame it's not as feature-packed a game as Morrowind is.

restive walrus
#

My opinion about TES V is not that it lacks features, it's just the writting that's problematic

quaint hound
#

Yeah, that too

mild lantern
#

voice acting is also often pretty bad

#

it gets annoying fast because of how repetitive it is

#

those guard memes were fun the first few times, I think

#

but Skyrim Vanilla is like... a decent action adventure game. I don't think that Vanilla Oblivion is even playable.

#

ideally, you will use mods for both, but OB has more "essential" ones

quaint hound
#

I can't play Oblivion without most of Maskar's mods, personally. He does some really great work.

restive walrus
#

OB made me discover mods doitswit

mild lantern
#

😄

#

curious about Skyblivion. Actually, what will they do with level scaling?

#

I don't know. IIRC the mod was supposed to be released already.

restive walrus
#

Can't be worse than OG

quaint hound
#

Yeah, definitely. I'm more excited about Project Cyrodiil these days. The work done on Anvil that's already playable is beautiful.

ember cloud
#

Oblivion needs "scaling unclusterfucked"

boreal apex
restive walrus
#

That's a relief

#

So yeah, while Arrean and I were agreeing on the goodness of offering more settings to the god of settings, I remembered to make this suggestion I'd though about for a while

#

If possible, to add customisation to exp gain on haggle and no haggle trades, like, if they can be separated (kinda like the enchant exp on "on strike" and "on use" enchantments)

boreal apex
restive walrus
#

(I personally see no-haggle trades kinda the same way as "on strike" enchants : while it makes sense it would bring familiarity over time, I don't see it as much of an experience in the field. I like the idea of it giving minimal exp, but not enough to be a viable way of training.
I noticed my non-mercantile character suddenly leveling mercantile ever since I switched from old NCGD to current NCG+SE, despite never haggling. I can deal, but if there is a way to tone down his mercantile growth without gimping actual trader behaviour, I would be happy to have it.

restive walrus
#

Oh, you mean it's like an on/off thing, but no way to give a different amount of exp depending on how successful the haggling was (i.e. if you lowered the price by 1% Vs by 20%)?

#

I just meant this :

rn_image_picker_lib_temp_655aeed6-55b2-4a74-b3fe-57b7fce089ad.jpg
#

Like if no haggle could have a different value from haggled trade

boreal apex
# restive walrus How did it work then, when no haggle brought no exp?

A year ago, or so, low haggling gave low XP, and no haggling gave 0 XP. Then, low haggling started to give no XP. I thought it was an engine bug, and I "fixed" it by giving the base gain. But apparently, as you reported, it seems that the bug was different and no XP was given for low AND no XP. Then my fix caused another bug

restive walrus
#

Ohhh I see

#

A year ago is about when I stopped playing, so it makes sense that I missed all this development

#

Oh well, it's not a huge deal, was just a suggestion

#

Thanks for the explanation

boreal apex
#

I'll do some tests to see whether there is something to do about it

restive walrus
#

Cheers

sweet rampart
#

Which, notably, are things that NCG and SE address quite well

quaint hound
sweet rampart
#

I've tried just simply reducing my leveling speed, but then the moment-to-moment gameplay can feel quite slow. Already sporadically used skill like a lot of the magic skills increase at a crawl--but if the speed is increased (but still slower than vanilla), you'll inherently level faster, and ultimately no universal modifier can address every skill evenly

#

Since spamming a sword is weighed nearly the same as casting a spell, even if the latter typically happens inherently less often

#

The dynamic scaling of faster increases at low skill levels and slower at high levels is definitely the best way to do it

#

that way you're not suffering in the early game and struggling for singular increases lol

restive walrus
#

'cause vanilla Oblivion didn't work at all huhu

sweet rampart
#

Such as level scaling in Oblivion's case, or content mods in MW's case

restive walrus
#

How fast or slow the player character increases is irrelevant when the whole world increases at the same pace.

The issue of big content mods in TES III, making slowing down player leveling speed, occurs precisely because the world doesn't follow the player exactly (you feel you are OP because you have become stronger than some content).

That's why TES IV specifically was so criticized. It's not the player leveling system, it's the world level scaling.

sweet rampart
#

That's kind of splitting hairs since leveling only exists in the context of the game it's in, but still

restive walrus
#

Yeah sorry, we are in agreement on that front huhu

sweet rampart
#

No worries, I didn't articulate my point very well in the first place

sweet rampart
#

In isolation their leveling systems aren't bad, but other systems--the general game's context--cause a lot of friction.

#

But the fundamental premise isn't bad, and even has some fun quirks to it

#

A lot of issues people have with vanilla leveling in MW have to do with unoptimized levels, which isn't so much of an issue to me since I simply don't care about that--but in Oblivion, if you don't level well, you can easily end up weaker

#

again, my bigger problem is just how damned fast it is

restive walrus
#

Yeah, I found it funny for 5 minutes when my first TES IV became the champion of the arena at level 3, but I can't say anything positive about it past that huhu

sweet rampart
#

Oblivion is funny, if nothing else lmao

#

I've had some fun with it but it's lacking in most things I want out of an RPG. But it has proper skills, unlike Skyrim, so I'll give it an edge

restive walrus
sweet rampart
#

What mod is that? haven't heard of it

restive walrus
#

I forgot tbh, it might be a TR thing.

sweet rampart
#

Just TR_Factions, maybe?

#

I use that as well if so

restive walrus
#

Maybe. I really don't remember

sweet rampart
#

gotcha

#

That mod just places TR content in normal faction context

#

so like, no more rising through the ranks from just Vvardenfell

#

Once more Redoran content gets added I think it's firmly the best way to play

mild lantern
#

yeah, TR Factions is literally there in order to prevent being able to blaze through the faction questline just by doing Vvardenfell stuff

boreal apex
boreal apex
restive walrus
#

....I just messed up my install by accident 😭
...I don't suppose there's a way to "undo" data deletion in the launcher?

ember cloud
#

otherwise - no, I don't think there's an undo

restive walrus
#

Fuck me

#

I though I was on a test list I'd just created, and deleted a huge chunk of file paths in the data tab, then noticed it was actually my main list I was playing on

#

...guess that Wretched playthough I had started is going to wait. I guess it's finally time to do that new install I was putting off. Not going to be able to play again for a while 😢

mild lantern
ember cloud
#

I've screwed up my deploy scripts for indev mods just over a month ago. And instead of deleting just the mod directory on deploy - it wiped entire mods directory doitswit

mild lantern
restive walrus
#

This is going to take days at best

mild lantern
#

Once a Wretch, always a Wretch todd .

#

Maybe you can speed it up with console. Get back roughly to the point you were.

restive walrus
#

The lack of inventory space is the biggest hurdle of the Wretched start imo. I had just gotten my strength to a point where I could wear my full armour + weapon without being over encumbered

mild lantern
#

Just set some skills to higher lvl post chargen and let NCG recalculate?

#

Add gold amount which seems fair

#

And you will have faster start

restive walrus
#

Nah, not fun that way. I'll restart. What I'm most bummed about is that I just wanted to play, and now I'll have to spend days/weeks just figuring out a full modlist for myself and installing and testing it.

#

I could try to just repair what I just did, but at this point I might as well do the full reinstall I had been putting off for weeks

mild lantern
#

So all your files got deleted?

#

Can't check savegame for a modlist?

restive walrus
#

Not all. But a big chunk of them

mild lantern
#

Nothing in trashbin?

restive walrus
#

I didn't delete files

#

I delete the data paths to them in the launcher

mild lantern
#

Is it a custom modlist?

restive walrus
#

Figuring out what I deleted exactly and need to reinstall will be a nightmare

restive walrus
# mild lantern Is it a custom modlist?

Yes and no. It's my old hundreads-of-mods install, that I've been adding stuff on for the past months. I have a backup list, but it's still weeks-old, I've been updating/reordering/adding mods since then, figuring out what isn't something I'm looking forward to

#

Since I've been wanting to make a new list from scratch for a while, might as well do it now. It's just going to take a while, and a lot of work 🥲

mild lantern
#

Well, this is where umo MOMW is easier as you can -sync, apply customizations and you will be mostly done.

restive walrus
#

...and I realise we're flooding SE's channel with non-SE-related discussion, stopping now (sorry mym)

boreal apex
#

Skill Evolution 2.2 released!

  • Improved the performances and reduced the memory usage of the script attached to actors (load less things)
  • The Lua "skill used" and "on hit" handlers are now added at the script root
  • This mod should be placed before mods using handlers to alter skill gains on the player, or alter damage on the player or actors
  • Fixed the skill down notification message when not caused by a skill decay (e.g. jail)
  • Fixed upgrade error from versions below 2.0
sly rain
#

It’s worth noting that OSSC now has MBSP setting for quickcasting which you can pair with MBSP setting of SE. 🙌

boreal apex