Jump to content

Lindor's Mod for Sacred 2 EE development Thread


Lindor

Beta version yes or no?  

1 member has voted

  1. 1. Should i publish an early test version of my unfinished mod?

    • Yes, I want to participate in playtesting.
      0
    • Generally I'd like a Beta version, but if it's really so unfinished yet, you should work on it a little bit more first.
      1
    • No, don't publish until it's perfect.
      0


Recommended Posts

I have completed but not finished the Standard Armor Set classification:

Spoiler
local classification = {
    Dryad = {
        AspectOne = {"Ivy"},
        AspectTwo = {"Leafs"},
        AspectThree = {"Crystal"},
        Generic = {"Special", "Generic"},
        Melee = {"Iron"},
        Ranged = {"Leather", "Cloth"},
        Spell = {"Magic"},
    },
    Seraphim = {
        AspectOne = {"Angel Dust"},
        AspectTwo = {"Ancient"},
        AspectThree = {"Mystique"},
        Generic = {"Special", "Generic", "Cloth"},
        Melee = {"Iron", "Sophia"},
        Ranged = {"Leather"},
        Spell = {"Magic", "Genesis"},
    },
    Shadow Warrior = {
        AspectOne = {"Enforcer"},
        AspectTwo = {"Exxo"},
        AspectThree = {"Crypt"},
        Generic = {"Special", "Cloth", "Generic"},
        Melee = {"Iron", "Leather"},
        Ranged = {"Redstorm", "Colossus"},
        Spell = {"Magic", "Scourge of Lordaeron", "Hellknight"},
    },
    High Elf = {
        AspectOne = {"Pearl"},
        AspectTwo = {"Diamond"},
        AspectThree = {"Raven"},
        Generic = {"Special", "Cloth", "Generic", "Lara's Glad Rags"},
        Melee = {"Iron", "Children of Asha"},
        Ranged = {"Range Array"},
        Spell = {"Magic", "Leather"},
    },
    Inquisitor = {
        AspectOne = {"Blood Poison"},
        AspectTwo = {"Scourge"},
        AspectThree = {"Armageddon"},
        Generic = {"Special"}
        Melee = {"Generic", "Judicator"},
        Ranged = {"Iron", "Leather"},
        Spell = {"Magic", "Cloth", "Disgraced Gods"},
    },
    Temple Guardian = {
        AspectOne = {"Punisher"},
        AspectTwo = {"Iron Will"},
        AspectThree = {"T-Wolf"},
        Generic = {"Special", "Generic"},
        Melee = {"Iron"},
        Ranged = {"Cloth"},
        Spell = {"Magic", "Leather"},
    },
    Dragon Mage = {
        AspectOne = {"Dragon Magic"},
        AspectTwo = {"Commander"},
        AspectThree = {"Special"},
        Generic = {"Iron", "Generic"},
        Melee = {"Kha-Beleth"},
        Ranged = {"Magic"},
        Spell = {"Cloth", "Leather"},
    },
}

 

The classification is, other than the Aspect and Mutation Set Classification, completely subjective. I just looked at the armor and thought "oh that looks like ranged". Can be modified later by modders.

 

I plan to extract the data from the model name used in itemtype.txt, and then add the flag to each item which uses this specific itemtype. Because flag-conflict might occur, I thought about a usagebits-style flag, but with base 7 and not base 2.

Link to comment
2 hours ago, Lindor said:

I plan to extract the data from the model name used in itemtype.txt

Aaaand Done! Only need to implement the flags system, and all the pieces necessary for the automated bonusgroup generation are there. As far as I can tell, there are 2024 distinct single hero weargroup itemtypes for non-set/unique/legendary armor.

@gogoblender Is it okay if I keep you informed of the progress here? I know other forums where this might be seen as spam.

Edited by Lindor
  • Appreciation 1
Link to comment
8 minutes ago, Lindor said:

Aaaand Done! Only need to implement the flags system, and all the pieces necessary for the automated bonusgroup generation are there. As far as I can tell, there are 2024 distinct single hero weargroup itemtypes for non-set/unique/legendary armor.

@gogoblender Is it okay if I keep you informed of the progress here? I know other forums where this might be seen as spam.

No worries! You're creating a roadmap of progress.

and around here, stuff lasts a loooooong time

:lindor:

