Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change System Time #16444

Open
2 tasks done
jet082 opened this issue Nov 27, 2022 · 7 comments
Open
2 tasks done

Change System Time #16444

jet082 opened this issue Nov 27, 2022 · 7 comments
Labels
Feature Request HLE/Kernel Kernel, memory manager, other HLE issues
Milestone

Comments

@jet082
Copy link

jet082 commented Nov 27, 2022

What should happen

We should be able to change the system time in the settings menu. Currently, it exclusively pulls from the host system time.

Who would this benefit

Some games may break in the future with different dates, some games have special events on specific times, etc. Windows, and quite a few pieces of software with timed licenses, are especially finnicky about changing the system date, so it would be very nice to be able to do so within the emulator itself.

I personally discovered this lack while hacking a PSP game and trying to take apart its save file (which has a bizarre timestamp method that is a massive pain to diagnose having to change the host system time every time I want to tweak something).

Platform (if relevant)

No response

Games this would be useful in

Any

Other emulators or software with a similar feature

No response

Checklist

@NABN00B
Copy link
Contributor

NABN00B commented Dec 16, 2022

Could also be useful for #15617

@hrydgard hrydgard added Feature Request HLE/Kernel Kernel, memory manager, other HLE issues labels Dec 16, 2022
@hrydgard hrydgard added this to the v1.15.0 milestone Dec 16, 2022
@unknownbrackets
Copy link
Collaborator

unknownbrackets commented Dec 17, 2022

You can actually use the API to call replay.time.set to set the unix timestamp (seconds since 1970-01-01), although this of course doesn't help you do anything via the UI. But if you're already using it for romhacking, the debugger API is a reasonable tool to use.

// Get the base RTC (real time clock) time for replay data (replay.time.get)
//
// The base time is constant during a game session, and represents the "power on" time of the
// emulated PSP.
//
// No parameters.
//
// Response (same event name):
//  - value: unsigned integer, may have more than 32 integer bits.

...

// Overwrite the base RTC time (replay.time.set)
//
// Parameters:
//  - value: unsigned integer.
//
// Empty response.

Also, a save state memorializes the timestamp. Another method is to start with "Break on load" enabled, and create a save state before starting CPU execution. Now everything will be constant from that save state and you can always load it for the same base time to be used (as well as randomness and anything else.)

-[Unknown]

@NABN00B
Copy link
Contributor

NABN00B commented Dec 17, 2022

Also, a save state memorializes the timestamp. Another method is to start with "Break on load" enabled, and create a save state before starting CPU execution. Now everything will be constant from that save state and you can always load it for the same base time to be used (as well as randomness and anything else.)

-[Unknown]

You also want to set the time to a specific value before launching a game, otherwise rng will be out of sync eg when replaying a TAS.

@unknownbrackets
Copy link
Collaborator

Well, if you create a save state / set the time literally 0 cycles into emulation, that is before starting the game. The way I run PPSSPP, I have to press the "unthrottle" (fast-forward) button or hit "Go" in the debugger after I load a game for it to actually start. Before pressing that, I can do or configure anything I want before the game starts. PPSSPP has supported this for years.

I've always assumed that would be an obvious component of TAS, but I'm not personally that interested in TAS myself.

-[Unknown]

@jet082
Copy link
Author

jet082 commented Dec 17, 2022

TAS stuff aside, I do think this is still important to add to the UI. There are absolutely games with events/special items tied to the system clock. Gurumin, for instance, has a bunch of these. Moreover, it's not inconceivable that a high enough clock value could just outright break some poorly coded games. It's a bit much to request the average user (especially on mobile devices even) enter a special debug mode or set their system clock to be able to get around this.

@unknownbrackets
Copy link
Collaborator

unknownbrackets commented Dec 17, 2022

I'm not necessarily disagreeing, although there's also a balance to the number of config settings we have.

For example, there's some settings the PSP operating system lets you set and exposes to games: whether to use X/O as a confirm button, whether it's currently DST, date format, time format, etc. There have been pushes multiple times to remove these settings and people from time to time complain they don't work or need "fixing" because games often (but not always) don't respect them.

A system time setting would be respected in all games, but there would be tricky things to changing it mid game. Currently, if you start a game, create a save state, and then load that save state a week later - time doesn't move forward. A save state is literally like you never stopped playing in the "emulated PSP world." But what happens if you changed the system time between those? Maybe even for another game, did you intend for it to cause this game to suddenly reject all your savedata? To give you an error message every time autosave occurs now, and mark saves as broken in memory so even changing system time back won't fix it (from this save state)?

Sometimes to resolve these concerns we add an "ini only" setting, one that can be set via ini for more esoteric use cases. I don't think that'd be appropriate here, because we already have a way to do it at runtime - just not in the UI.

Anyway, I personally think it'd be fine enough to add a setting which impacts the start time with the following constraints:

  • It would actually be an "offset" from the current time. So you might set 2006-01-13 as the date in the UI, but it would actually save an offset of 534154361 seconds. In one week, the time would be 2006-01-20.
  • It would only affect new game sessions, and be disabled while the game is running. Of course, you could change it and load regular save data, just like on a real PSP.
  • Save states would continue to be exact as they are, and time in them would continue from the moment the save state was created.
  • Fast-forward would continue to alter the time (making it move faster), and the configured time would just be the base time - as is the case today.
  • Obviously you could cause a save data corruption "time paradox" in some games by fast forwarding at 2x, creating regular savedata, and then restarting and loading that save data which was created "10 minutes ago", which would be possible on a real PSP too, but far more likely than fiddling with the date/time settings would've been on a PSP.

Also, it might be necessary to set the modification time of save files to the PSP time, which we don't currently do. Maybe that's already a separate problem, although it's probably confusing for a file manager to tell you a save file on your Android device was last modified in 2006.

(I'll also note that something likely needs to be done about this before 2038, because I'm sure there are at least a few PSP games that'll have a Y2K38 problem.)

-[Unknown]

@IrfanH495
Copy link

I only know game gurumin which has events on 1 january and 25 december.
Screenshot_20230101-185357_PPSSPP
the costume will be lost if i correct the date and load the game without save state

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Request HLE/Kernel Kernel, memory manager, other HLE issues
Projects
None yet
Development

No branches or pull requests

5 participants