The reset-aware level gate in BotPartyHandler rejected nearly every party
invitation on servers with resets, because it folded reset count into the level
scale (one reset ~= 400 points against a 500 cap). A veteran player inviting a
freshly generated bot was always over the limit, so the invitation was silently
declined. Remove the gate so a bot accepts any inviter who is alive and in the
world, matching OpenMU's own party action; the situational safeguards (shopping,
revenge, mini game, pending invite, human companion) stay in place.
The event chip registration (0x95) and dialog close (0x97) requests are
handled since the Golden Archer item registration feature was merged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The generic EventChipRegistrationRequest/EventChipExitDialog/EventChip
RegistrationResult packets predate this feature and are reused by other
NPCs; renaming them to GoldenArcher* broke the public packet API and
docs filenames for no benefit. Also reverts unrelated BOM removal,
blank-line and escaping churn (GameConfiguration.cs, Character.cs,
Directory.Packages.props, Startup.csproj) and ~3900 lines of
trailing-whitespace-only diff noise in ServerToClientPacketTests.cs,
keeping only the one genuinely new test for EventChipRegistrationResult.
Squashed from the feature/golden-archer branch history (62 iterative
commits) into a single commit for reviewability. Adds a generic
item-registration engine (IItemRegistrationStrategy + feature plug-in +
NPC-configurable rules) with a concrete Golden Archer / Rena strategy,
the EventChip* packets it uses, and supporting EF migrations.
The behaviour notes were describing a bot which took the strongest map it
could survive, travelled for free, and fought with whatever it had
learned. All three have changed on this branch: the map is drawn among
the ones worth going to, the trip is paid for like a player's, and a
skill the character cannot currently cast - a pet's without the pet, or
one a reset left it holding above its level - is passed over.
Three settings which read as if they controlled the bot population did
not do what they say:
Unchecking "Enabled" did nothing until the next restart - the bots kept
hunting. It now stops them within a tick, without deleting anything, so
checking it again brings the same characters back.
"Reset bots" was skipped whenever the number of accounts was zero: the
server which carries out the reset was picked as the owner of the FIRST
account, and with no accounts configured there was none - so the one
setting which says "I want no bots" disabled the code which removes
them. The role now follows from the set of game servers alone.
Deleting the bots for good was not possible at all: a reset regenerates
the population, and every gate sat behind "Enabled". The new "Purge
bots" deletes every bot account and switches the feature off - which is
what makes it a purge, since the same pass would otherwise generate the
population again right after deleting it. It works with the feature
enabled or disabled, and whatever number of accounts is configured.
A flag which is set but cannot be acted upon is logged now instead of
being ignored silently. That silence was why a purge which never ran
looked like one which had nothing to delete.
The bots documentation lists every setting of the feature plugin and describes
what a bot does with its money, so it has to follow: the two stock settings are
added, and the merchant section now says what actually happens - what makes the
bot go, how it picks the merchant, that it repairs there, that it only collects
the three jewels it can spend, and what it does at the money limit.
A master class at the maximum level only earns master experience from monsters
of at least MinimumMonsterLevelForMasterExperience, and no regular experience at
all - so below that line a kill pays it nothing. Bots kept hunting the strongest
monsters they considered safe, which are weaker than that line, and never gained
a single point of master experience.
Mastered bots now pick their map and hunting ground among the monsters which pay
them, and take the weakest ones above the line: master experience hardly grows
with the monster's level, so the cheapest kill above it is the best one. Those
monsters carry 40.000+ health, out of reach of the regular hit budget for a bot
in the gear it collects from drops, so the budget is stretched for them - a long
fight it survives beats a quick one worth nothing. Survivability is not
stretched: a monster whose hits it cannot take is still refused.
The QuestProgressExtended packet (F6 0C) has a declared length of 272 bytes.
A C1 packet header only supports a 1-byte length field (max 255 bytes), so
the correct header type is C2, which uses a 2-byte length field.
- Rename C1-F6-0C-QuestProgressExtended_by-server.md to C2-F6-0C-...
- Fix the packet type byte (0xC1 -> 0xC2) and length field width (1 -> 2 bytes)
- Fix field offsets: C2 header is 4 bytes (not 3), shifting all fields by 1
- Update the link in ServerToClient.md
Now we can transmit values of Health, Shield, Mana, AG, Damage, Experience above 65k. I widened all to 32 bit.
Additionally, I added a message to add more than one statpoint at a time.
These changes will be added to my MuMain sources soon as well.