gogo

  • Like! 1
Link to comment
55 minutes ago, Lindor said:

Only need to implement the flags system

There we go:

Spoiler
local armor = {}
local newItem = {}

newItem = {
    id = 1282,
    name = "hero_chest_strap_fight_magic",
    classificationbits = 6603152
    dmgvariation = 0,
    minconstraints = 5,
    allotment_pmfpi = {1000, 0, 0, 0, 0}, 
    bonusgroup0 = {601, 1000, 1, 9, 0}, 
    bonusgroup1 = {600, 1000, 1, 5, 0}, 
    bonusgroup2 = {599, 1000, 1, 2, 0}, 
    itemtypes = {6781, 8005, 8453, 8582, 9170, 9214, 10056, 10395, 10601, 10607, 12553}, 
    wearergroups = {"WEARGROUP_SERAPHIM", "WEARGROUP_DRYADIN", "WEARGROUP_CENTURIO", "WEARGROUP_TEMPLEGUARDIAN", "WEARGROUP_HIGHELVE", "WEARGROUP_DRAGONMAGE"}
}
do armor[1282] = newItem end

newItem = {
    id = 1283,
    name = "hero_chest_strap_fight_normal",
    classificationbits = 6663453
    dmgvariation = 0,
    minconstraints = 1,
    allotment_pmfpi = {1000, 0, 0, 0, 0}, 
    bonusgroup0 = {601, 900, 1, 9, 0}, 
    bonusgroup1 = {600, 900, 1, 5, 0}, 
    bonusgroup2 = {599, 900, 1, 2, 0}, 
    itemtypes = {3642, 4569, 5667, 6273, 7958, 8452, 8581, 9213, 12289, 12552}, 
    wearergroups = {"WEARGROUP_DRYADIN", "WEARGROUP_CENTURIO", "WEARGROUP_TEMPLEGUARDIAN", "WEARGROUP_HIGHELVE", "WEARGROUP_DRAGONMAGE"}
}
do armor[1283] = newItem end

newItem = {
    id = 1284,
    name = "hero_chest_strap_fight_rare",
    classificationbits = 2343152
    dmgvariation = 0,
    minconstraints = 9,
    allotment_pmfpi = {1000, 0, 0, 0, 0}, 
    bonusgroup0 = {601, 1100, 1, 9, 0}, 
    bonusgroup1 = {600, 1100, 1, 5, 0}, 
    bonusgroup2 = {615, 1100, 1, 2, 0}, 
    bonusgroup3 = {750, 1000, 45, 9, 1}, 
    itemtypes = {8580, 9171, 9172, 10057, 10058, 10396, 10417, 10608, 12782, 12783, 12806, 13464, 13471, 13478}, 
    wearergroups = {"WEARGROUP_SERAPHIM", "WEARGROUP_DRYADIN", "WEARGROUP_CENTURIO", "WEARGROUP_TEMPLEGUARDIAN", "WEARGROUP_HIGHELVE", "WEARGROUP_DRAGONMAGE"}
}
do armor[1284] = newItem end

(.....)

 

The classificationbits are in same order as usagebits. They're NOT converted into decimal, so each digit stands for a hero. This is what the digits mean:

local classificationOrder = {
    AspectOne = 0,
    AspectTwo = 1,
    AspectThree = 2,
    Generic = 3,
    Melee = 4,
    Ranged = 5,
    Spell = 6,
}

Only issue is when one armor has multiple itemtypes with different classifications for the same hero. It's possible to set in balance.lua that each item is created once for each itemtype and disable usagebits though (it's either usagebits or once for each itemtype). I may consider to implement classification directly at the main logic in blueprint.txt. If you choose to use the single itemtype option, then the classification conflict will get solved as well.

Link to comment

The classification conflict happens indeed quite often even within single weargroup items. E.G.:

"hero_wings_technic_normal" has two "leather" itemtypes which I classified as "ranged" and one "special" itemtype which I classified as "generic".

Link to comment
On 7/12/2022 at 10:35 PM, Lindor said:

Hmmm my idea would be:

for each instance of a bonus used, e.g. for each token of each spell in spells.txt, I'm gonna backtrace to the bonus in blueprint.txt, then multiply the bonus strength of the spell token with the highest difficultyvaluerange value of the bonus, divide it by the new highest difficultyvaluerange value, e.g. 100 if I use above normalization, round it to the next integer and then overwrite the old value with the new one.

