1.5.5 Buffed Alchemist (Talent Revision)

[Thexare]

2. addon fails if Revised Alchemist active.

Revised Alchemist 0.8.2
Steam-Chemist 0.9.9

That's because you're not supposed to use both:

Two versions of addon- alchrevision is for those who don't own EoR, and steamchemist is for those who do.

[Nevuk]

2. addon fails if Revised Alchemist active.

Revised Alchemist 0.8.2
Steam-Chemist 0.9.9

That's because you're not supposed to use both:

Two versions of addon- alchrevision is for those who don't own EoR, and steamchemist is for those who do.

Pretty much. Though I will say that unless you're playing SteamChemist specifically you probably want to use alchrevision - steamchemist breaks command staff's elemental functions, and I honestly have no idea why, as nothing I did touched normal staves at all.

I had to delete and reupload alchrevision to steam to get it to upload the thunderclap gem fix, just an fyi for subscribers.

[Thexare]

That's actually kind of frustrating; I'm running some other mods that mess around with Alchemists, so it was the Steam Chemist specifically that I was interested in. I love me some hybrid classes.

Could something have gone wrong in copying the staff egos to steamstaves?

[Roukoru]

And what about "1"? (throw bomb still consume gems)

[Lokean]

steamchemist breaks command staff's elemental functions, and I honestly have no idea why.

I know why, but I couldn't tell you how. Hopefully it'll save somebody some time.

Your dialogue is failing when it looks for elements. A quick source-dive into the command staff dialogue gives us:

Code: Select all

local flavors = o:getStaffFlavorList()
local flavor_list = table.keys(flavors)
table.sort(flavor_list)

local aspect_answers = {}
local aspect_chat_id = not is_sentient() and "welcome" or "which_aspect"
for _, flavor in ipairs(flavor_list) do
	local damtypes = o:getStaffFlavor(flavor)

So, o:getStaffFlavor(flavor) is returning an empty table, rather than a list of elements. Looking in mod.class.Object I found:

Code: Select all

function _M:getStaffFlavor(flavor)
	local flavors = self:getStaffFlavorList()
	if not flavors[flavor] then return nil end
	if flavors[flavor] == true then return standard_flavors[flavor]
	else return flavors[flavor] end
end

So the return standard_flavors[flavor] is returning an empty table. It's defined locally in the source as:

Code: Select all

local standard_flavors = {
	magestaff = {engine.DamageType.FIRE, engine.DamageType.COLD, engine.DamageType.LIGHTNING, engine.DamageType.ARCANE},
	starstaff = {engine.DamageType.LIGHT, engine.DamageType.DARKNESS, engine.DamageType.TEMPORAL, engine.DamageType.PHYSICAL},
	vilestaff = {engine.DamageType.DARKNESS, engine.DamageType.BLIGHT, engine.DamageType.ACID, engine.DamageType.FIRE}, -- yes it overlaps, it's okay
}

So, somewhere, your addon is breaking the scope that allowed engine.DamageType.FOO to resolve correctly, resulting in standard_flavors["magestaff"] returning {} rather than {engine.DamageType.FIRE, engine.DamageType.COLD, engine.DamageType.LIGHTNING, engine.DamageType.ARCANE}

Now, the problem is, I have no idea why, either.

I tried though!

[Nevuk]

steamchemist breaks command staff's elemental functions, and I honestly have no idea why.

I know why, but I couldn't tell you how. Hopefully it'll save somebody some time.

Your dialogue is failing when it looks for elements. A quick source-dive into the command staff dialogue gives us:

Code: Select all

local flavors = o:getStaffFlavorList()
local flavor_list = table.keys(flavors)
table.sort(flavor_list)

local aspect_answers = {}
local aspect_chat_id = not is_sentient() and "welcome" or "which_aspect"
for _, flavor in ipairs(flavor_list) do
	local damtypes = o:getStaffFlavor(flavor)

So, o:getStaffFlavor(flavor) is returning an empty table, rather than a list of elements. Looking in mod.class.Object I found:

Code: Select all

function _M:getStaffFlavor(flavor)
	local flavors = self:getStaffFlavorList()
	if not flavors[flavor] then return nil end
	if flavors[flavor] == true then return standard_flavors[flavor]
	else return flavors[flavor] end
end

So the return standard_flavors[flavor] is returning an empty table. It's defined locally in the source as:

Code: Select all

