gamingislove

@Mochi
Well, if auto refresh is triggered, you'll lose unsaved ORK changes, as that'll cause the whole editor to reload - same as if you change to play mode before saving.
Backups are created (if enabled) each time you save in the ORK editor, and they don't restore automatically, you have to activeley do that in Editor > Backups in the ORK editor. You can load the backup's data there, and it'll only override your current data if you click on save in the editor.

So, just click on save more often if you want more frequent backups :)

Mochi

@gamingislove
Thanks! I'll keep that in mind re backups. Really enjoying exploring ORK by the way, it's an amazing asset.

huulong

This is not exactly a bug, but a limitation that may have been overlooked:

Support Enter Play Mode Options > Reload Domain

The _ORK/_ORKCanvas object is normally generated on start and handles all ORK events. Without it, even the Main Menu won't appear.

In order to Play the game with faster iterations, I often use Project Settings > Editor > Enter Play Mode Options, checking the master box but leaving Reload Domain unchecked (also Reload Scene, but it doesn't matter). However, this causes static members to stop being cleared on game start/stop. As a result, ORK.Instantiated, and other static members, are not cleaned up between session or since they have been set in the editor. Therefore, GameStarter considers ORK to be initialized/instantiated on start and doesn't create the required _ORK/_ORKCanvas object.

Note: ORK is even initialized in the editor as BaseInspector has code like this:

if (!ORK.Instantiated)
		ORK.Initialize(ORKAssetHelper.LoadORKProject());

So even on first play, nothing will appear.

It took me some time to find out the cause, as I always disable Reload to get a much shorter (almost instant) startup time. The Main Menu was not appearing at all and I had to start a new project from scratch to identify the difference was in that setting.

My workaround was to copy the core part of GameStarter into my own script, that skipped ORK.Initialize and always Initialize ORK. I also needed to ORK.Game.LoadMainMenuScene() even if already on the main scene (probably to refresh the state). I don't know if the same behavior would occur even if ORK wasn't in a DLL.

Although the Enter Player Mode Options have been experimental for a long time and are not guaranteed to work on every project, it would be nice if there was a way to support Reload Domain. Possible ideas:

preference in ORK Framework for an alternative way of initializing the framework when in the editor, that would support no Reload Domain.

A. A preference or an editor-only member on GameStart script to force initialization:

(Experimental) Force ORK Initialization: "Always initialize ORK in GameStarter. Check this to support playing the game with Reload Domain unchecked, but it may have side effects."

B. Clear static members on game start, following examples in https://docs.unity3d.com/Manual/DomainReloading.html

Thank you

TextusGames

I am also using fast enter paly mode (without domain reload). It makes entering play mode almost instant. All third party assets which I am using supports this.
It would be good if ORK support this too.
Overwise I will not be able to use fast enter play mode. That will slow down my play iterations.

@gamingislove Is there any plans to support no domain reload?

huulong

Second bug report in a row (I'm just starting using the framework and prefer reporting things as early as possible)

Unsaved data doesn't prompt for save on close tab/Play

Currently, I must make sure to always Save Settings and Confirm changes after each data change. Closing ORK Framework tab, or playing the game will make me lose my changes. This thread: http://forum.orkframework.com/discussion/4581/solved-ork-asking-to-save-settings-when-no-changes-are-made suggests that a prompt feature exists (the thread is about the opposite issue, having prompt spammed despite no changes).

I'll sum-up the save behavior step by step. Note that most steps are associated to a suggestion, that I can rewrite in the Feature Request thread if you want. But what I'm really talking about now if the bug at point (d), because it should be fixed first. Then you can implement the quality-of-life suggestions little by little if you want.

a. Manual save is always required. It may be useful to have a global preference to enable auto-save after field change (suggestion)
b. When clicking Save Settings manually, we must always go through the diff screen to Confirm. Which is a good idea to avoid unwanted changes on important data, but during fast prototyping is a bit overkill. It may be useful to have a global preference to skip changes Confirm (suggestion)
c. Even when changes are shown, it only tells which data group is changed (e.g. factions), not the details of change, so it is only useful to avoid changing things in the wrong group, not to avoid changing the wrong fields by accident. It may be useful to display the detail of field change, with old and new value (suggestion)
d. If not confirming save, closing tab and Play game do not prompt for save. User may assume that the changes were taken into account, at least temporarily for the next Play session. But actually, they are reverted. Apparently a prompt feature already exists, so this should trigger (bug)

huulong

Bug in Editor: Game view is Maximized when clicking on any tab in same panel during Play

Repro:
1. Put several tabs, e.g. Scene and Game, onto the same panel (e.g. when Game view is visible, it should hide the Scene view)
2. Play in the editor. Game view should be focused even if Scene view was visible.
3. Click on another tab on the same panel as Game, e.g. the Scene tab.

Expected: view switches to other tab (Scene), hiding Game view
Actual: Game view is Maximized

More generally, clicking *anywhere* on the top bar on which Scene, Game and other tabs are listed, will toggle Maximize.
So by clicking there again, Game view again will be Minimized again. But you still can't switch to the Scene view...
This makes it harder to debug Play mode, and requires you to move the Scene view to another panel.

gamingislove

@huulong
That sounds more like a Unity issue - ORK has no control over this.

huulong

@gamingislove It could be, but I tested a project with and without ORK, and the project without ORK didn't have the bug.

Do you have it on OSX/Windows? It may also be a Linux thing (in this case I can send a bug report to Unity, but I don't know to which extent they'll accept to debug third-party code).

If you can reproduce it on your platform, then could you have a look at what's causing this? Once you found the issue, if it's actually out of your control, either I or you can send the bug report (maybe as an asset developer, you'll have some more weight?) If you cannot find the cause at all (or you lack time searching), same thing, either of us can send the bug report. I'm fine sending it, but if you wanna track the resolution state, you may want to do it as well. Just tell me if you're taking over.

gamingislove

@huulong
Definitely not happening here on Windows. How's the ORK editor involved in this when it's happening?
Is it just open or also docked to the same panel? Or is it not opened at all?

huulong

@gamingislove It happened even with ORK/Makinom and Scene Wizard tabs closed... as if the DLL tself was registering some event on start.

I unchecked Reload Domain in Project Settings > Editor > Enter Play Mode Settings to see (it is known not to start ORK, see my other post more above), but the bug was still present! So maybe some editor event registered by ORK independently from the runtime DLL?

gamingislove

@huulong
There's definitely nothing like that going on when the editor is closed, only if the ORK/Makinom editor is open it'll listen for play state changes to save some editor data, but nothing that'd cause any other window to change size or go full screen.

braytendo

In my battle start event, if I store the music of the current scene before loading a battle scene and then return to the previous scene after the battle, it breaks the looping of the stored music (the check time and set time is ignored and the track loops to the beginning from the end of the track). The settings for the song I discovered this on are as follows:

loop clip: checked
use start PCM: unchecked
start time: 0

(Loop 0)
end loop: unchecked
keep looping: unchecked
use PCM: unchecked
check time: 124.023
set time: 11.29

I'm using ORK version 2.33.1 BETA and Unity version 2019.1.5f1

gamingislove

@braytendo
Hm, is playing the stored music done before or after the scene change?
If it's after, it's probably due to the music player in the scene starting to play the track already - this'd prevent playing it again (even from a different position), as playing the same clip is ignored.

braytendo

oh, yes, the stored music is being played after loading the stored scene. I'll check if playing it before loading the scene fixes the issue.

EDIT: Nope, it's still playing all the way to the end. It plays from the correct stored position, but it's not looping back at the check time to the set time like it should.

I can send you an example project of the issue if that helps.

gamingislove

@braytendo
I'll check it out.