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

customizable player loading progress screen #40

Closed
wants to merge 7 commits into from

Conversation

kajott
Copy link
Contributor

@kajott kajott commented Feb 2, 2019

The look of the player's loading screen can now be customized by defining a custom operator that draws it and defining a property called "LoaderProgressOperator" with the operator's meta ID in ProjectSettings.json. The operator will then be rendered instead of the normal loading bar, with t=-1 seconds at the start of loading and t=0 second at the end.

Reasonably comprehensive documentation is included, including information about the two things that don't work properly, namely missing updates in the "pre-caching" phase at the end of the loader and broken default camera settings that need to be worked around.

The look of the player's loading screen can now be customized
by defining a custom operator that draws it and defining a
property called "LoaderProgressOperator" with the operator's
meta ID in ProjectSettings.json. The operator will then be
rendered instead of the normal loading bar, with t=0 seconds
at the start of loading and t=1 second at the end.
no more fatal exceptions if the GUID is malformed
or the operator .mop is missing
The time for the custom loader operator is now mapped
differently: instead of 0...1, it's -1...0. This makes
it more natural to work with: Now, the loader is conceptually
running in the second just before the demo (except that this
"second" may in reality take much longer than that). It no
longer overlaps part of the timeline. This also makes seamless
transitions from the loader into the first scene easier.
Includes the explicit Camera operator work-around
against broken default camera settings.
@drcynic
Copy link
Member

drcynic commented Feb 2, 2019

Hi KeyJ,
thanks for this feature. One thing, can you select the develop branch as merge target? The master is meant for released versions only. I'll take a deeper look into the code tomorrow, when I'm back at my computer. A first glimpse looked fine.

@drcynic
Copy link
Member

drcynic commented Feb 3, 2019

Ok, the code changes itself are fine. I think I would have removed the hardcoded progress bar and put this in an operator too and this one set as default operator to use for progress visualization. Anyhow this can (or not) be done later. This only leaves the merge target branch that would need to be changed.

@kajott
Copy link
Contributor Author

kajott commented Feb 4, 2019

I selected master instead of develop because master is currently ahead of develop, making develop look like an abandoned branch. But if you want, I can still rebase to develop and make a new PR.

@drcynic
Copy link
Member

drcynic commented Feb 4, 2019

Hmm for me it looks like both have the same state:
image
So I would prefer merging it to develop (this is also the branch we do all modifications on). After your changes got merged to develop we can increase the version and update master to the latest state.

@kajott
Copy link
Contributor Author

kajott commented Feb 4, 2019

image
You're right, master and develop are indeed equal. The web interface disagrees for some reason though, and that's what I based my decision on.

I'll do a new PR based on develop now.

@kajott kajott closed this Feb 4, 2019
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

Successfully merging this pull request may close these issues.

None yet

2 participants