local standard_flavors = {
	magestaff = {engine.DamageType.FIRE, engine.DamageType.COLD, engine.DamageType.LIGHTNING, engine.DamageType.ARCANE},
	starstaff = {engine.DamageType.LIGHT, engine.DamageType.DARKNESS, engine.DamageType.TEMPORAL, engine.DamageType.PHYSICAL},
	vilestaff = {engine.DamageType.DARKNESS, engine.DamageType.BLIGHT, engine.DamageType.ACID, engine.DamageType.FIRE}, -- yes it overlaps, it's okay
}

So, somewhere, your addon is breaking the scope that allowed engine.DamageType.FOO to resolve correctly, resulting in standard_flavors["magestaff"] returning {} rather than {engine.DamageType.FIRE, engine.DamageType.COLD, engine.DamageType.LIGHTNING, engine.DamageType.ARCANE}

Now, the problem is, I have no idea why, either.

I tried though!

Thanks, that's very helpful. I may not be able to go through my mod fully for a couple weeks. Sounds like it's either something to do with one of the new damagetype I created or that I need to keep the same flavor names for the staffs. If it's the latter that's an easy fix, the former will take longer.

[HousePet]

I've located the exact line that causes the problem, but it makes no sense to me at all.

load.lua: line 9.

local PartyTinker = require 'mod.class.interface.PartyTinker'

I think you will need DarkGod to solve this one.

[Nevuk]

I've located the exact line that causes the problem, but it makes no sense to me at all.

load.lua: line 9.

local PartyTinker = require 'mod.class.interface.PartyTinker'

I think you will need DarkGod to solve this one.

Thank you tremendously. I've commented out this line and the lines that used it, as it was only for a single tinker that was meant as an alternative to a mana coil - a tiny part of the mod. I'll work on superloading mana coil instead as a route around it.


So 0.9.10 is out on steam/te4 :

Code: Select all

0.9.10:
Fixed command staff not having elements. Unfortunately, had to disable steam coil as a short term fix.
Also lowered modifiers on some steamstave artifacts, as they were slightly too high

And what about "1"? (throw bomb still consume gems)

What version of the mod are you on? It should be fixed on the latest version of both steamchemist and alchrevision. If you got it via steam, you may need to resubscribe - I had to reupload the entire mod to get the fix to finally upload.

[Nevuk]

Much thanks to HousePet and Darkgod for looking at the problem with steamcoils + command staff. It's now fixed, steam coil is re-enabled, so 1.0.0 is out for steamchemist.

Code: Select all

1.0.0: 
Steamcoil re-enabled (it's a tinker, a version of mana coil that gives some steam regen and can attach to steam staves). 
Generic steamstaves modifiers changed to .6 mag /.8 cun modifiers instead of .8/.8 

I thought about adding a steamstaff tinker creation option, but it doesn't really seem necessary in my playing, as I've never used the create steamsaws/steamgun options and found plenty of steamstaves.

I also thought about making it so that steamstaves use a separate talent from staves entirely was also on the table, but I'm still giving it some thought (it'd just be a duplicate of staff combat tree but the two masteries would be incompatible).

[Roukoru]

Taken SteamChemist alone, its Throw Bomb do not consume alchemist gems. But, it interferes with Arcanum Class Pack -- and gems no more...
Steamchemist 1.0.0
Arcanum Class Pack 2.2.13

[Nevuk]

Taken SteamChemist alone, its Throw Bomb do not consume alchemist gems. But, it interferes with Arcanum Class Pack -- and gems no more...
Steamchemist 1.0.0
Arcanum Class Pack 2.2.13

it'll probably depend on which one loads last - arcanum modifies a lot of the same spells using a very similar method. I got a steam comment about this same interaction, and the person reinstalled the module and it worked, but the only way that should happen is if the steamchemist changes are prioritized over the arcanum changes. (I have no idea how the loading order works in tome add-ons, tbh). Throw bomb will behave very differently even if it didn't consume ammo if arcanum is being prioritized (steamchemist/alchrevision have a damage formula that should result in somewhat smoother scaling).

I highly doubt the two mods are are going to be 100% compatible even if you get them to load in the right order, though. I'm also not sure what would need to be changed or how involved it would be.

[HousePet]

Well it depends on what exactly is clashing.
I could add a switch to Arcanum that would disable the changes to alchemist talents, but your overload of the gems file is also going to upset things.

[Nevuk]

Well it depends on what exactly is clashing.
I could add a switch to Arcanum that would disable the changes to alchemist talents, but your overload of the gems file is also going to upset things.

Yeah, I'll try to work on getting those to superload. Just wasn't sure how to do that in the past, as superloading items is rarer in mods. (I also had to overload golemancy for one reason or another, which is also probably a problem).

Actually, just want to check before I start, is it possible to do a similar style for altering properties of objects as we do for talents, rather than just overloading them? The closest thing I can find is grayswandir's weapon pack altering egos, but that's fairly different. All I'm actually doing in that overloading mod is changing one value on each gem

[HousePet]

Gems is tricky due to the way it doesn't actually have the items in it, but a couple of functions that creates the items.
It should be possible to change the items after they have been created though.

Which value are you changing, and do you really need to change it?

[Nevuk]

Gems is tricky due to the way it doesn't actually have the items in it, but a couple of functions that creates the items.
It should be possible to change the items after they have been created though.

Which value are you changing, and do you really need to change it?

Well, it's not a must, but I'd need to redo my balance formula otherwise. I changed the throw bomb damage formula, it no longer takes into account the field that provides extra power for diamond-type gems (ie +25%). Now all gems, instead of having their spellpower added to spellpower then averaged for the bonus spellpower calculation, instead use their power field as a multiplier - this was to make it more predictable what effect each gem would have when I wanted to balance.

Here's the damage calculation :

Code: Select all

inc_dam = inc_dam + (ammo.alchemist_bomb and [b]ammo.alchemist_power [/b]or 0) / 100
	local dam =self:combatTalentSpellDamage(t, 5, 175, ((self:combatSpellpower()*1.35 - 5)))
	dam = dam * (1 + inc_dam)

Here's what it is in yours (and normal tome alchemists) :

Code: Select all

   inc_dam = inc_dam + (ammo.alchemist_bomb and[b] ammo.alchemist_bomb.power[/b] or 0) / 100
   local dam = self:combatTalentSpellDamage(t, 15, 150, ((ammo.alchemist_power or 0) + self:combatSpellpower()) / 2)
   dam = dam * (1 + inc_dam)

So the difference is that the alchemist_bomb.power field is no longer used, which nerfs the diamond style gems. (My numbers may need tweaked a bit regardless). I could do something like

Code: Select all

inc_dam = inc_dam +(ammo.alchemist_bomb and ammo.alchemist_power and ammo.alchemist_bomb.power or 0)/100

but I think I tried that and it didn't work, originally. There's probably a work around though.

So what wound up happening is that I changed the alchemist power values on those gems by adding their additional power field so diamond became 95, etc. I also nerfed bloodstone/garnet power a bit because of the synergy with gem armor, but that may have been unnecessary now that I think about it.

I've changed it to this, which should let me get rid of overloading gems. Not sure how well our different infusions are going to play together, though.

Code: Select all

	
bomb.computeDamage=  function(self, t, ammo)
                local inc_dam = 0
		local powe = ammo.alchemist_bomb.power or 0
		local damtype = DamageType.PHYSICAL
		local particle = "ball_physical"
		if self:isTalentActive(self.T_ACID_INFUSION) then damtype = DamageType.ACID_BLIND; particle = "ball_acid"
		elseif self:isTalentActive(self.T_LIGHTNING_INFUSION) then damtype = DamageType.LIGHTNING_DAZE; particle = "ball_lightning_beam"
		elseif self:isTalentActive(self.T_FROST_INFUSION) then damtype = DamageType.ICE_SLOWONLY; particle = "ball_ice"
		elseif self:isTalentActive(self.T_FIRE_INFUSION) then damtype = DamageType.FIREBURNER; particle = "fireflash"
		elseif self:isTalentActive(self.T_AETHER_INFUSION) then damtype = DamageType.AETHER_GEM; particle = "ball_arcane"
		elseif self:isTalentActive(self.T_SHRAPNEL_INFUSION) then damtype = DamageType.PHYSICAL_SHRAPNEL; particle = "vapour_explosion"
		end
		inc_dam = inc_dam + ((ammo.alchemist_bomb and ammo.alchemist_power or 0)+powe) / 100
		local dam =self:combatTalentSpellDamage(t, 5, 175, ((self:combatSpellpower()*1.35 - 5)))
		dam = dam * (1 + inc_dam)
		return dam, damtype, particle
	end

I'll push out an update shortly with this change. Will overloading golemancy also be a problem or no?

Update pushed, for both alchrevision and steamchemist (should have no gameplay differences)