Seed Sphere MaximumItemLevel defaults to 0, blocking /item from creating tiers 2-6 even though crafting supports them

[didiconcs]

Summary

All "Seed Sphere (Element) (N)" ItemDefinitions (Group 12) are seeded with MaximumItemLevel left at the default 0, because CreateSeedSphere() never sets it, unlike the sibling CreateSeed() method right above it, which does:

// CreateSeed(): sets it correctly
itemDefinition.MaximumItemLevel = (byte)options.PossibleOptions.Max(o => o.Number);

// CreateSeedSphere(): never sets it, stays at the default 0
private void CreateSeedSphere(byte number, string name, byte level, ItemOptionDefinition options)
{
    var itemDefinition = this.Context.CreateNew<ItemDefinition>();
    itemDefinition.Name = name;
    itemDefinition.Number = number;
    itemDefinition.Group = 12;
    itemDefinition.Durability = 1;
    itemDefinition.Width = 1;
    itemDefinition.Height = 1;
    itemDefinition.DropLevel = level;
    itemDefinition.SetGuid(itemDefinition.Group, itemDefinition.Number);
    itemDefinition.PossibleItemOptions.Add(options);
    this.GameConfiguration.Items.Add(itemDefinition);
}

(src/Persistence/Initialization/VersionSeasonSix/Items/SocketSystem.cs)

Confirmed on a freshly seeded Season 6 database:

Name                          | MaximumItemLevel
Seed Sphere (Fire) (1)        | 0
Seed Sphere (Water) (1)       | 0
Seed Sphere (Fire) (2)        | 0
...

Why this matters

A Seed Sphere's socket-bonus tier is determined at runtime by its item instance Level (0-5), not by which of the 6 per-tier ItemDefinitions it is. Confirmed in MountSeedSphereCrafting.CreateOrModifyResultItemsAsync:

sphereOption.ItemOption = seedSphere.Definition.PossibleItemOptions
    .SelectMany(o => o.PossibleOptions)
    .Single(o => o.OptionType == ItemOptionTypes.SocketOption && o.Number == seedSphere.Level);
sphereOption.Level = seedSphere.Level;

and in SeedSphereCrafting.CreateOrModifyResultItemsAsync:

result.Level = seed.Level; // The level defines the kind of option

The normal crafting path (Seed Master NPC → "Seed Sphere Creation") works fine because it assigns Item.Level directly in code, bypassing any MaximumItemLevel check. But /item explicitly enforces the cap before creating anything, in ItemChatCommandPlugIn.TryParseArgumentsAsync:

if (arguments.Level > itemDefinition.MaximumItemLevel)
{
    await gameMaster.ShowLocalizedBlueMessageAsync(nameof(PlayerMessage.ItemLevelExceeded), itemDefinition.MaximumItemLevel).ConfigureAwait(false);
    return (false, null);
}

Since MaximumItemLevel=0, any /item ... lvl=1 (or higher) request for a Seed Sphere is rejected with "Item level exceeded". A GM can only ever spawn tier-1 (Level 0) Seed Spheres for testing, even though the real crafting system supports and produces all 6 tiers (0-5) without issue. This likely also blocks setting a higher level through any other path that validates against MaximumItemLevel (e.g. creating a brand-new item of this type through the AdminPanel).

Suggested fix

In CreateSeedSphere(), set MaximumItemLevel the same way CreateSeed() already does one method above it:

itemDefinition.MaximumItemLevel = (byte)options.PossibleOptions.Max(o => o.Number);

This evaluates to 5, matching the 6 valid IncreasableItemOption.Number entries (0-5) already seeded per element.

Environment

• Confirmed against origin/master (commit b29338b78), Season 6 seed data, fresh database.
• Not gameplay-breaking: the real crafting path is unaffected. This only limits GM/admin tooling.

[sven-n]

As far as I remember, GMO had only the first level of seed spheres in Season 6.

[didiconcs]

Hi @sven-n,

We dug into a Season 6 Episode 3 (English protocol) client source tree we maintain locally (a from-scratch reimplementation of the retail client, not decompiled/pirated code) to check whether the retail client only ever shipped a single Seed Sphere tier, as you suspected.

Short answer: the client is fully built for 5 distinct tiers per element, not 1. We found no evidence limiting it to a single tier anywhere in the socket/seed sphere code.

