orta / vscode-playdate

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Update launch arguments to the expected values

willco007 opened this issue · comments

Panic engineer here. :)

When using this extension the Launch Request arguments are not using the expected keys. They are currently are "source" and "output".

The Simulator expects "sourcePath" and "gamePath" and optionally "sdkPath".

Please let me know of that doesn't make sense, thanks!

👋🏻

This took me a while to grok, because all the usage for launching the CLI is positional inside the codebase. E.g. we never use those as keys, only for internal logic.

That said, what I think you're saying is that the names we've chosen for settings inside this vscode extension are not consistent with the terms used inside the playdate sdk.

I think it makes sense for us to switch to sourcePath etc to keep the setting names consistent (ideally without breaking backwards compatibility)

You're getting the idea. :) If the extension switches to use these named values, the Simulator will open the game when sent the launch request automatically (no CLI args needed), for example. Going forward, if you want to add any more features to this extension, it will need to launch the game with these arguments to set up the debugger correctly.

It makes sense to keep the old way of working, for older versions of the Sim, while also adding the new values for proper support of the Sim.

Thanks - looks like we're talking about these debugging keys:values also - https://github.com/orta/vscode-playdate/blob/master/src/MockDebugSession.ts

@orta yup, those are the ones.

You'll also need to send the configurationDone request after the launch request to tell the Sim you're done with any configuration, then it will launch the game.

I still don't really get the issue here since I can't find those references and also because this extension works fine for me with latest SDK (1.12). I don't find anywhere in pdc or the simulator where I can use any named arguments. In fact, if I look at the arguments for pdc they're just called input and output:

$ pdc | head -4
usage: pdc [-sdkpath <path>] [-s] [-u] [-m] [--version] <input> [output]
  input: folder containing scripts and assets (or lua source, with -m flag)
  output: folder for compiled game resources (will be created, defaults to <input>.pdx)
  -sdkpath: use the SDK at the given path instead of the default

I tried to see what references there were to either sourcePath or gamePath but the only thing I find when Googling is for sourcePath and that's from this other Playdate Debugger for VS Code: midouest/vscode-playdate-debug.

I don't find any reference to either of those in the Inside Playdate documentation or Designing for Playdate documentation.

@willco007 Would you mind pointing out where in the simulator these flags or names are referenced and how we should use them from this extension (or how they're used in general)? Also can you confirm this is the right plugin and that you did not intend to add this issue in midouest/vscode-playdate-debug?

You'll also need to send the configurationDone request after the launch request to tell the Sim you're done with any configuration, then it will launch the game.

Hmm, is this a problem for you? We don't use the configuration API and all we do is spawn the process just like from command line. Afaik the Simulator does not know that it got spawned from VS Code since this is not a real debugger that actually attaches to anything or implements the DAP. Does this plugin not work for you or did you mean that as good practice?

OK, so right now this extension launches the game via the CLI interface but also declares itself as debugger extension. Therefore, VS Code must be sending the Launch event (and others) on your extensions behalf with the values specified in the launch.json file.

Since the extension is not sending the correct values to the Simulator, the Sim doesn't process the Launch event correctly and VS Code doesn't think the Simulator is actually launched (you can see this by the constant indeterminate process bar in the interface) when running a game from VS Code.

While using the CLI is fine, it is technically not the correct way to launch the Simulator with a game while using a debugger extension and will cause some internal issues with the Simulator (such as not replying to VS Code's Launch event with the success message).

The key values I've listed are undocumented, but should be used in the VS Code Launch event (by defining them in the Launch.json file noted above). If you do that, the Simulator will correctly process the rest of the default events coming from VS Code. I have tested this with your extension already by modifying the values myself.

Thank you for the clarification! Since this is just a mock debugger that doesn't use any proper debugging mechanisms I didn't follow (and also I have limited experience with VS Code debuggers, heh). I actually suggested removing the whole debugging feature in #13 but we ended up keeping it since some people are used to hitting F5 to launch the simulator even if it doesn't provide any real debugging features.

We should probably also look into a real Debugger Extension at some point but I need to dig deeper into this.

Until then, updating the arguments sounds like a good start!