the account ids check out end to end: the player's avatar carries the
profile account, the bot carries 0-0, LogicBattle::account_ids takes
both from the avatars, and the client's getAccountIndex therefore finds
the player at index 0 and makes them the bottom avatar. so
isOwnedByBottomPlayer is right, and it is right in a way that matters:
the player's units take the blue export names in Character::Character
and the bot's take the red ones. red draws, blue does not.
that leaves two candidates - an empty blue prefix on the row, or a data
reference pointing at the wrong row whose blue prefix happens to be
empty - and one run tells them apart. SCROLL_BOT_MIRRORS_DECK=1 hands
the bot the player's cards; if its knight draws and ours does not, the
rows are fine and the blue branch is the fault.
LogicGameMode::encode reads its return value out of getCheckSum() and
only then writes it:
v15 = ChecksumEncoder::getCheckSum(a2);
(...vptr+88)(a2, v15); // the checkpoint vint
return v15;
we were reading ours after that write, so the closing checkpoint was
folded into the number we compared. the two could never match, whatever
the simulation did - which is why tick 41 disagreed with six untouched
towers on the field.
write() now hands back the value it wrote, the way encode() does.
the spawn log caught it at once: two archers took 11 and 12, and the
goblins that followed started again at 12, then the knight landed on 13.
the counter moved by one per card while a card can summon several.
two objects sharing a global id are one object to the client -
getGameObjectIndex finds the first and reuses it - so the duplicates
never became objects, never got models, and left the client and the
server holding different sets, which no checksum can survive.
the bot's units get models and the player's do not, and both take the
same path through summon() - only owner and position differ, and
position for a player's card comes off the wire. so print the id, the
data row, the owner and the position at the moment the object joins the
battle, and compare the two sides instead of guessing again.
the models came back last run, washed out, and the card art went white
with them: BattleScreen::startResourceLoading walks the battle's objects
to decide what to load, and an opening state holding only two towers
left it nothing to load. art needs the objects in the first state; the
model needs them to arrive after the screen exists. both, not either.
so everything ships up front for the art, and everything except the two
summoners is renumbered once the client speaks, which makes it new to
LogicGameObjectManager::decode and gets it through addGameObject with
its art already in memory. the summoners stay put because the hud holds
them raw at [SpellButton+0x1d0].
mana spending from the last commit is confirmed working in the log.
LogicBattle::resetSimulatedManaTimers reads both leaders out of the
battle at +96 and +104 and calls a virtual on each without a null check,
so an opening state with no leaders segfaults inside LogicGameMode
::decode before anything else happens.
so the opening state carries the two king towers and nothing else. they
are the objects that cannot get a model - the battle screen, and with it
the listener, does not exist yet - and they are also the pair the hud
caches at [SpellButton+0x1d0], so they are exactly the objects that must
not be replaced later either. everything else, princess towers included,
now arrives after the screen is up.
traced the whole path in the client rather than guessing at it again.
GameObjectManager::addGameObject is the only thing that builds a model,
and LogicGameObjectManager::decode calls it through the listener at
[mgr+0x28], only for objects whose "newly created" flag is still set -
and it clears that flag on the way out. setListener has exactly two
callers: the BattleScreen constructor and its destructor. GameMode
::updateLoading builds that screen only after isFullUpdateReceived, ie
after the first sector state has already been decoded.
so every object in the opening state is created against the do-nothing
base listener, loses its flag, and can never get a model afterwards -
later snapshots match it by global id and reuse it. that is the missing
archers, and it was never about the data or the ids.
the opening state now carries no objects and no leaders. the towers
arrive on the next snapshot, once the client has said it is up, and are
new by then.
renumbering, which the last commit did, is gone: SpellButton caches the
summoner at [this+0x1d0] when the hud is built, so replacing the objects
under it left a dangling pointer, which is the getOwnerAccountId crash.
also spend mana when a card is played - it was only ever regenerating.
the client never asks for the state, so the objects it decoded before
the battle screen installed its listener were stuck without models for
the whole battle - and every later snapshot matched them by global id
and reused them, so the "newly created" flag the visual depends on was
never set again.
the first sector command is the client telling us it is up. at that
point every object is handed a fresh id: nothing matches, so the client
builds them all from scratch and they get models. the leaders and the
tower lists are remapped with them and the column is re-sorted, since
the client binary searches it.
the battle itself is complete as of this run: a princess tower fell and
the first crown was scored, towers (2, 1) and stars (1, 0) in the log.
RequestSectorStateMessage, 12903, one vint of client tick, sent through
sendUdpMessage and so arriving on tcp like everything else. we were
ignoring it.
it matters because of how the client builds models. the factory marks a
freshly created object at [obj+0x14], and only for those does
LogicGameObjectManager::decode call the listener at [mgr+0x28] that
builds the visual. every later snapshot matches the same object by
global id and reuses it, so the flag is never set again - an object that
was decoded before the battle screen installed its listener stays
invisible for the whole battle while still walking and fighting. that is
the tower archers and the invisible units; the knight shows because the
client creates that one itself, after the screen is up.
the client asks for the state when it is ready, and now it gets it.
a collision could shove a unit past the edge of the arena. the next path
search then turned that negative coordinate into a tile index, cast it to
usize and read far off the end of the grid - the panic killed the tokio
task running the battle, snapshots stopped, and the models the client had
already been told about were left frozen and unresolvable. that is the
invisible-unit symptom: the simulation was dead, not the rendering.
the push is clamped to the arena now, and find_path checks that the start
tile is on the map rather than only the goal.
LogicMath::sqrt is a 256-entry table of floor(16*sqrt(i)) with a seed
picked by magnitude and one or two newton steps on top, and it is not
exact: above 2147441940 the seed overshoots and the single correction
cannot pull it back, so it answers 46341 where the true root is 46340,
and 65535 for INT_MAX.
that matters because the checksum is computed over whatever it returns.
an honest square root would be a permanent, invisible disagreement, so
this one is transcribed branch for branch - including the early -1 for
negatives and the INT_MAX special case - and our own converging root is
gone. checked against the exact root across the low range and the
boundaries, where the two agree, and at the top, where they must not.
distances now go through the saturating helper before the root, the way
the client does it, rather than being squared in i64 on the way in.
the client matches the objects in a snapshot against the ones it already
has by global id, and anything it cannot find it builds from scratch.
our next id was the highest one in play plus one, recomputed at every
spawn - so as soon as a unit died its id came free and the next spawn
took it. at five snapshots a second the client was destroying and
rebuilding models faster than they could appear, which is why units
fought and shot while invisible.
the counter is per battle now and only ever goes up, starting past the
towers.
collisions, from checkCollisions and checkCollision in the client.
a pair is considered when both are on the same plane - air with air,
ground with ground, decided by z. the radius is the unit's own
CollisionRadius, capped at 500 when the other side has no movement
component, which is what lets a unit squeeze past a building instead of
being shoved by it, plus the other's radius. the axis test comes before
the squared one, tangency counts as a hit, and two units standing exactly
on top of each other are separated along y by the owner's facing rather
than dividing by zero.
the push is clamp(sum - distance, 0, 300) scaled by the other's mass over
mine, plus one, capped at 300, spread along dx and dy over the distance.
Mass is clamped to one through twenty and a building counts as twenty.
the accumulator is drained the same tick it is filled, as it is in the
client.
what is still short of the client: the push is averaged over the pairs
rather than run through updateMovementTowards, avoidance steering is not
modelled, and LogicMath::sqrt is our exact root rather than the client's
table - which differs from the true root above 2147441940 and will have
to be reproduced bug for bug before checksums can agree.
the bot's first card was due on tick one, so it was already walking
while the opening countdown was still on screen - reaching the bridge
and swinging at nothing before the battle had visibly started. it waits
six seconds now before opening, and keeps its four to eleven second
rhythm after that.
the server was simulating correctly all along - the log shows a goblin
covering 120 units a tick and a knight 60, exactly their Speed columns,
in a straight line with no jitter. the teleporting was the correction
rate: one snapshot a second, while the client runs its own prediction in
between and diverges from ours. a unit gets more than a tile out of step
before our state arrives and drags it back.
the snapshot now goes every four ticks and the gateway ticks every fifty
milliseconds rather than two hundred, so a correction moves a unit a
fifth as far.
this makes the symptom smaller, not absent. it goes away when the two
simulations agree, which is what the checksum comparison is for and what
collisions and projectiles are still missing for.
newton's method in integers can settle into a two-value cycle rather
than a fixed point, and the loop guard was "the value changed", which
such a cycle satisfies for ever. it ran under the session lock inside a
spawned task, so the worker never reached a yield point and the runtime
could not shut down - which is why ctrl-c printed "shutdown requested"
and then hung.
the guard is now "stopped decreasing", which is the converging form.
checked against the exact integer square root across the small range and
the boundaries, including the 46340 saturation edge and INT_MAX.
the checksum goes out first and the tick second: setClientChecksum writes
[+0x50] and setClientTick writes [+0x54], and encode writes [+0x50]
before [+0x54]. we had them the other way about, which is why the log
showed a tick full of noise and a checksum climbing by forty-one a
message - the tick was being read as the checksum.
the tick was running A* over the whole 36x64 grid for every unit, every
tick. catching up ten seconds meant thousands of searches inside the
session lock, so the tick loop never finished, snapshots never went out,
and the client - which refuses to send a command while
isFullUpdatePending is true - sat there showing the connection icon and
would not spawn anything. ctrl-c looked like a hang for the same reason:
a task stuck in that loop.
the client does not do this either. LogicMovementComponent carries a
path array precisely so the route is found once and walked. we keep the
route and the goal it was found for, drop a node once we are within
250 units of it, and only search again when the goal moves or the route
runs out.
advance_to also refuses to simulate more than forty ticks in one call,
so a late tick can never turn into an unbounded loop under the lock.
the snapshot is built inside the tick loop but the clock was written
after it, so every pushed state went out carrying the tick from the
previous call. LogicGameMode::decode compares that number against the
last one it saw and ignores anything older, so a stale stamp is the
difference between a state being applied and being dropped on the floor.
the clock advances with the tick now.
the sector command log gains the summoner mana, how many snapshots have
gone out, and the type of the command that arrived, so the next run says
whether the push is happening at all rather than leaving it to inference.
at type 0 the client stopped working the elixir bar out for itself and
started reading it from the summoner in our snapshot - which never
moved, so the bar sat where the opening state left it and no card could
be afforded.
the rule from LogicSummoner::tick: an accumulator gains five thousand a
tick and one mana is granted for every MANA_REGEN_MS * 100 / MAX_MANA it
holds, the remainder carried rather than dropped. that works out at
2.8 seconds a mana with the shipped globals, and halves in the last
sixty seconds through MANA_REGEN_MS_END, which is the speed-up the game
has always had.
type 0 turns out not to need a UDP transport. MessageManager::sendUdpMessage
checks for a socket and a valid connection, and falls straight back to
sendMessage when there is neither - we never send UdpConnectionInfoMessage,
so the client has no socket and the sector traffic arrives on the tcp
connection we already have.
so SectorCommandMessage, 12904, is decoded now: a client tick, a client
checksum and an optional command. a card played this way goes through the
same summon path as before. the client stops sending EndClientTurnMessage
in a battle - sendEndTurn asserts on isImmediateMessageExecution - so the
checksum comparison moves onto the sector command, which carries the same
two numbers.
with the type at 0 the client no longer simulates. it renders what the
snapshot says, which is why the snapshots start flowing again: the gate
on them was the battle type all along. the bot's cards reach the player
for the first time, because there is finally one simulation rather than
two arguing.
the leading vint of the game mode is not a field of its own. the client
loads it straight out of LogicTime at gameMode+0x60 and then encodes
LogicTime immediately after, so the same number goes out twice and the
two cannot drift. we kept a separate server_tick that the session never
advanced, so it stayed at zero while the clock ran - a divergence in the
checksum that had nothing to do with the simulation. the field is gone
and the tick comes from LogicTime.
LogicGameMode::calculateChecksum runs the whole game mode through a
ChecksumEncoder - in a battle there is no client home, so it is the same
encode as the snapshot with the command manager left out. we compute the
same number now and log it beside the one the client sends in every turn
message, with whether they agree.
that comparison only means something because of what turned up while
reading the encoder: the two vints the decoder throws away are not
padding. the client writes getCheckSum() into both, once after the
server tick and once after the tutorial manager. we were writing zero,
which parses fine - the decoder discards them either way - but poisons
the running checksum, so the numbers could never have matched. they
carry the real running value now.
the two will not agree yet. the point is to see how far apart they are
and where, since the gap is what stands between this and battle type 0.
units stood still all battle. a unit only moved if it had a combat
target, and targets are only found inside SightRange - six thousand
units for a knight - while the enemy tower sits twenty thousand away. so
nothing ever walked, nothing was ever hit, no tower fell, crowns stayed
at nothing and the battle could only end on the clock.
a unit with no target now walks at the nearest enemy building, which is
the default target the client falls back to. once the tower comes inside
sight the ordinary search picks it up and the attack timer takes over.
the battle turn log carries the standing tower count per side so damage
is visible before it becomes a crown.
units now path. A* over the tilemap grid, water costing 800 against 1
for ground so the route runs to a bridge, or 20 when the unit flies and
crosses anywhere. bit 5 of a map cell is the water flag, which is what
makes 48 water and leaves the bridge cells - carrying the lane ids 1 and
2 - dry. the unit walks to the next node rather than at its target, and
still stops at Range.
also stops pushing snapshots while the battle type is 1. the client is
simulating the same battle itself there, and our state does not match it
yet, so every push yanked the units back to where the server thought
they were. the snapshots are still built and verified each second, ready
for the switch to type 0 once the two simulations agree; they are simply
not sent.
matchmaking now queues. the first player in waits, the second one to
arrive pairs with them, and both get the same battle: one shared session
keyed by both accounts, one snapshot, the client working out which side
it is from the account ids it already carries. if nobody turns up within
ten seconds the ticker polls the queue out and builds the bot battle
instead. cancelling or disconnecting leaves the queue.
also fixes the movement component tail: the extracted layout counts
"n + 18" vints including the path length itself, so seventeen follow the
path, not eighteen. the verifier read one too many and every snapshot
carrying a moving unit came apart after it - which is what the guard
caught and refused to send, rather than the client aborting on it.
every four to eleven seconds the bot draws a card from the deck we gave
it and puts it down on its own side, on the lane of whichever of its
towers stands furthest forward. the card goes through the same summon
factory the player's cards use, so it lands in the server simulation and
reaches the player inside the next snapshot rather than through any
special path.
placement comes from the bot's own tower positions rather than from the
tilemap, so the session does not need the map threaded into it.
a character with Speed gets a LogicMovementComponent on the client, and
until now we had no encoder for it, so any snapshot carrying a unit
would have desynced. the layout is four booleans, a path length, that
many path nodes, and eighteen more vints - one conditional, no data
driven ones. charge time defaults to the -1 the client uses when
ChargeRange is empty, which is every card but the Prince.
with that in place the session pushes a fresh SectorStateMessage once a
second down the battle ticker. every push runs through verify_snapshot
first and is dropped rather than sent if it does not read back, the same
guard that caught the decks.
the verifier learned the movement pass, and lost the leftover
SCROLL_BATTLE_SUMMONER switch that the builder had already shed.
crowns now move because the server finally hurts things. each tick it
retargets, moves, resolves attacks and buries the dead, in that order.
the numbers are the client's own. Speed is position units per tick, so a
knight at 60 covers 1.2 tiles a second; SightRange and Range are in the
same units with 1000 to a game tile, and the target's CollisionRadius is
added on the far side of both. distances compare squared with the
client's saturation rule - beyond 46340 on either axis, or on overflow,
the distance is INT_MAX rather than a wrapped negative. the attack timer
counts milliseconds fifty at a time and fires once LoadTime + HitSpeed
have passed, then rewinds to LoadTime. tower damage comes from
projectiles.csv, not from the Damage column of buildings.csv, which is
empty for them.
a princess tower leaving the board is struck from leader_towers, which is
what getStars reads, so crowns follow from the same list the client
keeps.
what is deliberately not modelled yet: pathfinding, so units walk
straight at their target instead of along the roads and over the bridges;
collision, pushback and avoidance; projectiles as travelling objects,
since the damage lands the moment the attack fires; and buffs. field_48
on the combat component is renamed hit_timer after what it holds.
the client never receives individual commands in a battle - SectorManager
has receiveSectorState, receiveCompressedSectorState and a heartbeat, and
nothing else. so everything the opponent does has to reach the player
inside server state, which means the server needs to be able to speak
first. it could not: the rpc only ever answered.
the gateway now runs a ticker for the length of a battle, calling a new
battle_tick on the service five times a second and writing whatever it
returns straight to the socket. the simulation stays in the service and
the socket stays in the gateway.
the first rider is emotes. the player's SendBattleEventMessage reaches
the service instead of being logged and dropped, and the bot answers with
a taunt of its own; it also sends one unprompted every twelve to thirty
seconds, drawn from the rows of taunts.csv that TauntMenu marks as
usable. the reply carries the opponent account so it renders on their
side of the arena.
commands carry tick_when_given and execute_tick, so a spawn no longer
lands the moment its turn message arrives. it is queued and released on
its own tick while advance_to steps the battle one tick at a time, which
is what makes the simulation reproducible from the command stream rather
than from when packets happened to arrive.
the per-tick object update goes in this loop next.
a LogicDoSpellCommand names a deck slot, so the card comes from the deck
we sent for that player, and the owner comes from matching the command's
executor account against the two the battle carries. the spell row's
SummonCharacter and SummonNumber say what and how many to place, at the
position the command carries.
the object factory behind the towers is now shared: hitpoints and the
combat/hitpoint/buff components are built the same way for a summoned
character as for a tower.
these objects are not encodable yet. a character with Speed gets a
LogicMovementComponent on the client, and we have no encoder for that
component, so the server copy must not be turned back into a snapshot
until it exists. nothing re-encodes it today - it feeds the clock, the
crowns and the end condition only.
LogicBattle::isEndConditionMatched, transcribed: the battle is over when
end_counter is positive, when either king is dead, when tick/20 seconds
reach MatchLength + OvertimeSeconds, or - once past MatchLength - when
the crowns differ. the divisor is the 0x66666667/2^35 multiply in the
client, which is a divide by twenty, so the battle runs at 20 ticks a
second.
crowns come from LogicSummoner::getStars: three when the enemy king is
down, otherwise two minus the enemy princess towers still standing,
which is exactly what leader_towers holds.
BattleRegistry keeps the LogicGameMode we built for each account and
advances it on the tick the client reports in its turn message, so the
server now tracks the clock, the crowns and whether the battle is over,
and drops the session when the player goes home. the two isSummoner
guards in the overtime branch are left out: they only fire for an object
that is not a summoner, which a king tower always is.
BattleScreen::createBattleEndHUD takes a null result message and builds
the end screen from the local battle, then BattleScreen::sendGoHomeMessage
fires - so in this mode the client decides the battle is over and asks to
go home on its own. we now clear the stopped flag on that request instead
of leaving the session wedged until the next login.
battle turns are logged with their tick, checksum and command types while
the flag is up, so the traffic at the end of a battle is visible.
command type 1 is LogicDoSpellCommand - the card the player put on the
field. it carries the usual command header, the deck slot, an optional
LogicSpell and the drop position. type 2 is
LogicCompleteTutorialBattleCommand, which reads its global id before the
header the way the achievement command does.
both execute to Ignored for now: the home logic is stopped during the
battle, so nothing on the server acts on them yet. decoding them stops
EndClientTurnMessage from being thrown away whole, which is what the
"unknown command type 1" warnings were.
LogicSummoner::tick guards the whole hand-refill block on the first vint
of the deck block being at least 1 - it is the number of hand slots the
client scans for an empty one before pulling from the draw queue. we
sent zero, so the hand we dealt was the only one the player ever got.
named after what it is and set to four.
12951 is SendBattleEventMessage, the in-battle emotes and quick chat. it
carries a LogicBattleEvent: a type byte, the sender account and three
int lists - ticks, coordinate pairs and params. it decodes now instead
of being dropped with a warning. the client renders its own emote
locally, so nothing is echoed back yet; the relay belongs with a real
opponent.
the card bar was empty because the hand lives on the king tower, not on
the battle. LogicSummoner::decode gates a whole block behind one boolean
- setEncodeDeckDataEnabled on the client side - and we always wrote it
false, so the client kept the hand and the draw queue it was born with,
which is nothing.
the block holds four deck indices for the hand, then two int lists: the
draw queue getNextSpell walks and the used pile reshuffleDeck folds back
into it. we now hand out the first four slots and queue the rest, leave
the used pile empty and keep last used at -1, which is what
getLastUsedSpell reads as "none".
starting mana comes from the START_MANA global instead of zero, and the
field after last-used is named after clearSpellCooldowns, which is the
only thing that writes it.
verify_snapshot still carried the stub from when both decks were always
absent, so the first battle that actually carried one was refused before
it reached the client. it reads them now: eight presence bits, then a
data reference, five vints and two booleans per filled slot.
while in there, the six battle booleans were all being discarded, which
hid the fact that the two score-change vints are only present when the
first of them is set. the verifier tracks it now, same as the encoder.
the decks were the visible half: LogicBattle carries one LogicSpellDeck
per player and we wrote both as absent, so the client cleared them and
the card bar came up empty. both sides get a real deck now - the player
from their profile, the bot from the fullest row of predefined_decks.
matchmaking no longer picks a row out of npcs.csv. it takes the location
from the arena's PvpLocation column and builds an opponent avatar with
its own name, arena and trophies, so the battle reads as a player match
rather than a trainer one. StartMissionMessage still goes through the
npc path unchanged.
the battle type stays 1 on purpose. LogicGameMode::isImmediateMessageExecution
is (type - 1) < 3, so 1, 2 and 3 let the client simulate locally while 0
makes it wait for the server to drive the sector - which needs the real
tick loop we do not have yet.
the client sends EndClientTurnMessage during the battle too, but its
tick and checksum belong to the battle, not to the home. we kept
comparing them against the home checksum and answered with
OutOfSyncMessage, which is the "Client and server are out of sync!"
dialog on tick 60.
HomeMode carries the stopped flag now and returns an empty turn result
while it is set, and sector_state_for raises it, so both the mission and
the matchmaking entry points are covered.
the base object writes owner index, component mask, position and z, in
that order. we had the first field unnamed and were writing the owner
into the z slot, so every object belonged to player 0, and the mask slot
carried a zero.
the mask matters: getHitpointComponent tests bit 2 of it before touching
components[2], so a zero mask made every tower report no hitpoints,
LogicCharacter::isAlive fell through to the z field, shouldDestruct went
true and the towers were destroyed on the first tick - which then hit
"cant find summoner tower" in LogicBattle::removeGameObjectReferences.
entries are built through LogicGameObjectEntry::new now so the mask is
derived from the component array and cannot drift from it.
also rename the first character flag after what sets it: kamikaze
death and morph both raise it right before the object is removed.
SectorManager::receiveSectorState reads one byte off the front of the
message body and branches on it: 1 goes to receiveCompressedSectorState,
anything else falls through to the plain decode. we never wrote that
byte, so the client ate the first byte of the snapshot as the flag and
then read every field one byte early - server tick 0, discard 11, and
the section sentinel landed on the LogicTime tick instead of 11.
drop the two bisect switches, they served their purpose: both settings
aborted identically, which is what ruled out the object payload.
the client aborts in Debugger::error("Full update stream is corrupted!"), tail
called out of LogicGameMode::decode, which is why the stack blames
receiveSectorState. only one error path exists there so it is a sentinel.
verify_snapshot reads the snapshot back following the client decoders and
refuses to send anything that does not land both sentinels with no trailing
bytes. it passes today, so the layout matches what i believe the client reads.
checked every reader against the binary: LogicGameMode, LogicBattle,
LogicGameObjectManager, LogicGameObject, LogicCharacter, LogicSummoner, all
three components, LogicClientAvatar, readGlobalID, readDataReference,
readConstantSizeIntArray, readGameObjectReference, decodeComponent, and
setLevelIndex for the component set. all match.
SCROLL_BATTLE_SUMMONER=0 encodes the king towers as plain characters,
SCROLL_BATTLE_PRINCESS=0 drops the princess towers. one client run with each
splits the remaining hypotheses.
the client reads getTable(8)->getItemCount() entries there, table 8 is
damage_types with 5 rows. i was writing character_buffs, 12 rows, so every
snapshot carried 7 extra vints and 7 extra booleans and the stream slid.
that is what tripped the sentinel and aborted the client in
Debugger::error("Full update stream is corrupted!").
verified the rest field by field against the client decoders: LogicGameMode,
LogicBattle, LogicGameObjectManager, LogicGameObject, LogicCharacter,
LogicSummoner and LogicCombatComponent all match. the conditional character
fields stay off because ReloadAfterHits and ManaGenerateLimit are empty for both
tower rows.
537 only tells the client's ui to start searching, the handshake after it was
missing: server sends 24106 StopHomeLogic, client answers 14105, server sends
21903. that last step now builds the same snapshot the npc mission does, using
npcs row 0 as the opponent.
battle type stays 1 so it runs on the client's offline path. a real pvp battle
is type 0 and needs the udp sector channel, which does not exist here.
14107 CancelMatchmake now answers 24125 instead of being ignored.
npc missions used to get a ServerErrorMessage back. now StartMission builds a
LogicGameMode snapshot off the arena tilemap and answers 21903.
towers come from assets/locations/*.csv the way initDefaultSector does it: tile
coordinates times 500, leader index decided by which half of the map the tower
sits in. the two king towers must be there, the client dereferences them without
a null check. they live in buildings.csv, not characters.csv.
LogicCharacter puts the base object fields fourth, not first. the buff component
writes a fixed array sized by the character_buffs row count even with no buffs.
training_arena parses to 2 kings, 4 princess towers, 36x64 subtiles. snapshot is
602 bytes over 6 objects. the real client has not seen it yet.
field order taken straight off LogicBattle::encode. the object manager is
columnar, not object major: 6 counters, a count, then all data refs, then all
global ids, then all objects, then four component passes. global ids must be
ascending, the client binary searches them.
LogicRandom moved out of the shop into its own module. its abs was
checked_abs().unwrap_or(0), the binary uses NEGS so i32::MIN stays i32::MIN.
one seed in four billion, but it would have desynced the card shop.
per object subclass encodes and the component payloads are still missing, so no
snapshot can be sent yet.
14303 AskForJoinableAlliancesList and 14107 CancelMatchmake are both genuinely
empty payloads. 516 UpdateLastShownLevelUp is header only, 537 StartMatchmake
carries a vint and a bool. none of them move the home checksum.
that clears the unknown type warnings out of the log.
SCROLL_MODE=supervised spawns auth-service, game-service and gateway, waits for
each rpc port before starting the next, and restarts whatever dies with backoff
from 500ms to 30s. the counter resets once a service has been up a minute.
single process mode is still the default and unchanged.
kill_on_drop means ctrl-c takes the children with it, no orphans.