1. The item-type enum defines 5 separate item types per element (30 total), not 1

// src/source/Core/Globals/_enum.h, lines 2662-2691
ITEM_SEED_SPHERE_FIRE_1      = ITEM_WING + 100,
ITEM_SEED_SPHERE_WATER_1     = ITEM_WING + 101,
ITEM_SEED_SPHERE_ICE_1       = ITEM_WING + 102,
ITEM_SEED_SPHERE_WIND_1      = ITEM_WING + 103,
ITEM_SEED_SPHERE_LIGHTNING_1 = ITEM_WING + 104,
ITEM_SEED_SPHERE_EARTH_1     = ITEM_WING + 105,
ITEM_SEED_SPHERE_FIRE_2      = ITEM_WING + 106,
...
ITEM_SEED_SPHERE_FIRE_5      = ITEM_WING + 124,
...
ITEM_SEED_SPHERE_EARTH_5     = ITEM_WING + 129,

Every element (Fire/Water/Ice/Wind/Lightning/Earth) has its own _1 through _5 item type. There is no _6 for any element anywhere in the enum.

2. The socket option data model is a fixed 5-slot table, one power value per tier, for every option

// src/source/Network/Server/SocketSystem.h, lines 85-103
typedef struct {
    int m_iOptionID;
    int m_iOptionCategory;
    wchar_t m_szOptionName[MAX_SOCKET_OPTION_NAME_LENGTH];
    char m_bOptionType;
    int m_iOptionValue[5];   // <-- one value per tier, 5 slots
    BYTE m_bySocketCheckInfo[6];
} SOCKET_OPTION_INFO;

and

// src/source/Network/Server/SocketSystem.h, line 15
const int MAX_SPHERE_LEVEL = 5;

This is a structural design choice (fixed array size, named constant), not an accident of a single populated tier.

3. Tooltip code actually reads and displays a tier-specific value, computed straight from the item type

// src/source/Network/Server/SocketSystem.cpp, line 366 (AttachToolTipForSeedSphereItem)
auto fOptionValue = (float)pInfo->m_iOptionValue[(pItem->Type - (ITEM_SEED_SPHERE_FIRE_1)) / 6];

(Type - FIRE_1) / 6 yields 0-4 (the 5 tiers), used directly as the index into the 5-slot value table. This is live, reachable UI code that runs whenever a player mouses over a Seed Sphere item, not dead/unused code.

4. Supplementary (weaker) signal

Cash-shop test data bundled in this repo's build output references a real sellable "LV3 [Element] Seed Sphere" product, e.g.:

out/build/windows-x86-vs/src/Debug/Data/InGameShopScript/512.2012.084/IBSProduct.txt:2314
991@LV3 Ice Seed Sphere@Quantity@1@EA@0@1192@142@145@1@144@673@518@6258@7@138@680

dated 2012. We can't confirm this specific shop data originates from GMO itself (the region/publisher of this particular script isn't clear from the file alone), so treat this as corroborating rather than conclusive, unlike points 1-3 above which come directly from the client's own game logic.

One correction to our original report, though

The client only supports 5 tiers per element (_1 to _5), not 6. So the fix probably shouldn't allow item Level 0-5 (6 values) as we originally implied - it should allow Level 0-4 (5 values), matching MAX_SPHERE_LEVEL = 5. We found more detail on this while digging into the byte-encoding side of things for #891 (posted there), including a fairly concrete explanation of the crash mechanism itself.

Happy to pull any other specific piece of this client's Seed Sphere code if it would help.

[sven-n]

I know that the client has code for 5 levels. However, I actually played it on the official server until the end of season 6 and only the first level was effectively available for the players.

[didiconcs]

That settles it then, first-hand experience on the official server beats what we could reconstruct from the client alone. Our dig only shows the client is capable of 5 tiers, not that GMO ever actually granted anything past the first one in practice, which is really the question that matters here.

So MaximumItemLevel=0 is very likely correct/intentional as-is, not a config bug. Feel free to close this, and apologies for the noise. If OpenMU ever wants to deliberately let private servers grant higher tiers as an opt-in (a few other config knobs in this project already lean toward "more permissive than official" for server owners who want it), #891's findings on the safe byte-range cap would still be the relevant reference at that point.