libretro / libretro/RetroArch

Save States Not Overwriting SaveRAM in Mupen64Plus-Next

Open
#17,885 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
14.1k
Forks
2.2k
Avg merge
7h 35m
Merged PRs (30d)
51

Description

Is there an existing issue for this?
  • This is a bug in RetroArch frontend
  • I have searched the existing issues
Description

Loading a save state doesn't overwrite SaveRAM in the Mupen64Plus-Next core, even though "Don't Overwrite SaveRAM on Loading Save State" is set to OFF. I'm only experiencing this with the Mupen64Plus-Next core; every other core I've tried is working as it should in this regard.

Expected behavior

Loading a save state should overwrite SaveRAM when "Don't Overwrite SaveRAM on Loading Save State" is set to OFF.

Steps to reproduce the bug
  1. Set "Don't Overwrite SaveRAM on Loading Save State" to OFF.
  2. Save state in any game in the Mupen64Plus-Next core.
  3. Make a hard save after the save state point in the same game.
  4. Load the state, then close and reopen the emulator to see that the SaveRAM wasn't affected.
Version/Commit

1.21.0

Bisect Results

No idea

Present in the nightly version

I don't know

Platform & operating system

Windows 10 Pro 22H2

Affected Cores

Mupen64Plus-Next (2.8-Vulkan 7c7f110)

Environment information

CPU: Intel Core i7-4790K 4.00 GHz
GPU: NVIDIA GeForce GT 1030
RAM: 32GB DDR3 1600 MHz

Relevant log output

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the issue with the Mupen64Plus-Next core using the listed save-state steps and the "Don't Overwrite SaveRAM on Loading Save State" setting set to OFF. Done means loading a state restores SaveRAM to the state’s contents and the result remains after closing and reopening RetroArch.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
game-dev
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.