Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[0.90] Watcher fails when loading multiple carts #1494

Closed
scambier opened this issue Jul 18, 2021 · 9 comments
Closed

[0.90] Watcher fails when loading multiple carts #1494

scambier opened this issue Jul 18, 2021 · 9 comments
Assignees

Comments

@scambier
Copy link

For my bundler, I need to load 2 carts into TIC-80 :

  • The first one (game.fnl) contains all the assets, and may contain code (that should be ignored)
  • The second one (build.fnl) contains the always up-to-date bundled code

I'm using the following args for TIC-80:

"--skip --fs=C:\\(etc.)\mygame .\\game.fnl --cmd load .\\build.fnl code & run"
  • The code from build.fnl is ignored until I exit the game with esc, at which point it is loaded into the editor
  • The game runs as intended, with code from build.fnl and other assets from game.fnl
  • Now if the contents of build.fnl change, TIC reloads this file as the whole cart, and consequently "unloads" game.fnl and loses all the non-code assets
@scambier
Copy link
Author

scambier commented Jul 19, 2021

One more thing: in 0.80, once I load game.fnl (the cart with assets) and inject build.fnl (the code alone), all changes done within TIC-80 are saved inside game.fnl. That's an excellent behavior as it keeps assets and code decoupled. I'd love it if this behavior was unchanged in 0.90, once the watcher is fixed :p

Thank you!

@nesbox
Copy link
Owner

nesbox commented Jul 22, 2021

I think it's outside of TIC possibilities to watch all the carts you load into it, the watcher looks for the only cart loaded using load command. In your case, it's better to join all the assets outside into one cart.fnl = assets.fnl + code.fnl + ... with your tool/bundler and only then run tic80 cart.fnl.

The code from build.fnl is ignored until I exit the game with esc, at which point it is loaded into the editor

Here it's better to use command tic80 --skip --fs ...\mygame --cmd "load game.fnl & load code.fnl code & run" because it runs cart after code is imported, and TIC will look only for game.fnl changes.

In the commit e4c8372 I disabled cart watching if you load a section (code, tiles, ...) from a cart.

@nesbox nesbox closed this as completed Jul 22, 2021
@nesbox nesbox self-assigned this Jul 22, 2021
@scambier
Copy link
Author

@nesbox I understand totally that watching multiple files and reloading them correctly is out of scope for TIC-80, but would it be possible for ctrl+r to "re-execute" the CLI args?

For example, using tic80.exe --skip --fs=.../mygame --cmd load .\game.fnl & load .\build.fnl code & run: without necessarily watching those files, a ctrl+r could re-execute the load .\game.fnl & load .\build.fnl code & run argument and thus reload the files from disk.

In your case, it's better to join all the assets outside into one cart.fnl = assets.fnl + code.fnl + ... with your tool/bundler and only then run tic80 cart.fnl.

That's a possibility, but if I edit the assets within TIC-80, those will be saved inside cart.fnl, which is a build artifact, and will be overwritten once the code changes. It could be worked around, but that flow is becoming quite complex. It's unfortunate because that worked quite well in v0.80, even without the watcher: load both files, edit assets in TIC, edit code in your IDE, hit ctrl+r, your game was up-to-date without any file conflict (or additional read-writes from the bundler).

I'm asking this because TIC-80 games can be quite big (in lines of code count), and bundlers are a necessity IMO. So I just think they should be as frictionless as possible.

@nesbox
Copy link
Owner

nesbox commented Jul 26, 2021

would it be possible for ctrl+r to "re-execute" the CLI args?

We could add a command-line parameter to "re-execute" the --cmd commands on ctrl+r.
How to call it, what do you think? :)
Maybe, something like --keepcmd

@scambier
Copy link
Author

Nice, thanks! --keepcmd should do it, I cannot find a clearer & short name for it :)

@nesbox
Copy link
Owner

nesbox commented Jul 26, 2021

ok, let's do it then

@nesbox nesbox reopened this Jul 26, 2021
nesbox added a commit that referenced this issue Jul 30, 2021
@nesbox
Copy link
Owner

nesbox commented Jul 30, 2021

Added --keepcmd command line parameter f9be293

@nesbox nesbox closed this as completed Jul 30, 2021
@scambier
Copy link
Author

@nesbox I just tried and it seems to be working perfectly for my workflow! Thanks again, it's really great!

@nesbox
Copy link
Owner

nesbox commented Aug 15, 2021

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants