learnMoveOn (Game2.lua) built every move-learning message -- level-up
learn, TM/HM teach, the "trying to learn X, forget a move?" flow, "stop
learning?", the HM-can't-be-forgotten refusal, "which move should be
forgotten?", and the "1, 2 and... forgot X, learned Y!" replace result
-- with a bare string literal or a direct :format() call, bypassing
Strings() entirely (src/core/Strings.lua). Game2:say()/TextBox.new()
show whatever text they're handed with no lookup of their own, so this
meant the entire move-learning UI stayed in English no matter what
translation catalog a mod supplied -- confirmed against a real
gen1recomp-translation-mods build, which has translated overrides for
several of these keys that could never apply because the literal never
reached the catalog. Same bug for the TM/HM teach refusals ("X can't
learn Y!"/"X already knows Y!").
src/core/gen2/ItemEffects.lua had the same bug across its whole family:
every item-usage message (Potion/heal, status cure, Revive, Rare Candy,
Vitamin, PP restore/PP Up, "no effect"/"can't use on an EGG"/"can't use
on this #MON") was either a bare table constant or built with :format()
directly, none of it routed through Strings(). Its constants are now
wrapped in Strings.source() at declaration (so a mod's catalog harvest
still finds them, per the pattern already documented in Strings.lua)
and looked up through Strings() at each use site. The Vitamin success
message's own VITAMIN_LABEL table (HEALTH/ATTACK/DEFENSE/SPEED/SPECIAL)
gets the same two-part fix -- each entry wrapped in Strings.source() at
declaration, and Strings(VITAMIN_LABEL[stat]) at the one use site --
matching the identical stat-name tables in MoveEffects.lua/TrainerAI.lua/
gen2/Effects.lua/ContestMenu.lua/SummaryMenu.lua, which all already do
this; without it a Vitamin's stat name would stay in English mid-sentence
even inside an otherwise fully translated message. Two more call sites
read ItemEffects.TEXT_NO_EFFECT raw outside that file and needed the
same fix: PartyMenu.lua's Softboiled-no-target refusal, and
BattleState.lua's X-item-reused-with-no-effect and
BitterBerry-when-not-confused refusals -- both battle-side messages
where every neighboring self.message assignment already correctly
wraps in Strings(), which is what made these two stand out as missed.
None of this changes vanilla (no mod loaded) output: Strings.get() is
an identity function with no catalog active, so every message renders
byte-identical to before. Verified with the headless Gen 2 suite
(luajit tests/run_gen2.lua): 144/145, the one failure
(gen2_fishing_time_test.lua) reproduces identically on dev before this
change and is unrelated (fishing time-group logic); the full engine
suite (luajit tests/run_engine.lua) is 533/533.
messagePages() only split on \n (line) and \f (paragraph), so a translated
message needing a \v scroll-continue break -- the same marker PackMenu and
PrizeMenu's messages already rely on via CommonText.pages -- rendered wrong
here: no line ever scrolled. Delegate to CommonText.pages, the same shared
page-break implementation PackMenu and PrizeMenu already use for their own
messages, instead of a second, incomplete reimplementation local to this
file.
CommonText.pages() also only treats \n as the box's second row, not a page
break, unlike the old local messagePages(), which grouped every two
\n-separated lines into a page regardless of \f. The one BOX_FAILURE_SOURCES
literal with a third line via a second bare \n ("You'll need a\nPOKéMON to
call\nwith.") needed \f instead, the marker every other multi-page message
in this file already uses for the same transition (see RELEASED just
above); pinned with a test.
CenterPcMenu.lua's own TEXT.noMon had the identical \n-vs-\v bug: the
Pokecenter PC's empty-party refusal (_PokecenterPCCantUseText, "ends in
cont" per the comment already on this line) needs \v to scroll "have a #MON
to" up and land "use this!" under it, not a third bare \n line, which
pagesOf() (this screen's own \f/\v-aware paginator, unaffected by the
messagePages() bug above) renders as a lone one-line page instead -- caught
by gen1recomp/dev's own independent fix to the same line while rebasing this
branch onto dev, and confirmed against tests/gen2_pc_screens_test.lua's
scroll assertions. The French/German/Spanish/Italian/Japanese/Korean
overrides already carry the correct \v in their translated values; only the
lookup key needed the same fix, made in gen1recomp-translation-mods
alongside this commit.
GEN2_STATUS_IDS (psn/brn/frz/par/paralysis/slp -> Gen 2's own registry ids)
was declared verbatim in both PartyMenu.lua and SummaryMenu.lua; move it to
Status.GEN2_ID_ALIASES so a future status alias fix only has one copy to
update.
SummaryMenu.TYPE_NAMES was left behind after this branch switched its two
former internal uses to the shared TypeChart.displayName/DISPLAY_NAMES; it
has no remaining callers anywhere in src/ or tests/.
Immediate-mode UI polls SaveData.loadOptions once per frame (the
launcher's skins tab and SkinStudio's library re-read it to learn the
active skin), and every call was a getInfo+read+decode of the whole
options file against the save volume. The file can only change through
saveOptions (or loadOptions' own recovery write), so a per-filesystem
revision counter is enough: saveOptions bumps it on a verified write and
loadOptions re-reads only when it moved. Callers still receive a deep
copy per call, never the cached tree, and the cart overlay keeps
applying per call because the active cart can move between reads without
any write.
`Checkpoint.restore()` rejected most valid checkpoints:
Checkpoint restoration failed: restored state differed at $.save.poisonSteps
poisonSteps is a plain step counter -- (poisonSteps + 1) % 4 on EVERY step,
not only while a mon is poisoned (OverworldController:applyFieldPoison) -- so
it is non-zero three steps out of four in ordinary play.
Installing the restored world re-enters the map, and the map-enter path zeroes
the counter, correctly mirroring ClearVariablesOnEnterMap. Checkpoint.restore
then re-captures the applied state and compares it against the checkpoint, so
the field it had just discarded failed the comparison and the whole restore
rolled back.
A restore is not a map entry from the player's point of view: the counter
belongs to the state being restored. Carry it across the push.
Why this stayed hidden: the two autosave triggers a checkpoint consumer
naturally uses, map.entered and player.warped, are emitted from inside the
very paths that zero the counter (OverworldController 377/572 and 4664/4783),
so those captures hold 0 and restore cleanly. Only a capture taken at an
arbitrary step -- a manual quicksave, or one tied to the ordinary SAVE --
carries a non-zero value. The T4 title-checkpoint tier misses it for the same
reason: its save is fresh, so the counter is already 0.
The comment above the push claimed Checkpoint.resume was this method's only
caller. Both callers arrive through Checkpoint.apply, which serves resume from
the title session and restore from a settled runtime; that is exactly why the
map-entry side effects matter here. Corrected.
tests/engine/restore_poison_steps_bug1971.lua covers 1..3 and 0 across a
restore, and pins the two behaviours that must NOT change: a plain map entry
still zeroes the counter, and a seamless connection crossing still carries it.
It fails on main (3/6, "got 0, want 3") and passes with this change.
- Introduced the `POKEPORT_IDLE_AFTER` and `POKEPORT_IDLE_FPS` environment variables to manage presentation rates on static screens, allowing game logic and audio to maintain full speed.
- Updated the vsync handling to keep it enabled across all platforms, including KMSDRM handhelds, to leverage PresentSync for improved cadence and pacing.
- Enhanced FrameCap logic to ensure proper handling of performance caps in handheld environments, preventing unnecessary software pacing when hardware capabilities are sufficient.
- Adjusted documentation to reflect these changes and their impact on power efficiency and performance.
The sbc/portmaster launcher exports POKEPORT_AUDIO_RATE=22050 and
docs/linux-arm-sbc.md describes it as halving synthesis CPU on
Cortex-A53 handhelds, but nothing in the engine read it: ChipSynth
always rendered at 44100 Hz, and snapTicks baked that rate in as the
integer rational 1470/512 (so once the rate does change, music plays
at half tempo/pitch unless snapTicks follows).
Read the env var at module load (validated to 8000-48000, 44100
fallback) and make snapTicks rate-aware. At 44100 the new form is
arithmetically identical to the old one
((ticks*44100 + 7680)/15360 == (ticks*1470 + 256)/512), so desktop
behavior is unchanged.
Tested on an RG351MP (RK3326, dArkOS): correct music tempo and pitch
at 22050 Hz, halved synthesis work on the audio worker.
On weak single-core handhelds (RK3326/RG351MP) the main thread sits at
100% CPU, so every millisecond of jitter drops a frame: constant
stuttering while walking even at PERFORMANCE LOW with all mods off,
while average CPU usage stays unchanged. Three sources of per-frame
garbage and pause on the hot path:
- Game:step / Game:logicSpeed passed inline closures to ModRuntime.call,
allocating a fresh function 60 times per second. Hoist both to
module-level locals; behavior is identical.
- Game:update advanced the incremental collector every rendered frame.
Space it to every 4th frame: the explicit frees the comment refers
to still do the heavy lifting, collection stays incremental, and the
stepping itself stops competing with the 16.6ms frame budget.
- checkEmergencyQuit called love.joystick.getJoysticks() (a fresh
table) twice per frame to guard a 5-second hold combo. Cache the
joystick list and refresh it once per second; a 1s hotplug delay is
irrelevant against a 5s hold.
Tested on an RG351MP (RK3326, dArkOS, v0.2.41): eliminates the
constant walking stutter with all mods off, and with 11 mods
re-enabled. Average CPU is unchanged (the cost was variance, not
load), which matches the diagnosis.
- Updated PresentProbe to measure inter-present cadence accurately, ensuring that ambiguous signals default to FrameCap.
- Refined classification logic to prioritize stable cadence over unreliable hardware gating, enhancing the robustness of frame pacing.
- Adjusted PresentSync documentation to clarify probe isolation and its implications for sync confirmation.
- Improved test cases to validate the new cadence-based gating logic across various platforms, ensuring consistent behavior in frame pacing.
- Updated PresentSync to accurately measure present() block time, ensuring that the probe does not misclassify sync status due to FrameCap sleep artifacts.
- Enhanced FixedStep to implement a hard ceiling on catch-up debt, preventing input starvation during high-speed scenarios.
- Adjusted logic in Game and Game2 to utilize the new catchupLimit function for setting maxAccum, ensuring consistent behavior across speed multipliers.
- Improved test coverage for PresentProbe and PresentSync to validate the new logic and edge cases.
the display sync stuff i added was probing whether vsync was actually working, but it was measuring the wrong thing. during the probe we software-cap at 60 for safety, and the probe was looking at the gap between frames... which includes the sleep 😅 ..... so it always looked like sync was fine even when the driver was ignoring it. on something like the ally x on windows thats a real problem. vsync says on, probe says gated, we lift the cap and snap logic to the panel hz, then youre basically uncapped. at 2–4x that turns into hitching, dropped frames, dropped input, that weird half second freeze. speed swapping wasnt desyncing the driver, it was just making the bad path hurt more.
the solution is just we time present() itself now, not the gap after it, this way the warmup sleep cant fake a pass. if sync is unclear or broken we just stay on a capped 60 and dont snap logic. Also fixed fixedstep so it snaps wall clock dt before applying speed, so in general the 2-4x speed swaps dont screw the pacing math anymore
- Introduced PresentSync module to manage display synchronization.
- Updated love.run() to handle display changes and resizing events with PresentSync.
- Enhanced FrameCap logic to accommodate PresentSync requirements.
- Modified VSync to report effective states and handle driver quirks.
- Updated options menus to reflect PresentSync availability and restrictions.
- Added tests to validate PresentSync functionality and its interaction with VSync settings.
should address issue #1910 and issue #1958
bryanthaboi