v6b8/v14a3 Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

This forum is for members of the public to post any announcements relating to Diablo 2 Mod Making including mod and patch releases amongst other similar subjects.
User avatar
erevos
Hosted Forum Moderator
Paladin
Posts: 145
Joined: Sat Mar 05, 2005 7:41 am
Location: Crete
Greece

Re: v6b6/v10b Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by erevos » Mon Mar 27, 2023 10:54 am

Hi @cypress and thanks for the lengthy and detailed answer.

I was also referring to your example of a portion of physical damage dealt as fire.
What i would like to ask if via this changes of yours to make stats trigger based on a % of char's life, for example, if let us say life drops below 20% a defense bonus is triggered, are this effects possible?

User avatar
Cypress
Moderator
Champion of the Light
Posts: 446
Joined: Fri Dec 01, 2017 2:08 am

Re: v6b6/v10b Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by Cypress » Mon Mar 27, 2023 11:39 pm

erevos, life based is possible. You will need to make a formula that determines your percent life and then create a conditional which uses the formula. Something like (100*stat('hitpoints'.accr)/stat('maxhp'.accr)>20)?(0):(x), where x would be the defense bonus, which you would link to whichever stat you want it to give.

Physical damage dealt as fire is much more complicated since there are three flavors of physical damage that need to be considered. I handle this in v10 by appending reference stats to many items, so that I can know if the player is wielding a shield, how many weapons the player is holding, what type of weapon is being used, the handedness of the weapon and the fighting style of the weapon. Basically, the calcs involving all this summarize to: Is the player wielding a one-handed weapon, a two-handed weapon or a mix-handed weapon (i.e. two-handed swords which can be used one- or two-handed)?
(a) If the player is using a one-handed weapon, compare avg 1Hdamage to avg throw damage, and use the higher value.
(b) If the player is using a two-handed weapon, compare avg 2Hdamage to avg throw damage, and use the higher value.
(c) If the player is using a mix-handed weapon, then are they using only that weapon, or are they wielding a secondary weapon or a shield? If using mix-handed as 2h (no shield, no secondary weapon), then use the (b) adjustment, otherwise use the (a) adjustment.

The damage type used (one-handed, two-handed or throwing) is then put into simple calcs: (mindmg)*(crazystatvalue)/100 and (maxdmg)*(crazystatvalue)/100, which is then linked to [firemindam] and [firemaxdam], which is then linked to the superoskill, which gives the amount of fire damage as a percentage of your base physical damage.

If you want a more complete explanation then I can give it.

Also, some other fun ideas for crazy stats:
Item restrictions. You can make crafting skills that require skill allocation, and will break the moment you fail to meet the requirement. So for example, maybe you have a skill called "Empowered Weapon", that lets you craft +10*lvl% damage and lvl% chance to cast level lvl Amplify Damage. You can then craft this bonus onto a weapon, but the weapon will set your Strength and Dexterity to 0 (unequipping everything) the moment your "Empowered Weapon" level drops below the skill level required by the weapon. This lets you tie cube recipes and skills together in a way that cannot be cheated through respeccing.

"Per attribute" stats. A lot of mods use these, but they don't actually work since they can be cheesed by equipping the item when your attribute is high (like when you have a lot of attribute charms equipped) and then lowering your attribute after the bonus is gained. With crazy stats, the value will update shortly after your attribute value changes.

Can encode non-damagerelated "per level" stats to crazy stats, which can save itemstatcost stat slots.

Passive skills can have as many stats as you want (no longer just 5), and they will now constantly update. For example, could give Cold Mastery +1% Cold Skill Damage per 5 points of cold pierce above 200% (since cold pierce above 200% does nothing otherwise).

Potions and the like can normally only modify 3 stats at a time. With crazy stats, you can make the potion change as many stats as you want.

User avatar
erevos
Hosted Forum Moderator
Paladin
Posts: 145
Joined: Sat Mar 05, 2005 7:41 am
Location: Crete
Greece

Re: v6b6/v10b Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by erevos » Wed Mar 29, 2023 2:03 pm

Thank you for all the info! Your work is admirable!

OrderOfTheScribble
Posts: 33
Joined: Wed Apr 05, 2023 7:35 pm
United States of America

Re: v6b6/v10b Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by OrderOfTheScribble » Wed Apr 05, 2023 9:15 pm

I love the fixes made in Overworked, and I see a lot of modding potential with these files, but I noticed a few issues with v10:
  • The defense bonus referenced by '[armorclass]' is implemented as a bonus to 'armorclass_vs_missile' for some reason, so it didn't show up on the character screen when I tested the 'acperdex' crazy stat.
  • Act 2 mercs weren't working for me until I changed the 'm-jab' skill used by act2hire in MonStats.txt to 'Jab'. The documentation says mercs still use the player version of skills, so I assume this was an oversight.
  • When I tested the 'unarmedscale' crazy stat, it didn't work, so I looked in Skills.txt and found that == was used in a bunch of conditions, but I thought at the time that it needed to be =. I reread the Formulae Guide as I was making this post, and == is correct, so I will have to reinstate that, but I remember unarmedscale not working before the change.
The testing I did after making that error prompted me to join the Phrozen Keep (I've been lurking for years and even done some txt modding for myself) and make this post. Even though I messed up a bunch of conditionals, the testing may still provide a clue as to why 'unarmedscale' doesn't work because it showed a limitation in updating, at least on the character screen. When I unequipped a weapon with the superstates charm equipped, the damage went to some crazy number (presumably because of the messed up skills), and it didn't matter whether or not I had a source of 'unarmedscale'. The unarmed damage became normal when I unequipped the charm, but the key is what happened afterwards. I re-equipped the charm, but the damage didn't go up until I re-equipped and then unequipped the weapon. It's possible the system has a bug/limitation where crazy stats don't work until the charm is reset, or perhaps it's a compatibility issue with one of the plugins I'm using.

I've fixed the conditions by restoring == after realizing the error, but for performance reasons, I'm not going to retest 'unarmedscale' before posting this. I was going to attach the mod, but when I made the zip and tried to attach that, it said the file was too large. In case it matters, the mod uses PlugY and BaseMod with a core version of 1.13c using D2SE.

User avatar
Cypress
Moderator
Champion of the Light
Posts: 446
Joined: Fri Dec 01, 2017 2:08 am

Re: v6b6/v10b Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by Cypress » Thu Apr 06, 2023 2:07 am

Hi OrderOfTheScribble, thanks so much for the bug fixing! And I'm really happy that Modworked encouraged you to start posting!

As to first the first issue, you got it exactly right. The reason for the bug is rather funny:

Somehow, the superstate system was preventing the usage of state-casting skills like Frozen Armor, Enchant and Fade. This was at the time presumed to be because of the sheer number of states being put out by the superstates item. I was furious since it meant all my effort was for nothing, then I ended up trying to restructure the entire system into individual mini-states that would be attached to items only as needed, which would be a huge pain to mod with. Yet this fixed nothing, the bug was still happening.

But then I realized, for some godforsaken reason, having InTown=0 on an Aura will prevent states from being cast in town, it had nothing to do with having too many states. Why InTown=0 on an aura prevents any States from being cast while in town EXCEPT for the aura's state, I do not know. But because of this huge mess, I then had to re-rework the system back into its original form, and I mistakenly, hastily chucked [armorclass] into armorclass_vs_missile since my sheet editor cuts off the text precisely at the end of armorclass (and thus, armorclass, armorclass_vs_missile and armorclass_vs_hth all look the same).

tl;dr intown=0 on an aura will prevent you from casting state skills in town only when an aura updates (which is every frame with the superstate passive updating aura)


For issue 2, I likely presumed at the time that Hirelings used the skills defined in hirelings.txt and not monstats.txt, thus I thought it wouldn't matter (or more likely I just lazily replaced every instance of Jab with m-jab in monstats). Excellent catch, thanks!


Now onto issue 3, I'm really not certain what is going on here. I started up a fresh copy of Modworked v10, loaded Punchman (one of the characters included in the saves), gave him the superstates charm (he doesn't start with it) and it works fine. Could you upload your save files and/or txt files? I presume you are using items generated in Modworked v9+ so that you have access to the weapon reference stats (requisite for unarmedscale and the dmgaselem stats), so the only other issue I can think of is that I forgot to add the weapon references to some weapons.


Also, if you'd like to see any other crazy stats or systems or ideas, feel free to request them and I'll see if they are possible to make.

------------

And just a random note: I've been considering adding a bunch of "Null" items, which you equip like normal gear, but these items do absolutely nothing, purely for the purpose of letting the modder reference what the player isn't wearing (i.e. if the player is wielding Null Gloves, then you know the player isn't wielding real, useful gloves). This would allow for some more references for crazy stats, so you could for example give a special bonus like "If you are not wielding Gloves, gain +40% Attack Speed", would allow for some very silly unique items (or skills, similar to something like Path of Exile Keystones, in particular the Hollow Palm Technique's Unencumbered status).

And another random note: I've been working on a system that allows for softcoded skill tabs. Basically, instead of using the skill tree, you use charms instead to represent tabs. This allows players to freely choose and swap between skill tabs (and restrict them from using certain tabs, or from using too many tabs, or from using undesired combinations of tabs).

OrderOfTheScribble
Posts: 33
Joined: Wed Apr 05, 2023 7:35 pm
United States of America

Re: v6b6/v10b Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by OrderOfTheScribble » Thu Apr 06, 2023 5:41 am