If I apply this idea, this happens:

Spoiler
(.....)
do bonusTypeBalance["BONUS_ADDCA_HORSE"] = {6, 6, 7, 7, 7, 8, 8, 8, 9, 9, 9, 1, 1, 1, 1, 1, } end
do bonusTypeBalance["BONUS_COMBATVALUE"] = {1, 1, 1, 2, 2, 2, 3, 3, 3, 3, 4, 4, 4, 5, 5, 5, } end
do bonusTypeBalance["BONUS_AREARADIUS"] = {33159504139384, 32141449187817, 31123394236251, 30105339284684, 29087284333117, 28069229381551, 27051174429984, 26033119478417, 25015064526851, 23997009575284, 22978954623717, 21960899672151, 20942844720584, 19924789769017, 18906734817451, 17888679865884, } end
(.....)

 

Ridiculous numbers. Additionally comes the problem that bonusstrength at the blueprint's bonusgroup applies to the whole bonusgroup, making different difficultyvalueranges mandatory.

I will not apply a normalized difficultyvaluerange, instead I will apply a normalized bonusstrength and change the difficultyvaluerange at the bonus for keeping the balance.

 

As a side note: I have no idea why the BONUS_ADDCA_HORSE balance first in- and then decreases. It should be a linear function.

 

EDIT: I know what happened. It was a bug in the code. Nevertheless the problem with the strength applying for all boni in the bonusgroup still holds true, which is why I'll go with the normalized bonusstrength idea.

EDIT2: I just realized that if I did this, I'd sacrifice bonus scaling with item tier. It's the way the system works: Either have scaling with tier or have correct values or have only single bonus bonusgroups. I don't know if and how this is resolvable. Uhmmm... help?

Edited by Lindor
Link to comment
6 hours ago, Lindor said:

I just realized that if I did this, I'd sacrifice bonus scaling with item tier. It's the way the system works: Either have scaling with tier or have correct values or have only single bonus bonusgroups. I don't know if and how this is resolvable. Uhmmm... help?

I managed to solve the problem!:woot:

The solution is again: linear interpolation!
Here's how it works: I implemented scaling with item tier directly in balance.lua:

Spoiler
    --This is just for scaling with tier. The absolute value doesn't matter. Remember there are 15 item tiers.
    --strength at item tier 1, increase per item tier
    bonusstrength = {1000, 71.4285714286},

These are the values used for ALL bonusgroups, the balance is kept via manipulation of difficultyvaluerange. For each difficulty, the extracted linear bonusstrength function of the item tier is multiplied with the old difficultyvaluerange to get the desired funtion.

Then I modify the difficultyvaluerange so that, when I multiply it with the new linear bonusstrength function of item tier as set in balance.lua and afterwards add the difference between these two function for all item tiers to get the total amount of error, this error equals zero.

 

 

The end result may be a little bit too high/low for low item tiers and too low/high for high item tiers, but the average is the same as the old mod's balance. I'd even argue that it improves the balance as it keeps consistency. And it gives the modder the ability to modify scaling with item tier for all boni with a single number change!

Here's a little snippet of the end result for EE with above settings for bonusstrength:

Spoiler
local bonusTypeBalance = {}
do bonusTypeBalance["BONUS_DEEPWOUND"] = {
    difficultyvaluerange0 = {0, 15, 38},
    difficultyvaluerange1 = {1, 22, 49},
    difficultyvaluerange2 = {2, 29, 59},
    difficultyvaluerange3 = {3, 36, 69},
    difficultyvaluerange4 = {4, 44, 79},
} end
do bonusTypeBalance["BONUS_SUREHIT"] = {
    difficultyvaluerange0 = {0, 18, 36},
    difficultyvaluerange1 = {1, 24, 49},
    difficultyvaluerange2 = {2, 31, 62},
    difficultyvaluerange3 = {3, 37, 74},
    difficultyvaluerange4 = {4, 44, 87},
} end
do bonusTypeBalance["BONUS_LIGHTRANGE"] = {
    difficultyvaluerange0 = {0, 27, 80},
    difficultyvaluerange1 = {1, 38, 111},
    difficultyvaluerange2 = {2, 48, 142},
    difficultyvaluerange3 = {3, 58, 173},
    difficultyvaluerange4 = {4, 69, 204},
} end
(.....)

 

  • Like! 1
