Yo @zep! I think I had a decent brainwave! And I think it's a good bang-for-buck in terms of using existing functionality to get something really useful.

How hard would it be to add a command to the command prompt that simply does what #include does at runtime, i.e. executes some external PICO-8-compatible Lua in the current runtime environment?

For instance, I could load @Mot's cool variable inspector, which is a live, ephemeral dev/debug tool, without having to cut and paste the code in three parts into the command line manually:

> #include inspector.lua
loading inspector.lua
> dinsp(myvar)
[debugging intensifies]

I think #include or even include might be a bit cumbersome for something a dev might want to type often, though. I thought of other alternatives like `import, but I think use might be the shortest verb that still makes sense in the context of an ephemeral-use tool. If we combine that short keyword with functionality that automatically tries to append .lua, that really cuts down the typing necessary at runtime:

> use inspector
loading inspector.lua

I'd also suggest that the command try .p8 and .p8.png as well (not sure about order among the three), but it would only grab the lua section of the cart. This would make working on the dev tool itself a lot easier. It'd just be necessary for a tool author who wants a main loop to create it themself, rather than relying on _update/_draw, which they shouldn't be including since it would overwrite the game's functions.

Another option might be a single-char prefix, similar to ?, to execute something, maybe ! like chatbot commands, and simultaneously switching the filename from a noun to a verb:

> !inspect
loading inspect.p8

That'd really be concise and quick.

So, anyway...

Whatcha think?

😄
🙏🏻

Gets my vote!

Even if it just grabbed the file and executed the lines in sequence in immediate mode (i.e. automating what I often do manually anyway).

And there are a some other tools like a profiler or a memory viewer that would be useful to implement but often won't fit into any reasonably complex cart. (And those are usually the carts that benefit from debugging tools the most.)

@Mot

Yes, exactly! The point would be to allow live debug features without having to spend tokens/chars in an actual cart that's close to the limit. The limiting factor would just be the Lua memory limit, which I think is fine.

Plus, of course, to be clear, the tool would exist purely on the Lua GC heap and disappear as soon as you restart the app and the heap gets reset. Totally temporary/ephemeral. A tool dev could even include a function that deletes the tool so the app can keep running, e.g. maybe dinsp_exit() in your variable inspector's case. It'd probably be a good practice to keep everything inside a single table so all one needs to do is nil the table and maybe a few global exports.

Yes, this could be very handy. I'd like to see it be able to copy carts from the bbs like load does, but it would only pull in the code part. include #my_cart_id

@bikibird

Oo, neat idea! Not sure how much extra work that'd be, I guess it's up to zep if he'd want to go the extra mile, but it'd be great for sharing tools! 👍

This would be super useful. I am keeping an old pico version just to do this by abusing the parser bug that allowed extra code. Prince of Persia for example is close to the limit but the debug feature are necessary to complete it. this would be a life saver.

Btw, this conversation got me thinking about profiling pico-8 code, which eventually resulted in this snippet.

Which I now can't use on my larger games :-) as they don't have a spare 395 tokens, so this thread feels even more relevant.

I also use code for debugging, and in the final stages of development, I may consider separating that code.
We may also comment out some code and reintroduce debugging code after release.

I think it would be easier if there is pico-8 code (lua file or p8 file) that is automatically loaded without any commands (such as #include).

This is custom user code that is read in common no matter which p8 file is loaded.

Custom user code is located at the same level as config.txt and exists as an empty file by default.

Of course, it is not included in png or bin cart exports.

@shiftalow

Ooo, that's a good idea too! Basically autoexec.lua for PICO-8.

I assume this is only for .p8 carts. You wouldn't want extraneous code for other people's .p8.png carts.

You could maybe do a per-cart thing instead/as-well, where it's cart.dbg.p8[.png], and that way it wouldn't tromp anywhere it shouldn't.

Or just load any autoexec.lua that's in the same folder as a .p8[.png], and then you could have your projects in subfolders. Something like that.