Log In  


The typical external editor workflow keeps a .p8 file open in both PICO-8 and a text editor. The author edits code in the text editor, saves the file in the editor, then presses Ctrl-R in PICO-8 to reload and run the new version. The author also edits sprites, map, sfx, or music in PICO-8, saves the file in PICO-8, then reloads in their editor (automatically in some editors).

To prevent a potential accident, PICO-8 has a failsafe that blocks Ctrl-R with a warning message if it detects that the cart has changed in memory since the last time it was saved from PICO-8 and the file on disk has been updated by an external editor. PICO-8 makes no further attempt to help resolve the merge conflict: it's up to the author to rescue the external edits, save the cart from PICO-8, then re-apply the edits.

This failsafe considers the entire cart—code, graphics, sound—as a single document for this purpose. This makes triggering the failsafe common in the typical workflow: even when the author uses the external editor exclusively for code and the internal editors exclusively for art, failing to save changes in one before making changes in the other will block reloads.

I don't expect PICO-8 to merge two sets of changes to the same section, but it seems like it would be an improvement if PICO-8 can do dirty data detection on each section individually, or perhaps just "code" and "everything else." If PICO-8 has unsaved changes only to non-code and the file on disk has changes only to the code, Ctrl-R can silently load just the new code from disk and preserve non-code changes in memory.

Sound good? Anything I'm missing?

1


2

... A workaround to achieve the desired effect is to store code in a separate .lua file then #include it from the cart. The Ctrl-R failsafe will not trigger if both the .lua file and the internal art have changed, but it will reload the .lua file from disk when it runs the cart.


Thats what I would suggest using includes for the moment.

But yes I frequently run into collisions cause I edit code externally and then sprites from within pico-8.

A simple in memory hash of spritesheet / map and audio (each seperately) should be fairly easy to keep.



[Please log in to post a comment]