Link to comment
1 hour ago, Flix said:

How will you handle item classifications in typification.txt calling on certain bonusgroups?

Wait what do the classifications have tod do with bonusgroups? Do you mean like, if it's CLF_DEFAULT, the correct classification is derived by bonusgroups? If that is so, I wasn't aware of that.

 

I plan a hybrid classification system for weapons: As first instance, it is looked for certain strings present in the item name, like "pole" or "bow" e.g. This half is already completed. If that's inconclusive, it is looked at the Families and Subfamilies of the itemtype. This half is not yet completed.

Theoretically I could advance this system into an automated classifications system. Classifications can always be derived from these three parameters I hope? I have all the possible classifications from the .dll data dump thread.

 

EDIT: Oh I see it's done through typification.txt. With this data, I can correct the classification automatically upon running Enable.exe.

 

EDIT2: Wait you mean the bonusgroup being called by the classification, not the classification being called by the bonusgroup right? Well that's easy to fix then, just change all bonusgroup IDs in typification.txt to 0 upon enabling. When such an amount of confusion happens, it's time to go to sleep. Good night :yawn:

Edited by Lindor
Link to comment
On 7/15/2022 at 12:22 AM, Lindor said:

I plan a hybrid classification system for weapons: As first instance, it is looked for certain strings present in the item name, like "pole" or "bow" e.g. This half is already completed. If that's inconclusive, it is looked at the Families and Subfamilies of the itemtype. This half is not yet completed.

The classification system is up and running, both for weapon and armor. I made it so that it's looked at weargroup and modelname for armor itemtypes to get the standard armor set of the itemtype, and it's looked for both blueprint name and itemtype subfam and only if both classifications match, the itemtype is classified. There is a warning displayed if they don't match.

Btw the Itemtype-Weargroup-Relation works by looking both at itemtype and model weargroup. It's a complicated logic, and I think it's very stable.

 

On 7/13/2022 at 7:56 PM, Lindor said:

I have completed but not finished the Standard Armor Set classification:

  Reveal hidden contents
local classification = {
    Dryad = {
        AspectOne = {"Ivy"},
        AspectTwo = {"Leafs"},
        AspectThree = {"Crystal"},
        Generic = {"Special", "Generic"},
        Melee = {"Iron"},
        Ranged = {"Leather", "Cloth"},
        Spell = {"Magic"},
    },
    Seraphim = {
        AspectOne = {"Angel Dust"},
        AspectTwo = {"Ancient"},
        AspectThree = {"Mystique"},
        Generic = {"Special", "Generic", "Cloth"},
        Melee = {"Iron", "Sophia"},
        Ranged = {"Leather"},
        Spell = {"Magic", "Genesis"},
    },
    Shadow Warrior = {
        AspectOne = {"Enforcer"},
        AspectTwo = {"Exxo"},
        AspectThree = {"Crypt"},
        Generic = {"Special", "Cloth", "Generic"},
        Melee = {"Iron", "Leather"},
        Ranged = {"Redstorm", "Colossus"},
        Spell = {"Magic", "Scourge of Lordaeron", "Hellknight"},
    },
    High Elf = {
        AspectOne = {"Pearl"},
        AspectTwo = {"Diamond"},
        AspectThree = {"Raven"},
        Generic = {"Special", "Cloth", "Generic", "Lara's Glad Rags"},
        Melee = {"Iron", "Children of Asha"},
        Ranged = {"Range Array"},
        Spell = {"Magic", "Leather"},
    },
    Inquisitor = {
        AspectOne = {"Blood Poison"},
        AspectTwo = {"Scourge"},
        AspectThree = {"Armageddon"},
        Generic = {"Special"}
        Melee = {"Generic", "Judicator"},
        Ranged = {"Iron", "Leather"},
        Spell = {"Magic", "Cloth", "Disgraced Gods"},
    },
    Temple Guardian = {
        AspectOne = {"Punisher"},
        AspectTwo = {"Iron Will"},
        AspectThree = {"T-Wolf"},
        Generic = {"Special", "Generic"},
        Melee = {"Iron"},
        Ranged = {"Cloth"},
        Spell = {"Magic", "Leather"},
    },
    Dragon Mage = {
        AspectOne = {"Dragon Magic"},
        AspectTwo = {"Commander"},
        AspectThree = {"Special"},
        Generic = {"Iron", "Generic"},
        Melee = {"Kha-Beleth"},
        Ranged = {"Magic"},
        Spell = {"Cloth", "Leather"},
    },
}

 