Re: issue 1: That is a funny explanation. I've had that too, where I misunderstood the cause of a problem and ended up wasting time on a non-solution only to revert it after it did nothing or caused additional problems.

Re: issue 3: I've retested unarmedscale, and it does work except under certain conditions. Specifically, if I equip the superstates charm while I have a weapon equipped and then remove the weapon, unarmedscale won't work (note: with the latest version of BaseMod, I have to unequip and re-equip the charm to activate its aura; I don't remember having to do that with older versions of BaseMod, and I find it too useful to ditch it just to get rid of that bug) until I unequip and re-equip the charm with no weapon equipped. Also, if I have it working and then remove all sources of unarmedscale, the game will still think I have it until I unequip the superstates charm. Conversely, if I don't have unarmedscale, and I equip a source of it without a weapon, it won't work until I unequip and re-equip the superstates charm.

My guess is the game is failing to update the crazy stat (which is internally a skill) to or from lvl 0 until the superstates charm is unequipped and re-equipped. I don't know why that's the case, but I guess it would affect any crazy stat, and I just wasn't testing enough before making my first post. I don't know if that's enough info for you, but I don't know how to attach the files you're looking for. It said invalid file when I tried to attach the shared stash file, so maybe I can't send the files you asked for via attachment anyway.

P.S. The null items idea looks interesting. Something I'd like to be able to do in modding is add proficiencies where each slot would have subtypes and requirements other than stats, level, or class. In a proficiencies system, I would make subclasses or a second class system separate from vanilla classes, and these subclasses or alternate classes would only be proficient in certain subtypes of weapons and armor. I figure crazy stats would make it easier/possible to implement such a system, and null items could help close off certain slots to certain subclasses and give an extra bonus for leaving a slot empty. For example, body armor could be subdivided into light, medium, and heavy. Each subclass would have a max armor proficiency of none, light, medium, or heavy. The heavier armor items would reduce mobility and spellcasting ability compared to light or no armor, but they would be set up to be more useful to a melee character (e.g. higher defense, damage reduction, and maybe resists or other defensive effects a tank would use).

User avatar
Cypress
Moderator
Champion of the Light
Posts: 446
Joined: Fri Dec 01, 2017 2:08 am

Re: v6b6/v10b Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by Cypress » Sun Apr 09, 2023 1:53 am

v10c:
Fixed the bugs described by OrderOfTheScribble (thanks!)
Removed an unnecessary reference on Attack.
Starting Gear now spawns with full durability and full quantity, just as if it were generated by charstats.
Pseudostats should no longer increase minimum level requirements.
Pseudostats should no longer appear on the skill bar.
Your character glows red after you die, indicating that you need to re-equip your Superstate Charm.
Added Null items, which allow modders to reference which item slots the player is not using.

---

I figured out issue 3. Basemod's Charm Zone does not have identical behavior to the vanilla inventory. Namely, with the vanilla inventory, charms will be re-equipped on game start (and thus the aura will activate every time); in Basemod, charms in the Charm Zone will NOT activate their auras on starting a new game. This was patched with an admittedly awkward setup where you start with a Superstate Charm and Superstate Gem, where the Superstate Gem is (supposed to be) socketed into the Superstate Charm. For whatever reason, Basemod's Charm Zone does re-activate auras of charms, but only if the aura is given by a socketable of the charm.

Players can cheese this system, since the Superstate Charm socket can be filled with socketables other than the Superstate Gem. There's probably a good way to prevent this without being too silly, but I cannot think of it right now.


Your proficiencies system is definitely possible. Functionally, it is very similar to the way unarmedscale works, relying on various hidden references to item stats that otherwise cannot be referenced. Namely, you'll need to append your reference stats to:
Uniqueitems.txt (will need to be applied to each unique item; note that the first stat is open since Modworked moves all the stats by one slot to make room for reference stats; should make it somewhat easier to go down the rows and copy-paste-in the desired reference stats)
Setitems.txt (same as uniqueitems, will need to be individually applied to each set item)
Automagic.txt (need to attach every desired item in weapons.txt, armor.txt and misc.txt to the desired reference stat affix; will apply your hidden stat to Broken, Normal, Superior, Magic, Rare, Crafted, Tempered)

For the reference stats, you could make a stat (or skill that acts as a stat) for each item slot. Then evaluate that stat's value: 0=unarmored, 1=light, 2=medium, 3=heavy. You wouldn't even need Null items, since every item would have the reference stat, and thus only a complete lack of the item will result in a stat value of 0.

And for the bonuses, they could be given by Superstates using various calcs that check the heaviness of the equipment slots, rewarding and penalizing the player with stats as desired.

I hope this helps, let me know if anything is unclear! It sounds like a very fun idea, I'd love to see a mod based around that concept. I might also be able to add partial support for this system in Modworked if you'd like.

User avatar
erevos
Hosted Forum Moderator
Paladin
Posts: 145
Joined: Sat Mar 05, 2005 7:41 am
Location: Crete
Greece

Re: v6b6/v10c Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by erevos » Sun Apr 09, 2023 8:37 pm

Cypress wrote:
Mon Mar 27, 2023 11:39 pm
(100*stat('hitpoints'.accr)/stat('maxhp'.accr)>20)?(0):(x)
Hi @cypress! The life calc added by an aura, partially works. For example, when life drops below 20% the +X% damage is correctly applied. But When i recover health via a potion, the bonus to damage remains. Is this solvable?

User avatar
Cypress
Moderator
Champion of the Light
Posts: 446
Joined: Fri Dec 01, 2017 2:08 am

Re: v6b6/v10c Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by Cypress » Sun Apr 09, 2023 8:54 pm

Hi erevos, that is a flaw of auras. Auras will not update a stat value if it returns to 0. This is why crazy stats are applied via constantly updating passivestates and not aurastates: passivestates can return to 0, aurastates cannot. The closest you can get to 0 on fluctuating auras is -1 or +1.

User avatar
erevos
Hosted Forum Moderator
Paladin
Posts: 145
Joined: Sat Mar 05, 2005 7:41 am
Location: Crete
Greece

Re: v6b6/v10c Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by erevos » Sun Apr 09, 2023 9:58 pm

Cypress wrote:
Sun Apr 09, 2023 8:54 pm
Hi erevos, that is a flaw of auras. Auras will not update a stat value if it returns to 0. This is why crazy stats are applied via constantly updating passivestates and not aurastates: passivestates can return to 0, aurastates cannot. The closest you can get to 0 on fluctuating auras is -1 or +1.
Awesome, adding 1 solves it!

OrderOfTheScribble
Posts: 33
Joined: Wed Apr 05, 2023 7:35 pm
United States of America

Re: v6b6/v10c Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by OrderOfTheScribble » Mon Apr 10, 2023 9:27 pm

Cypress wrote:
Sun Apr 09, 2023 1:53 am
I figured out issue 3. Basemod's Charm Zone does not have identical behavior to the vanilla inventory. Namely, with the vanilla inventory, charms will be re-equipped on game start (and thus the aura will activate every time); in Basemod, charms in the Charm Zone will NOT activate their auras on starting a new game. This was patched with an admittedly awkward setup where you start with a Superstate Charm and Superstate Gem, where the Superstate Gem is (supposed to be) socketed into the Superstate Charm. For whatever reason, Basemod's Charm Zone does re-activate auras of charms, but only if the aura is given by a socketable of the charm.
When I first read that, it seemed odd to me since my testing was done with the charm zone disabled, but I've now been able to confirm that the Superstate Gem allows the aura to activate on startup and update crazy stats to or from 0. It would seem that BaseMod treats the entire inventory as the charm zone if the feature is disabled rather than letting the vanilla code handle it.

I found another bug in Modworked v10, and it has to do with set items. Whenever I equip a set weapon or shield, my skills levels start fluctuating every few frames until I replace it with an item of a different quality. From what I can tell, the bonus to all skills from superstates rotates between +1, +3, and -1 with a lack of any other +skills simply replacing the -1 with +0 (I guess that's from the min of +0 to all skills). In case it matters, the set items I was testing with are Cleglaw's Tooth (a set long sword I just found from Mephisto in Normal) and Cleglaw's Claw (a set shield I had found while testing v10b and placed in the shared stash before tonight's testing), both of which were generated in Modworked v10.

Edit: I have now tested crazy stats with the superstates gem, and they can now update to or from 0 with a delay of at most a few frames. Also, unique items don't cause +skills to fluctuate like sets do.

User avatar
Cypress
Moderator
Champion of the Light
Posts: 446
Joined: Fri Dec 01, 2017 2:08 am

Re: v6b6/v10c Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by Cypress » Tue Apr 11, 2023 1:24 am

v10d:
Fixed an allskills desync issue, thanks to OrderOfTheScribble.
Fixed various invalid references in Superstates.
Changed some names in uniqueitems.txt and armor.txt so that they match the item's actual name.
Added a framework for quickly applying stats of exact values to body armors, belts, gloves and helmets (previously, this only existed for boots, weapons and shields).


---

Thanks OrderOfTheScribble! That error was foolishness, I used the Value stat, to control the Superstates allskills synchronizer, figuring it was deprecated. It turns out it is not deprecated and does do something, as you found out. Now the synchronizer will use a custom stat to avoid unexpected behaviors.

But at least we now know what the hardcoded Value stat does:
If you have a Set equipped, gain +X Value, where X is the ID of that set in sets.txt. So:
Civerb's = +0 Value
Hsarus' = +1 Value
Cleglaw's = +2 Value
Iratha's = +3 Value
Isenhart's = +4 Value
etc
And Value isn't cumulative, so there is no difference between wearing one piece or all pieces of a set, you will get the same Value. Seems rather useless.

For the sake of understanding stats, I may add an indicator in a future version that won't completely break the game, something like the player character taking on a weird color if a seemingly deprecated stat changes its value. There are quite a few hardcoded stats that have no documented purpose, so it'd be nice to know what they all do.

OrderOfTheScribble
Posts: 33
Joined: Wed Apr 05, 2023 7:35 pm
United States of America

Re: v6b6/v10d Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by OrderOfTheScribble » Tue Apr 11, 2023 5:40 am

Cypress, thanks for expanding the item references! This should make the proficiencies idea I mentioned earlier easier to implement.
Cypress wrote:
Tue Apr 11, 2023 1:24 am
Thanks OrderOfTheScribble! That error was foolishness, I used the Value stat, to control the Superstates allskills synchronizer, figuring it was deprecated. It turns out it is not deprecated and does do something, as you found out. Now the synchronizer will use a custom stat to avoid unexpected behaviors.
Before pseudostats were a thing, I would always use "unused#" stats whenever I needed a stat that didn't exist in vanilla. I just assume any stat that doesn't say unused has a (theoretical) purpose, even if some of the stats don't work as intended (e.g. all those bytime stats).

P.S. In the ref skills, the boot and shield damages are backwards. The boot damages should be in the 'bmin' and 'bmax' asts, while the shield damages should be in the 'amin' and 'amax' asts since shields give the 'a' stat, while boots give the 'b' stat.

User avatar
Cypress
Moderator
Champion of the Light
Posts: 446
Joined: Fri Dec 01, 2017 2:08 am

Re: v6b6/v10d Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by Cypress » Fri Apr 14, 2023 2:18 am

Thanks yet again OrderOfTheScribble! That one is because of my terrible naming conventions, which I will fix. The next release will take a while and will hopefully include:

Poor Naming Conventions Fix (stats like 'a', 'b' and 'c' will be given actually descriptive names, like shieid, bootid and wepnum)
Add in a few ctc skills that I think are generally useful, such as: Softcoded Knockback, Softcoded Open Wounds (would allow for silly applications like ctc open wounds when struck, or for scaling open wounds damage).
A few additional references, like chance of a critical strike (rather complex since it involves 2 stats + param stats) and hireling ID.
Condition References, so that I don't keep making up new definitions of what unarmed or handedness is.
Allow Hirelings to use Superstates and crazy stats.
Will add in a few applications of Superstates, which I think are useful demonstrations or useful in general:
•weapon masteries that depend on what your hands are doing (single weapon mastery, dual-wielding mastery, one-handed mastery, two-handed mastery, etc)
•class-only pseudostats, to force equipment restrictions (so you can have items that are Necromancer Only via an item property, or items that are hireling only, or items that are Iron Wolf only, etc)
•aggressive item restriction pseudostats, so you could do something like a weapon that can only be equipped if you are not wielding gloves

User avatar
erevos
Hosted Forum Moderator
Paladin
Posts: 145
Joined: Sat Mar 05, 2005 7:41 am
Location: Crete
Greece

Re: v6b6/v10d Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by erevos » Sun Apr 16, 2023 12:55 pm

@Cypress i feel a bit stupid for not understanding because you are explaining things very detailed but im failing to understand how the superauras are beating the 0 issue with the auras.

Also, i've tested the montype affix, the fixed one from you and the expanded montype file with the items in it. Specific dmg from weapon types work, but damage to specific monster does not produce extra dmg.

User avatar
Cypress
Moderator
Champion of the Light
Posts: 446
Joined: Fri Dec 01, 2017 2:08 am

Re: v6b6/v10d Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by Cypress » Sun Apr 16, 2023 5:58 pm

v10e:
Fixed the incorrect boot/shield references, as described by OrderOfTheScribble
Fixed the montypes bug, as described by erevos
Fixed a bug where two-handed blocking weapons were being sold by vendors
Made more txt file row names match for weapons.txt, armor.txt, itemtypes.txt and automagic.txt
Fixed some of the poor naming conventions, so that some reference stats and skills have easier to understand names (for example, w is now wepid which is the weapon ID, c is now wepnum which is the number of weapons equipped, s is now strbon, which is the strength bonus)
Added some mostly unfinished and unused conditional references.

---

Hi erevos, don't feel that way! It's very confusing how Blizzard implemented some of the game's mechanics, and it isn't helped by my convoluted systems built around said mechanics.

The secret trick is that I barely use superauras, I use superpassives. My superaura1 has only one purpose: constantly update allskills. Every other stat in my system is being controlled by passivestates. Passivestates ignore the 0 issue because they can update to 0. The superaura I use in my system never uses the 0 value: it only alternates between -1 and +1 allskills. And then I have dozens of superpassives that are being constantly updated by that aura, that can freely update to any value desired, because passivestates can update to 0.

It may appear in-game that allskills are not fluctuating, but that is all part of the trick. The superaura gives -1 or +1 allskills (never equals 0), and one of the superpassives gives +2 or +0 allskills (+0 being valid because passives can update to 0). The net result is that allskills are fluctuating despite summing to +1 (+2-1=+1) or +1 (+1+0=+1), which constantly updates passives even though allskills appears to be static.

Let me know if any part of this doesn't make sense.


And thanks erevos! The montype affix bug was because I used identical montype names again. I'll fix that in the next version, which I'll release in a few minutes (the update will be a lot smaller than planned because I found some other annoying bugs too that need immediate fixing).

User avatar
erevos
Hosted Forum Moderator
Paladin
Posts: 145
Joined: Sat Mar 05, 2005 7:41 am
Location: Crete
Greece

Re: v6b6/v10e Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by erevos » Sun Apr 16, 2023 9:53 pm

Cypress wrote:
Sun Apr 16, 2023 5:58 pm

Hi erevos, don't feel that way! It's very confusing how Blizzard implemented some of the game's mechanics, and it isn't helped by my convoluted systems built around said mechanics.

The secret trick is that I barely use superauras, I use superpassives. My superaura1 has only one purpose: constantly update allskills. Every other stat in my system is being controlled by passivestates. Passivestates ignore the 0 issue because they can update to 0. The superaura I use in my system never uses the 0 value: it only alternates between -1 and +1 allskills. And then I have dozens of superpassives that are being constantly updated by that aura, that can freely update to any value desired, because passivestates can update to 0.

It may appear in-game that allskills are not fluctuating, but that is all part of the trick. The superaura gives -1 or +1 allskills (never equals 0), and one of the superpassives gives +2 or +0 allskills (+0 being valid because passives can update to 0). The net result is that allskills are fluctuating despite summing to +1 (+2-1=+1) or +1 (+1+0=+1), which constantly updates passives even though allskills appears to be static.

Let me know if any part of this doesn't make sense.

And thanks erevos! The montype affix bug was because I used identical montype names again. I'll fix that in the next version, which I'll release in a few minutes (the update will be a lot smaller than planned because I found some other annoying bugs too that need immediate fixing).
Thanks for understanding @cypress :)

Ok, i mean different stats, not allskills. For example lets say that life formula or any other stat, if i make it a passive and a second item gives bonus to it, it will be updated when i level up or on major events, using a passive.

User avatar
Cypress
Moderator
Champion of the Light
Posts: 446
Joined: Fri Dec 01, 2017 2:08 am

Re: v6b6/v10e Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by Cypress » Sun Apr 16, 2023 10:28 pm

Yes, that will work, as long as you are constantly updating the passive's skill level. I describe allskills because it's what makes the system work and update, but I could give any stats I want, changing according to any conditions that can be defined within Diablo 2. A stat bonus based on a life formula is definitely possible.

Note that another advantage of using passives is that you can apply parameters. So in theory, you could make stats like "+1% Chance to Reanimate as: Zombie, per 5 Energy" or "+10 to Paladin Skills if your life is under 10%" or "+3 to Poison Skills if your Poison Resistance is 0% or less" or even "+1 to Prayer, per 1% of Max Life Missing".

User avatar
erevos
Hosted Forum Moderator
Paladin
Posts: 145
Joined: Sat Mar 05, 2005 7:41 am
Location: Crete
Greece

Re: v6b6/v10e Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by erevos » Sun Apr 16, 2023 11:19 pm

@Cypress do ids supposed to be like this?
Attachments
ids.png

User avatar
Nagahaku
Junior Member
Paladin
Posts: 119
Joined: Sat Nov 30, 2019 1:11 am

Re: v6b6/v10e Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by Nagahaku » Wed Apr 19, 2023 5:31 pm

Cypress wrote:
Sun Mar 12, 2023 3:14 pm
References to shield damage, boot damage, weapon type, weapon handedness, strbonus, dexbonus and the number of weapons being wielded.
•Blocking for Two-Handed Weapons
will this fix the problem that if a 2 handed weapon with itemtype "shld" holding in hand, would be impossible to pickup an one handed weapons dropped?

User avatar
Cypress
Moderator
Champion of the Light
Posts: 446
Joined: Fri Dec 01, 2017 2:08 am

Re: v6b6/v10e Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by Cypress » Sat Apr 22, 2023 6:22 pm

Hi erevos, they aren't supposed to be like that, I was being lazy/forgot to synchronize IDs. It won't cause any issues since the ID columns are only used for reference, but I'll be sure to fix that. Thanks for the find!

Hello Nagahaku, thanks for the find! That is a very interesting problem. It seems that the game is confused since it thinks: (1) shield + no 1h weapon = pick up item and equip, but (2) equipped 2h weapon = cannot equip additional weapon. So the equip slot is already used, since there is a 2h weapon in the slot, so it cannot equip the 1h weapon, thus it is not picked up. There is a fix, but it is awkward: you have to equip a quiver (or something like a quiver). This can be easily seen if you equip a Blocking Short Bow: with a quiver, you can pick up 1h weapons; without a quiver, you cannot. Therefore, the easiest fix is to give every single 2h blocking weapon some random junk item to go with it that does nothing except occupy the second hand slot. I'll be sure to implement this quiver fix in the next version if I can't find any better fix. I found something better.

EDIT: Found a fix which is much better. Applying the shld type to weapons will be removed entirely. Instead, you will be able to equip blocking quivers to two-handed weapons. This system will be so much easier to use and so much less buggy:
(1) Does not require cloning every single weapon as a blocking version, so you won't have to manually synchronize the non-blocking and blocking weapon settings
(2) Bonuses to specific weapon's damage will now apply to blocking weapons (i.e. if you made a weapon mastery specifically for Large Axes, it would not apply to Blocking Large Axes unless you went through a lot of effort)
(3) Significantly reduces row space waste, no longer need to add in hundreds of new weapons.txt and itemtypes.txt rows
(4) Removes the bug that sets blocking weapon damage to 0 unless you have a source of +dmg% on the weapon
(5) No longer have to worry about classifying between block and non-block weapons, no longer have to worry about monsters dropping blocking weapons even if you don't want them to, no longer have to worry about the cube producing blocking weapons even if you don't want them to.
(6) The bug you described will no longer apply, since now both hand slots will be occupied, thus the game will not think a one-handed weapon can be picked up and equipped.
(7) As far as I can tell, this new system does everything the old one does but better

EDIT 2: Okay, this new system isn't as good as I hoped. The main issue is that Barbarians cannot block with two-handed swords, since equipping the blocking quiver will make the two-handed sword be equipped as one-handed. So, specifically for two-handed swords, you'd have to create special blocking versions (i.e. blocking 2h swords can only be equipped as 2h: 1or2handed=0), while every other 2h weapon can be used properly with the blocking quiver. Still better than the old way, since it gets rid of all the janky bugs.

