Hi I’m worrying about the number of requests that are being made in my build. To explain, for the sake of compartmentalisation I’ve created a lot of small scripts, but each is being requested individually. While this is fine on desktop and the whole thing loads in 2 seconds, on a mobile device the number of simultaneous requests can be limited.
What is the best approach to merge these individual code items together for the final build so as to reduce the number of individual requests (by about half!)
Also the small scripts will probably not be being gzipped as they are too small, whereas if they were part of a larger thing they would be
If you are using Scripts 2.0 (not the legacy ones), then on publish by default scripts are concatenated into single script, unless they are not preloaded.
While you testing in Launch - this still will be individual requests for simplicity of testing.
Also, legacy scripts conceptually could not be concatenated, but new scripts can be, and you can define multiple Script Types within one JS file.
Regarding asset files, if you are hosting your build yourself, you should consider using HTTP/2 to speed up multiple requests to same domain dramatically.
HTTP/2 for Editor and Launcher is something we will be looking at very soon.
For published stuff, is a bit more complicated, especially once they will be behind CDN.
Yeah I pretty much have to use legacy scripts - have a workflow that requires editing here on my machine, using GIT for version control rather than putting everything on PC. (Is that still the case? I can’t GIT integrate and use local version serving with scripts 2?) Would love to use it, but that put me off.
There is no git integration with Scripts 2.0. We will be working on own solution for Branching and Snapshoting.
So using old system, you could try using HTTP/2 to speed up multiple requests to the server.
I understand the preference to use a local workflow, but is it really necessary? You could always periodically download your app’s scripts and store them in parallel in version control. Not ideal, but it would give you checkpointing/diffing.
No debugging and saving fixes in Chrome Developer Tools - I do about 20% of my development in CDT
No auto lookup of symbols across the project - this is my standard development style - the web editor is good, but it really isn’t close to being Sublime or IntelliJ
No reversion to previous version of fixes. IntelliJ local history and GIT give me easy roll back and the ability to compare revisions to find where something was introduced that later breaks a build. I simply wouldn’t entertain developing without that - I’d waste a lot of time.
No automatic refactoring of code for extraction of methods etc. I do this a lot. As do I do symbol and usage searches across a project. Refactoring is vital for me in the middle stages of development on a project
Online editor requires ; in code - I write code without them
I have successfully been able to create a build system that minifies my code and then includes it in the build, monkeypatching ScriptHandler._loadScript to use my compressed stuff. This converts it all into a single request and the code is smaller in any case, which has significantly reduced the loading time.
I do think you guys should implement some kind of performant picking without the need to include 1.8MB of ammo so you can click or tap on an Entity. I’m using my CollisionDetection stuff now, which has saved a big part of the load time and I’m down to 1.2 seconds on desktop.
I do think Scripts 2.0 looks good and fits a really good chunk of the market - it’s a nice upgrade. But these limitations make me feel that it is less suited to a development approach where there are more than one thing going on (server components, project hand overs etc). And developing without full version history feels like a step towards hobbyist rather than professional developer. I imagine I’m in a minority - but I do hope you guys either let me do that with 2.0 or keep Legacy!
Ah the documentation warns against using that on mobile, it’s a pretty big thing to render the scene again for a click I guess, though phones are faster these days. It’s just a simple ray, sphere/cube check in the end I guess.
As mentioned above, we will be looking at refactoring and extending shapes. It is still usable in its current state as shown in this example project but really could do with an OBB as well
Yeah looks good, could do with arbitrary rotations etc. I guess this is what my CollisionDetection library started off as and ended up with basic interpenetration and all that kind of stuff lol. So even that’s a little big. (50k minified)