The classification is, other than the Aspect and Mutation Set Classification, completely subjective. I just looked at the armor and thought "oh that looks like ranged". Can be modified later by modders.

 

I plan to extract the data from the model name used in itemtype.txt, and then add the flag to each item which uses this specific itemtype. Because flag-conflict might occur, I thought about a usagebits-style flag, but with base 7 and not base 2.

This system is hereby deprecated (the armor set classification is still used though). However I got some useful information out of it: The armors match their purpose for all heroes very rarely. Chaos like this is the most common:

    name = "hero_chest_strap_fight_rare",
    classificationbits = "2343152",

So for an armor set, if it is e.g. Aspect one for Seraphim, one can guarantee that the same armor set has a completely different purpose for another hero.

like e.g. the same item is part of scourge set of inquisitor which is aspect three and part of angeldust set of seraphim which is aspect one. If it's just aspects it would be kinda okay, but there are also items which are spell for one hero and melee for another.

This is very bad because, in case you decide to go with the usagebits-option and not make every item single itemtype, I can't give the armorsets useful boni based on their purpose like that. So if you use usagebits, pretty much every armor with automated bonusgroup generation will either have the ability to spawn every bonus available for the hero on armors, or only general-purpose boni like defensive stuff, depending on your settings in balance.lua.

 

@dimitrius154@FlixIs it possible to get the hero you're currently playing and load this information into blueprint.txt before blueprint.txt is being executed during the server loading stage? If so, I can solve the problem.

Edited by Lindor
  • Like! 1
Link to comment

I think I have to make a pause. The whole day I was feeling out of mental energy, don't know what is with me but at least it's not covid. Just feeling sry because I know Flix wanted to release EE at the end of this month, but I don't know wether I can hold that date for the bonus/item work reshuffle.

However it should be ready at least till the end of august, because I will have very limited time afterwards. It kinda sets a little pressure on me.

  • Appreciation 1
Link to comment

There is absolutely no rush. I'm not sure even to what extent I will bring in your changes, use it as a new base, or just let it be a standalone addition to EE.  The next EE is basically done, consisting mostly of all the bugfixes that have already been seen in D2F and PFP.  Right now I'm just leisurely working on the all the localizations (two restored quests need their text restored for all languages, X2 for Alt. Spells).

Generally I have a feeling of "winding down" for now.  I'm spending most of my free time playing Grim Dawn the past 2 weeks.

  • Appreciation 1
Link to comment

I continued working on it a little bit. Not with the same intensity as before, but there's progress being made.

Today I made it so that item modifier which are modified by a relevant skill cannot spawn unmodified on items. Relevant skills are basically all possible modifying skills except alchemist and horseman. I'm debating with myself wether I want to exclude skill_armorer_apprentice (blacksmithing) as well.

Only automated bonusgroup generation is affected by this, items with static boni remain as they are.

I might consider setting up a blacklist for balance.lua so the modder can choose.

  • Like! 1
Link to comment

I really really strongly dislike the base game's dual wield mechanic. It doesn't make any sense at all that you cannot use a single sword properly without cutting yourself, but as soon as you hold a second sword you transform into Torii Mototada!

If I'm ever getting up to a Dmitriy-level of assembly skills, I'm gonna remove the dual-wield skill entirely together with the need for it to unlock the ability to dual wield, this will be unlocked from the very beginning.

 

Right now it's getting me headache because the boni chosen for a weapon are dependent on the weapon type only. There is no intrinsic dual wield weapon. I cannot unlock boni modified by offhandlore so easily without breaking everything.

Therefore offhand weapon lore will be added to above blacklist by default. If you enable it, those boni which are modified by dual wield will never be able to spawn anywhere, neither modified by dual wield nor unmodified. By disabling, at least the unmodified version can appear.

Link to comment
12 minutes ago, Lindor said:

