luxeengine
project.flow; config settings not reflected
Seems like the project.flow file is being ignored. Settings like window size, project name, etc revert to default. Could be related to AppConfig -> GameConfig change?
Yea I forgot to note that, currently you just set them in the config function like here. (I've added a note to the blog post).
Both ways require a rebuild though - if you wanted to change those settings conveniently without building, you should probably load the settings from config.json and you can change the settings without building.
I'm working on a good way to pass information from flow to the runtime though, it's just a transition thing while fixing up some other issues. Sorry for the inconvenience!
Loading from a config.json file does seem like a better way to handle it. Are you moving away from having these settings in a flow file?
I'm busy clarifying the distinction between build vs runtime, and development vs user facing data in the projects and engine.
Right now I just know that how that information from flow was passed into the runtime was a short stop for convenience, but the same convenience comes from the config function when it's already there (which is why I put it in the empty sample).
There's more than just the window settings, and more than just luxe stuff - the fact that it's build time, and requires rebuilding (and if needed by the IDE, re-setting the project) doesn't make a lot of sense as it stood. Another relevant factor is whether user facing builds use a hardcoded resolution or fullscreen state, it's not as common or useful.
A better form of this type of convenience would be providing a facility to automatically read and apply some config from the config.json file during development, but I want to solve the need of passing data from the build file to the runtime cleanly in a general way - which is part of what I'm solving as mentioned above by the distinctions.
Could it be possible to have if blocks in a config.json file like we have in project.flow? Specifically, I would set borderless to true if building for iOS, and false if no iOS. If not, I think this can be set in Main, which is fine too since it probably isn't something that would change without rebuilding.
yea it's better to code it in main for now. Note that the engine already sets fullscreen + borderless by default here because as a game engine, fullscreen with no status bar is the most common use case on mobile.
That kinda stuff is technically what I'm referring to above btw, a consistent format for developer facing data that has important traits that we need (I'll get into that in the near future).
Oh, didn't realize that was default behavior now. 👍
Jonathan Hirz @jonathanhirz http://jonathanhirz.com
On May 13, 2016, at 6:40 PM, Sven Bergström [email protected] wrote:
yea it's better to code it in main for now. Note that the engine already sets fullscreen + borderless by default here because as a game engine fullscreen with no status bar is the most common use case.
That kinda stuff is technically what I'm referring to above btw, a consistent format for developer facing data that has important traits that we need (I'll get into that in the near future).
— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub