TIC-80
TIC-80 copied to clipboard
nesbox
Suggestion: Add filesystem ability to TIC-80
It'd be really useful if TIC-80 had access to TIC-80, albeit a locked-down version of the filesystem that won't let a rogue TIC program delete system files like System32. Before, we had to resort to solutions like saving data to the spritesheet or the map, and syncing it to the cart.
No one: Literally no one: Some random tic-80 cart game: sequencing SYSTEM32 removing procedure
BTW this might be cool if you will add possibility to create only one file which will store up to 256 values which is pmem XD What do you mean "It's already existing in .local"? Ahh, god dammit
And to clarify: I meant adding the ability to read and/or write to the filesystem, as well as creating new files (with a cap on how many files a program can create so it doesn't fill up the hard disk space and/or crash TIC-80), deleting new files (with restrictions on what it can delete, so as to not make it possible for a TIC program to exist that deletes the operating system or deletes important files necessary for the operating system to operate), and creating/deleting directories with the same restrictions as creating/deleting files.
Personally I'd say this is incredibly out of scope and not going to happen. :-) Entirely against the minimal nature and restrictions of the system, just to name one HUGE problem. (before you ever get to security issues)
Now if someone built a fake file API on top of pmem or saving RAM to the cartridge that might be interesting... but IMHO something like a key/value store would be far simpler (and more useful) than a full on filesystem... (you could still use / in the keys)
MAP is the largest bank... if one allotted say the top 4 MAP banks to data storage you'd have ~ 128kb of permanent (inside cartridge) storage to play around with... and with some nice APIs it'd be pretty easy to use/access... of course this work would need to be done PER runtime.... but some of the design work could perhaps be done globally.
Personally I'd say this is incredibly out of scope and not going to happen. :-) Entirely against the minimal nature and restrictions of the system, just to name one HUGE problem. (before you ever get to security issues)
Now if someone built a fake file API on top of
pmemor saving RAM to the cartridge that might be interesting... but IMHO something like a key/value store would be far simpler (and more useful) than a full on filesystem... (you could still use/in the keys)
MAPis the largest bank... if one allotted say the top 4MAPbanks to data storage you'd have ~ 128kb of permanent (inside cartridge) storage to play around with... and with some nice APIs it'd be pretty easy to use/access... of course this work would need to be done PER runtime.... but some of the design work could perhaps be done globally.
You can't save game by map not saving game manually, which makes impossible to save game in browser or in exported alone.
You can't save game by map not saving game manually, which makes impossible to save game in browser or in exported alone.
I don't understand. Are you saying the sync api is entirely broken in both browser and export?
It'd be really useful
How?
had to resort to solutions like saving data to the spritesheet or the map, and syncing it to the cart
What is wrong with this type of persistence or what prevents it from being equally useful to you?
You can't save game by map not saving game manually, which makes impossible to save game in browser or in exported alone.
I don't understand. Are you saying the
syncapi is entirely broken in both browser and export?
I meant that in order to save changes to .tic file after sync you need to manually save cart by "save" or ctrl+s. This savesystem not working in exported with alone=1 and maybe in browser.
Hmmmm, I seem to remember this now - yeah if the cart isn't auto-persisted that greatly reduces the utility of using the extra banks for save state... that just leaves you with the 1kb of PRAM.
I wonder if auto-persist perhaps should be an option or something - or it could be this is quite intentional.
@nesbox Was cart bank persistance ever intended to be used for any type of save state? And if that's "ok" usage then shouldn't we have some type of auto-save so those changes are actually persisted to the cartridge? And if it's not OK usage then I guess that's that...
I imagine you're likelier to get auto-persisted cartridges than you are write access to the filesystem...
I imagine you're likelier to get auto-persisted cartridges than you are write access to the filesystem...
Auto-persistence is quite a good compromise, if we can't get access to the filesystem.
By design, you will see a confirmation message if you have changed the cart using the sync() API, the message appears when you close the game.
By design, you will see a confirmation message if you have changed the cart using the
sync()API, the message appears when you close the game.
would be great if it wont ask a confirmation and write'n'save data immediately.
I think it's been explained clearly here why we won't be allowing access to the actual filesystem, so closing this issue.
would be great if it wont ask a confirmation and write'n'save data immediately.
Perhaps create a new issue to discuss the pros and cons? I can think of several, but I'll save them for that issue so they don't get lost here.
i need to write csv data to a file to run a stats model and diagnosis an issue
