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

Optional runtime lua script reimport #4769

Open
vakhoir opened this issue Jan 12, 2020 · 7 comments
Open

Optional runtime lua script reimport #4769

vakhoir opened this issue Jan 12, 2020 · 7 comments

Comments

@vakhoir
Copy link
Contributor

@vakhoir vakhoir commented Jan 12, 2020

There's a little hack I've been using for a while, that's a bit too dirty to actually commit, but at the same time it was useful enough that I thought other contributors might be interested. I pushed it to my repo.

First I modified LuaUtils.cpp to skip loading "debug.lua" from cache, so it's always loaded from the file. Debug.lua has the code for all the heavy lifting for whatever view I'm working on (Ship Market in this case), and it's reimported when a tab is refreshed (so when you switch to different tab, and switch back, for example). This lets me work on scripts without having to restart the game with every change that I want to test.

Like I said, it's been very useful to me when working on the UI, so my first question is if others would find it useful as well? If yes, any ideas on how to do it in a non-hacky way? From what I see in LuaUtils.cpp we can check what the script returns on import, so we can check for a "NO_CACHE" flag in the save_to_cache function.

Thoughts?

@Gliese852

This comment has been minimized.

Copy link
Contributor

@Gliese852 Gliese852 commented Jan 13, 2020

or maybe you can call some command in the the lua console to reload ui?

@Web-eWorks

This comment has been minimized.

Copy link
Member

@Web-eWorks Web-eWorks commented Jan 13, 2020

I've been wanting to properly sandbox the UI code and make it fault-tolerant, which would naturally include being able to hot-reload it. At the moment, the biggest issue is that a single uncaught error causes a lua panic, which cascades to a full-process abort()... which is naturally not good when you're debugging lua code.

@vakhoir if you want to handle making sure our Lua-side code works properly under sandboxing, I'm more than happy to start working on this and push my code to a lua-hot-reload branch here on the Pioneer repo or on my fork.

Ideally I'd like to run the UI code in a totally separate LuaState than the game code, but that carries a whole host of issues with it including the ability to inspect a mod's custom variables on e.g. a Ship from the UI code; for now I'd just be happy with the UI code being able to catch its own errors and disable the module responsible.

@vakhoir

This comment has been minimized.

Copy link
Contributor Author

@vakhoir vakhoir commented Jan 18, 2020

@vakhoir if you want to handle making sure our Lua-side code works properly under sandboxing, I'm more than happy to start working on this and push my code to a lua-hot-reload branch here on the Pioneer repo or on my fork.

If you don't think there's anything with a higher priority, I'd love to have that!

@Web-eWorks

This comment has been minimized.

Copy link
Member

@Web-eWorks Web-eWorks commented Jan 19, 2020

@vakhoir will do then! I'll probably start with the hot-reload functionality and try to scaffold out an "error checker" framework that lets us disable UI modules with more fine-grained control. Expect a ui-hot-reload development branch on this repo to send PRs against either today or tomorrow.

As an optional objective, I'll see about a cross-platform file watcher so we can reimport on changes, but don't hold your breath on that one; it's notoriously difficult to get right.

@Web-eWorks

This comment has been minimized.

Copy link
Member

@Web-eWorks Web-eWorks commented Jan 20, 2020

Alright, I've started by moving the Lua-related files out of the main src/ directory so that maintaining everything is a bit more sane. Those commits are published here, and it's what I'll be PRing the new reload functionality against.

If you don't mind, I'll lean on you to do the bulk of the lua-side updating (mostly because you've written about 40% of the pigui code by now); I'll update a couple screens with the error-proofing mechanism once I have all of the C++ side scaffolding done, and then it'll be at your discretion as to which modules you want the check-and-disable to be applied to.

@Web-eWorks

This comment has been minimized.

Copy link
Member

@Web-eWorks Web-eWorks commented Jan 20, 2020

image

...yeah, that's going to take a while to go through.

@vakhoir

This comment has been minimized.

Copy link
Contributor Author

@vakhoir vakhoir commented Jan 22, 2020

If you don't mind, I'll lean on you to do the bulk of the lua-side updating

Will be happy to!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.