Sync dev with upstream (2026-09-12) - #11
Merged
Merged
Conversation
* Export 0.5.5 data + trade data * Fix soulcore tests * Regen modcache and silence cspell * Fix .def Texture being local * Clanker fix for asset export * Fix spectre library icons * Fix random passing by bug * Swap emotion column order
* Add individual skill weapon set handling Allow skill groups to use Both, Set 1, or Set 2. Calculate skills, effects, and stats using the assigned weapon set. Add logic to auto apply / disable weapon sets if a skill can't be used with it Make item and tree granted skills into supportable groups that lock the skill so it can't be removed. Hide item/tree only gems from the dropdown list due to them having proper groups now. Added a bunch of tests and tried to make sure there weren't any obvious performance issues * Fix imported levels of item / tree granted skills Skills granted via tree nodes have their level scaled based on your characters level so should level up or down Skills granted via items will set a maximum base level based on the item and will auto downscale based on if you meet the stat requirement and level requirement * Fix import not validating weapon set selection * Fix level not syncing When levelling up your character, it was not updating the level of tree granted skills until you caused the socket group UI to refresh * Fix minion skills not showing the stat set dropdown sometimes When you set a minion to use weapon set 2 but had weapon set 1 active then it was hiding the skill set dropdowns in the sidebar and calcs tab * Auto grant default attacks for weapons Use the CharacterMeleeSkills table to set the default skill that should be added based on the current equipped weapons Auto level the skills based on the player level Spear Throw on weapons is just display text so make it not add a gem as that's handled by the dat file Add tests for a variety of scenarios * Fix compare not using the item set the skill is assigned to When comparing a weapon for a skill, it could show no difference if you were on set 1 while the skill was set to use only set 2 It now uses the set the skill is set to * Fix test * Fix tests * Fixes Fixes an issue with spear imports Fixes an issue with weapon set 2 jewel tooltips Cleans up some tests * Fix compare tab crash --------- Co-authored-by: LocalIdentity <localidentity2@gmail.com>
* Add more Atziri's Splendour variants * Update mod ids for a bunch of uniques * Regen modcache * Fix a bunch of mod IDs which change values * Use alt variant for splendour instead * Add groups for splendour * Use full names for variants * Fix a ton more mod ids * Fix some missing mods * Update modcache * Add attribute line for vertex * Fix intimidate shield block mod ID * Fix tests --------- Co-authored-by: LocalIdentity <localidentity2@gmail.com>
* Optimise tree rendering: - Batch SG calls - Use strings for colours - Cull out of view connectors * Avoid unpacking in node code and recalculating constants * Fix colours * Fix 0.1 Tree crash Switching to the 0.1 tree from 0.5 would cause a crash due to asset differences --------- Co-authored-by: LocalIdentity <localidentity2@gmail.com>
* Add "Can roll ___" mods to crafter * Fix some mods applying to invalid bases Fix missing rune modifiers for helmets and weapons, and exclude modifiers that cannot roll on the item’s base --------- Co-authored-by: LocalIdentity <localidentity2@gmail.com>
…nity#2516) The 'enemies in your presence have exposure' entry placed its ActorCondition tag on the OUTER EnemyModifier mod. That mod lives in the player's modDB, where actor="enemy" resolves to the enemy actor - but EnemyInPresence is only ever set on the PLAYER (CalcPerform.lua:526). The condition therefore never held, the EnemyModifier was never created, and the Shaman ascendancy notable Turning of the Seasons granted nothing. Moved the tag inside the elemental mod, matching the already-correct 'enemies in your presence have fire exposure' entry a few lines below: the inner mod is copied into the enemy's modDB, where actor="enemy" points back at the player, who does have the condition. Verified on a Druid/Shaman build with node 62523 allocated: Fire/Cold/Lightning Exposure 0/0/0 -> 20/20/20. On a real build (Flicker Strike, Druid/Shaman L85) this is 238,456 -> 264,437 DPS (+10.9%). ModCache.lua regenerated; exactly one line differs. Co-authored-by: Visp1024 <visp1024@users.noreply.github.com>
…nity#2514) composeNode() walked node.attrib with pairs(), so attributes came out in string-hash order and the same tree could serialise differently between processes. Collect the keys, sort them, then emit. The non-string-key check moves into the collecting loop because table.sort cannot compare a string key against a non-string one; both error messages are unchanged.
PartyTab:exportBuffs walked the name-keyed buffExports maps, and the nested otherEffects map, with pairs(), so the text inside each <ExportedBuffs> element came out in string-hash order and differed between runs of the same build. Use pairsSortByKey for both walks.
…ldingCommunity#2513) * Save builds with a stable element order The XML save path walked several maps with pairs(): calcs/config inputs and placeholders, item slots, saver sections, weapon-set node lists, and the node-id-keyed allocNodes, masterySelections, jewels, attribute nodes and hashOverrides in PassiveSpec. Their emission order was hash order, so the same build could save differently between runs. Sort each walk (names ascending, node ids ascending, slots in creation order, weapon sets by number) so a build always serialises the same way. EncodeURL also walks allocNodes ascending, so the nodeCount < 255 cap drops the same nodes every time. Loaders read all of these back as maps, so this is a pure reordering. * Iterate runes with ipairs --------- Co-authored-by: LocalIdentity <localidentity2@gmail.com>
* Iterate flasks and charms in slot order env.flasks and env.charms are keyed by item table, so pairs() walks them in memory-address order, which differs between processes. That order reaches the modDB and, for charms, the limit loop stops early, so it also decided which charms applied. CalcSetup now records each slotted item's slot number in env.itemSlotIndex, and mergeFlasks/mergeCharms iterate in that order with item.id as the tiebreak. * Fix duplicate charms changing slot order --------- Co-authored-by: LocalIdentity <localidentity2@gmail.com>
…mmunity#2511) * Add support for Runeforged/mastered unique variants * Fix mods not checking the selected base Mods were not checking if the base and variant matched and were just applying all the mods for a particular base --------- Co-authored-by: LocalIdentity <localidentity2@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Merge 14 upstream commits (
49e93925d..ce566eac4): 0.5.5 data export, trade data update, individual skill weapon set handling, tree tab performance, deterministic XML save order, unique variant/crafter additions, and a ModCache regen.macOS port verification
Clean merge, no conflicts. No forward-porting was needed.
git diff --name-only <pre-merge> HEADdoes not list any fork-patched file, so upstream touched none of them.src/Launch.lua— thejit.os == "OSX"JIT-disable block is present and unchanged.src/Classes/TradeQuery.lua— fork delta unchanged.src/Classes/TradeQueryRequests.lua— thepseudoModLinenil-crash guard is present. The second marked delta (the dropped{fractured}/{crafted}prefix inprocessLine) is now a stale signature: upstream's ownprocessLinereturnss .. escapeGGGString(modLine.description), so the fix is upstream and the fork no longer needs to carry it.Testing
bustedis not installed locally, so the test gate is CI (run_tests,check_modcache,spellcheck).