Another progress update. It's going very well now, and I'm very happy with where the code is at the moment.
But that's boring, so here are some new features:
Deployment profiles
Different platforms might need different settings tweaked for them, but manually changing these each time before deploying your game is not only tedious, it's error prone as well. To solve that I implemented deployment profiles. Take a look:
Deployment profiles currently allow you to tweak concurrent downloads, as well as image and audio cache sizes per platform, if you so wish. For any environment not specifically defined by you, the "Default" profile will be picked.
There's a list of built-in profiles: Desktop, Mobile Safari (iOS), Android Chrome, and generic Mobile Device detection. Should these not be specific enough, you can create custom profiles that evaluate a script:
I will provide some helpful shorthand methods to fetch things like url parameters and other useful tidbits easily, but you can of course write any script you want here. This should cover common and advanced deployment profile needs.
As I progress, I may add more options to the environment specific configurations.
Common Event preloading - Parallel Process and Autorun
Common Events specified in Events on a map will of course be preloaded, but you may also specify that you want to preload Common Events in general -- parallel processing, or all of them -- on map load:
Battle data
You may choose to preload battle data -- whether only Encounters configured on the map itself, or also Battle Process events:
Battle data preloading preloads not only the battlers and music involved, but also the event pages inside the Troop configurations.
You may notice tin the above image that it mentions "direct designation events only); this is because variable designation and random encounter are unpredictable at map start, so it makes no sense to preload these within the context of events, as their value is impossible to determine.
Battle Scenes will of course trigger their own preloading for unique assets when they start; this feature is simply to frontload most of that waiting time to the map load if you want to, so that the majority of encounters load much faster for the player.
Recursive preloading
Preloading things like events is recursive. Say an event calls a Common Event that calls another Common Event that calls a Battle Process. They'll all get resolved and preloaded.
Oh and in the case your Common Event calls itself -- a very bad idea -- the plugin knows which Common Events it's handled during its preloading process and won't cause an infinite loop to occur
;)
Avoids unnecessary map parsing
Maps that have had their assets already preloaded will completely skip parsing by the preloader when revisited. Due to a smarter cache solution, the plugin detects if its cache has remained untouched by memory restraints since last time the player visited that map.
While parsing a map for assets to preload is generally very fast, the more events and event pages exist on a map, the longer it'll take to figure out which assets need preloading on that map. But if nothing's been removed from the cache since last time this map was visited, the plugin skips that workload entirely.
Thank you for your encouragement everybody!