User avatar
Nagahaku
Junior Member
Paladin
Posts: 119
Joined: Sat Nov 30, 2019 1:11 am

Re: v6b6/v10e Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by Nagahaku » Sun Apr 23, 2023 3:01 pm

thank you, that's very helpful, I'll try your instructions @Cypress :D

OrderOfTheScribble
Posts: 33
Joined: Wed Apr 05, 2023 7:35 pm
United States of America

Re: v6b6/v10e Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by OrderOfTheScribble » Mon Apr 24, 2023 7:05 am

I just noticed some unusual behavior with Werewolf and the superstates charm with the superstates gem. Apparently, attacks in Werewolf form are about 50% faster with the superstates charm equipped. Here's how I tested that:
  • For this test, I used a large axe with 10% IAS and no other sources of IAS. The superstates charm adds +1 to all skills, and I have only 1 hard point into Werewolf, so the test was done at slvl 2.
  • I have a modified version of Werewolf, which adds 23% skill IAS at level 2, so to get the right attack speed, I entered level 4 Fanaticism into this calculator to determine the attack speed.
  • The calculator says an attack should take 14 frames in Werewolf form.
  • When I stashed the superstates charm and equipped a pelt with +1 to Werewolf, I got the expected attack speed.
  • When I equipped the superstates charm and stashed the pelt, my attacks were much faster. I'd say it was either 9 or 10 frames.
I also played a Werewolf Druid in Modworked v10b, which had superstates without the gem, and I wasn't getting unusually fast attacks, so I'm guessing it has something to do with the gem. From looking at the calculator, attacks with Werewolf take 50% more frames with a WSM 0 weapon, assuming no IAS. My guess is that the superstates as implemented in v10c or later are somehow causing the game to ignore this penalty without affecting the rest of the attack speed calculation.

User avatar
Cypress
Moderator
Champion of the Light
Posts: 446
Joined: Fri Dec 01, 2017 2:08 am

Re: v6b6/v10e Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by Cypress » Tue Apr 25, 2023 2:24 am