I really really strongly dislike the base game's dual wield mechanic. It doesn't make any sense at all that you cannot use a single sword properly without cutting yourself, but as soon as you hold a second sword you transform into Torii Mototada!

 

 

 

big lol... had to look it up, but worth it to see who Torii is ... alas, this games coding right?  here's to endless nights but some future coming satisfaction with your +1 increase to all assembly skills 

:)

 

gogo

Link to comment

Some information to this mod outside the blueprint.txt subproject: I have improived the Oren-Nayar lighting model for the fur shader. Most notably, that wierd flickering at the edges where fins generation happens no longer occurs. But there are also some aesthetics/realism/smoothness improvements. I think it looks the most realistic possible.

There are two versions, one with a quadratic (top) and one with a max (bottom) model for combining two lighting values.

Spoiler

54TCZLV.jpeg
zEI0BB7.jpeg

Contrary to my expectations, I think the max model looks better.

Does interest exist to update the fur shader pack with this improvement? (@idbeholdME)

Edited by Lindor
Link to comment
1 hour ago, idbeholdME said:

Why not? Seeing how it looks  in motion is the important part :D

Done, available for download.

I'm interested in your opinion: which of the two looks better you think?

 

BTW I'm not super happy with the specular lighting. It suddenly seems to appear more yellow-ish. Don't know why, in theory should be whiter.

Link to comment
3 hours ago, Lindor said:

wether there is a reason that bonusgroup names all have this long string of spaces in the end?

Can't say, but the inloading function is set to ignore the space characters at the end of a string. So, no practical use.

  • Thanks! 1
Link to comment

Okay I think the automated bonusgroup generation function is completed. Unfortunately I cannot test it ingame until the whole blueprint.txt logic is set up. The only thing left though is blueprintsets.

We're getting closer to a release. The steps left to do are:

  1. completing Enable.exe by writing the blueprintset exporting (should be pretty quick)
  2. completing blueprint.txt by completing the non-usagebits single-weargroup option (middle-ish difficulty) and by writing blueprintset importing (also easy)
  3. completing Update.exe by applying the (already built) hash/name generation scripts by writing the s2rw commandline scripts, importing and exporting functions (this one is hard)
  4. building Disable.exe (easy)
  5. Sort every script into correct folder and apply the path generation to all the require() functions (easy, but potentially time consuming)
  6. Test ingame and hope I didn't forget anything
  7. write the README.txt
Edited by Lindor
Link to comment

I can proudly announce that, after some bugfixing during the Disable.exe building (which basically reassembles the original blueprint.txt syntax, therefore being ideal for testing), the automated bonusgroup generation works! Here's a snippet of what it does automatically in the background:

Spoiler
newBonusgroup = {
    id = 1720,
    name = "SB_0spell$spell$spell$$melee$ranged$",
    bonuslist = {1091, 1654, 1633, 1657, 1656, 1599, 164, 1680, 1658, 1609, 1620, 1173, 1017, 983, 1157, 1155, 1153, 501, 1655, 1710},
}
do mgr.createBonusgroup(1720, newBonusgroup) end

newBonusgroup = {
    id = 1721,
    name = "SB_2EA_DM_MENTALISM$generic$melee$$EA_SK_TACTICALCOMBAT$ranged$EA_SE_TECHNICS",
    bonuslist = {1696, 20, 1632, 1635, 1713, 1700, 1689, 1669, 1664, 1616, 1615, 1611, 1610, 1602, 1601, 1701, 1011, 1195, 1600, 21, 1016, 1015, 1014, 1013, 1012, 975, 964, 23, 1693, 24, 1623, 22, 1660},
}
do mgr.createBonusgroup(1721, newBonusgroup) end

