Playdate.restart() with [arg] does not work on device, behaves weirdly in Simulator

I sometimes pass a string argument via Lua playdate.restart(“quick”), so I can skip some superflous visuals on the relaunch. (I check for playdate.argv[1] == “quick” on launch.)

On-device this does nothing: playdate.argv is not set by the .restart([arg]).

On the Simulator, things are weirder:

The restart never happens at all (separate bug report) but the command line argument IS stored. It takes affect on next launch—even with a fresh build-and-run of the game, where I’d want that one-time argument cleared.

Even beyond that, the stored argument never goes away: it persists, unwanted, across multiple build-and-runs. To clear it, you must quit and relaunch the Simulator app (this is SDK 2.6.2 on Mac with Nova).

Weirdest of all is the interaction between Simulator and device:

The stored argument from the Simulator’s failed restart() is made permanent on the device, happening at every launch, even fresh from the launcher screen.

The only way I’ve found to clear the argument on device is to quit-and-relaunch the Simulator as above (clearing the arg retained there) then upload fresh to device.

In short:

My game on-device is obeying leftover argument strings from failed Simulator restart()s, but is unable to set and read such strings itself.

As a result, I can’t transmit information across a restart via playdate.restart([arg]).

(As a workaround, I’ll redo this via saving of a little JSON data.)

2 Likes

These are fun ones, thanks for the report! I'm going to dig into this.

2 Likes

A quick update, I partially fixed this in 2.7 beta 9. We now correctly clear the launch args after game launch. What isn't fixed is using the args on device. That is a bit more involved and had to wait.

1 Like

We've got this all patched up (I think) but Will and I disagree on a small point and you get to be the tie-breaker. :slight_smile:

If you launch the simulator via the command line and pass an argument to the game, what happens when you hit the reload button (assuming nothing else has been loaded since, and the game didn't call playdate.restart())? Does it restart the game with the original argument from the command line, or with no argument?

1 Like

Cool! I can’t cast a vote because I never use command line arguments with Simulator!

But I will cast a tie breaker anyway in case nobody else chimes in… I think I’d want the original argument to be repeated? I’m pretty 50/50 though…

Oh yeah this is a h hard one.

I'd also keep the argument. And if you are willing to spend the time, add shift as a modifier to clear the arg. (cmd shift R, shift-click the restart button)

I'm comparing this to Chrome's reload. Which reloads a page retaining cookies normally, but will clear the cache when you hold shift.

1 Like

We are planning on adding a keyboard modifier to clear them on reload, but it won't make it into this release. Probably in 3.0.

1 Like

I’ve returned to this (SDK 2.7.6 but device has OS 3.0). The argument, once set, now seems permanent on BOTH the Simulator and the device. Relaunching the Simulator no longer clears it, and the game on-device inherits the argument from the Simulator and it’s now permanent there as well—so the game doesn’t act right.

How do you clear the argument currently?

(Although I’m not using the command line, just playdate.restart, I’ll do whatever’s needed!)

TIA!

Do you mean relaunching the game in the Simulator; because relaunching the Simulator would definitely clear it unless it’s getting passed back in.

1 Like

Thanks—knowing that, I've found the problem in my code.

(Although now print (pd.argv[1]) at launch never returns anything... somehow arguments are no longer being passed at all from the code pd.restart("quick") which used to work. I’ll try more experiments another day!)

What's arg 0? Iirc we took out the game path arg to match the device so the list is one shorter now.

Good to know, I’ll use argv[0]!

But even so, argv[0] is always nil, both after a fresh launch (expected) AND after pd.restart("quick”).

I test this using print (pd.argv[0]) early in main.lua.

(But that is indeed a change from argv[1] which didn't even return nil.)

That's weird, we tested this pretty heavily when coming up with the new behavior. I'll take a look at it Monday. Thanks!

1 Like

Cool—it’s not mission critical for my game or anything, just a bit of extra polish!

(And if it’s me being dumb, that wouldn’t be the first time.... in the last hour...)

I just tested this on Windows and Mac and it works for me? The first arg is the game, second arg is the argument passed in to restart().

1 Like

That was the solution: you must read argv[2] (not 1 or 0). All working now! Thanks for your time.

(Documentation suggestion: mention in the playdate.restart docs that the passed string is read from argv[2].)

Sure, the args are index 1 based; first is the game name, second, etc are the args separated by spaces.

1 Like

Makes sense! The playdate.restart() docs don’t mention a slot being reserved for the game name (nor does the link from there to argv) so that might be a useful clarification in the docs.

Yes we could absolutely improve the docs here, thanks again for following up on this.