Thanks for finding and testing that, OrderOfTheScribble! That's a tough one. The biggest problem is that I have no idea how transformation state attack speed works, and I'm not sure if there are any calculators that accurately describe it. What I've learned from my testing is that:
•The bug occurs because of the passive skill updater. It seems to occur even on the old style charm.
•It doesn't matter what transformed state you have: werewolf, werebear, skeleton, no gfxtype, it all has the same bugged speed bonus while wielding the passive skill updater (or rather, it seems that the weird speed penalty of being transformed is removed with the passive skill updater).
•The speed bonus given by the passive skill updater seems to be equivalent to IAS, not WIAS, meaning that the passive skill updater's bonus is irrelevant if you reach the non-WIAS speed cap (transformed characters have a limited and penalized IAS cap, but no WIAS cap). Although note that my test of this was extreme: I gave a werebear druid a -466 and -467 WIAS weapon, where the -466 WIAS weapon reached 2 frames per attack both with and without the charm, and -467 WIAS weapon reached 1 frame per attack both with and without the charm.


The way to fix this is to give transformation states some stat so that they can be referenced, and then apply a hidden IAS penalty when you are transformed, such that the penalty is equivalent to the bonus given by the passive skill updater, cancelling the two out. The problem is that I have no idea what this penalty's value would need to be, and I don't have any good ways of testing it. It could also be far more complicated, perhaps depending on things like animrate values, thus requiring different adjustment factors depending on the given transformation state.

I'm almost tempted to let this bug live, since seems nearly equivalent to D2R's buffed wereforms, which had the speed penalty removed at low speeds, and the unlimited WIAS retained at high speeds. Although I mostly say this because I hate the idea of trying to derive some hidden value by scrutinizing recordings of exact animation frames and relationships between various IAS related variables. It would very much help if there was a guide on how transformation attack frames worked exactly.

EDIT: Never mind, a simple stat adjustment will not suffice. A werebear with capped non-WIAS attacks faster while wielding the charm than without it. So perhaps it would require an adjustment to be made to animdata directly.

EDIT 2: I re-read your post and now I'm even more confused. You are correct: for some reason, the 10b charm is not speeding up transformations, yet the new one is, even though the mechanism is basically identical (the only difference I can think of is that the old charm used the 'value' stat to increment the skill updater timer, and the new charm uses the 'timer' stat). I have no idea what's going on now.

EDIT 3: Never mind, the 10b charm is bugged too. The bug occurs inconsistently since skills are not updating every frame, so if an attack happens to start on an updating frame, then it will attack faster, and if it isn't on an updating frame, then the attack will occur at vanilla speed.

EDIT 4: I don't know what to think anymore, nothing makes sense. Now it seems that shapeshifted characters have semi-randomized attack speed: without the charm equipped, my character is randomly attacking faster or slower with no apparent relation to anything. But that is completely unrelated to the bug, which is now known and due to a very silly mistake: UpdateAnimRate is accidentally set to TRUE for the 'timer' stat, because I put in a "comment" that is treated as a value. Apparently this results in the weird transformation speed penalty being removed. I'm very happy that this happened, since this is an incredibly useful mistake that has utility in mods (i.e. modders can set UpdateAnimRate=1 to the 'timer' stat to apparently remove the transformation penalties, enabling D2R-style transformation states). Of course, I will disable it in the next version, and also remove every single attempted "comment" scattered across itemstatcost.txt and skills.txt. Thanks a ton for bug testing this OrderOfTheScribble, I never would have figured it out otherwise.

This also makes me wonder if maybe this isn't a bug at all, but rather that the speed penalty to shapeshifting is an unintended bug that was accidentally fixed. Regardless, I'll assume the speed penalty is intended unless it is proven otherwise.

User avatar
Nagahaku
Junior Member
Paladin
Posts: 119
Joined: Sat Nov 30, 2019 1:11 am

Re: v6b6/v10e Overworked/Modworked 1.13c Txt Files: Bug Fixes, Descriptions and Modding Support

Post by Nagahaku » Tue Apr 25, 2023 2:44 pm

Cypress wrote:
Sat Apr 22, 2023 6:22 pm
EDIT 2: Okay, this new system isn't as good as I hoped. The main issue is that Barbarians cannot block with two-handed swords, since equipping the blocking quiver will make the two-handed sword be equipped as one-handed. So, specifically for two-handed swords, you'd have to create special blocking versions (i.e. blocking 2h swords can only be equipped as 2h: 1or2handed=0), while every other 2h weapon can be used properly with the blocking quiver. Still better than the old way, since it gets rid of all the janky bugs.
Firstly, I have an idea to deal with bar's 2 handed swords: make all old 2 handed swords totally 2 handed by using quiver method, then create some "bar only" 1 handed swords with original 2 ones' 1 handed damage, and give them itemtype of "shld", the new swords can only be equiped by bars and since they're 1 handed there would not be a pick up bug, they can block, and they work like 1 handed swords but with 2 handed ones' shape in bar's hands.
And another problem appeared... with the quiver method, 2 handed weapons cannot attack without a quiver. any idea to get rid of that?

Post Reply

Return to “Member Аnnouncements”