newBonusgroup = {
    id = 1722,
    name = "SB_3EA_DM_MENTALISM$generic$melee$$EA_SK_TACTICALCOMBAT$ranged$EA_SE_TECHNICS",
    bonuslist = {766, 76, 759, 844, 813, 1711, 849, 841, 776, 782, 1028, 795, 764, 1667, 817, 456, 781, 976, 846, 1709, 784, 1023, 468, 1716, 448, 765, 444, 430, 443, 754, 471, 1607, 1634, 1706, 412, 753, 855, 458, 1684, 450, 1679, 420, 1699, 799, 1692, 1168, 1665, 80, 1052, 1603, 464, 818, 1719, 1718, 466, 1622, 408, 7, 1612, 1605, 1630, 438, 421, 424, 1566, 1565, 1564, 1563, 1562, 1166, 1019, 437, 73, 172, 1691, 1613, 856, 1604, 814, 1682, 793, 761, 823, 839, 822, 832, 467, 434, 800, 1712, 768, 425, 439, 824, 811, 418, 441, 1170, 810, 442, 1169, 1167, 769, 416, 1121, 1120, 1119, 1118, 1117, 809, 1116, 1115, 1114, 1113, 1112, 1111, 1110, 1109, 1108, 816, 1107, 828, 422, 835, 410, 752, 830, 773, 801, 827, 78, 770, 1054, 1053, 1051, 1050, 1049, 821, 1027, 1025, 1024, 807, 780, 413, 803, 1020, 772, 758, 460, 74, 465, 449, 414, 411, 496, 1022, 1627, 61, 75, 1026, 806, 462, 966, 958, 836, 12, 429, 751, 1708, 1165, 1694, 790, 774, 1029, 858, 857, 854, 853, 852, 851, 850, 848, 847, 845, 843, 842, 840, 838, 837, 407, 417, 834, 463, 833, 831, 829, 77, 826, 825, 820, 819, 815, 812, 808, 805, 804, 802, 798, 797, 796, 792, 791, 789, 788, 787, 786, 785, 783, 39, 779, 778, 777, 775, 451, 409, 771, 767, 762, 760, 757, 756, 755, 40, 415, 435, 446, 431, 426, 1619, 453, 419, 1021, 447, 406, 423, 1707, 98, 38, 455, 503, 79, 433, 473, 470, 469, 461, 459, 454, 452, 445, 440, 41, 436, 432, 428, 427, 1678, 405, 42, 457, 43},
}
do mgr.createBonusgroup(1722, newBonusgroup) end

newBonusgroup = {
    id = 1723,
    name = "SB_1ranged$ranged$spell$$EA_SK_ASTRALPLANE$EA_DR_VOODOO$generic",
    bonuslist = {9, 1618, 146, 1702, 1686, 143, 1704, 1617, 1687, 510, 509, 1705, 145, 1703, 147, 144},
}
do mgr.createBonusgroup(1723, newBonusgroup) end

 

Now if my maths didn't left me, 264 different auto-bonusgroups generated for my tests on EE, additionally to the 1719 single-bonus-bonusgroups. Might be off by one or two, since a couple of IDs are hardcoded and need to remain.

The bonus IDs are all mixed up and won't tell you anything. You basically won't have to worry about bonus IDs ever again, and also not about bonusgroup IDs.

 

Still a bug left though, for some reason the bonusgroup IDs sometimes don't get written out at the blueprint entry which then looks like this:

Spoiler
newBlueprint = {
    id = 1225,
    name = "hero_helmet_full_fight_rare",
    palettebits = "1111111111111111",
    dmgvariation = 0,
    minconstraints = {1, 9, 0},
    lvljump = 1,
    usability = 0,
    allotment_pmfpi = {1000, 0, 0, 0, 0},
    uniquename = "",
    specialuseonly = 0,
    bonusgroup0 = {1926, 1571, 1, 1, 0},
    bonusgroup1 = {1927, 1571, 1, 1, 0},
    bonusgroup2 = {1927, 1571, 1, 1, 0},
    bonusgroup3 = {"", 1000, 1, 1, 0},
    bonusgroup4 = {"", 1000, 1, 1, 0},
    bonusgroup5 = {"", 1000, 1, 1, 0},
    itemtypes = {10036, 10037, 10087, 10088, 10558, 10682, 12841, 13542, 13637},
    wearergroups = 1225,
}
do mgr.createBlueprint(1225, newBlueprint) end

 

Have to figure out what's that all about.

EDIT: Figured it out. It was a series of bugs in the slot creation process. Fixed.
Enough work for today. Lots of progress. Quite an accomplishment.

Edited by Lindor
Link to comment

@dimitrius154 For the current implementation of the make-every-item-single-weargroup-option (which is actually more a single-itemtype-option), I have to give the blueprints very big blueprint IDs. Basically I'm concatenating the old ID with the itemtype.
Is there an upper limit for how big blueprint IDs can be?

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...
Please Sign In or Sign Up