Replies: 4 comments 1 reply
-
|
Oh cool you're still alive |
Beta Was this translation helpful? Give feedback.
-
|
actually based idea |
Beta Was this translation helpful? Give feedback.
-
|
your suggestion has been implemented in the new java gui(the old one used html) but we are still working on making the mods actually load from the new gui |
Beta Was this translation helpful? Give feedback.
-
|
forgot to say this thanks |
Beta Was this translation helpful? Give feedback.
-
|
new java GUI finished |
Beta Was this translation helpful? Give feedback.
-
I saw in the code that you save and load all of people’s mods from a local storage key as a JSON encoded array of strings containing raw javascript source code. In my opinion this isn’t the most ideal way to store files locally in a browser. Most modern browsers limit the use of local storage to 5 megabytes of data per domain, which will obviously become a problem if people start to get creative and try to bundle assets in their mods using base64 encoded strings. Even if you did introduce an optimized way to store assets you would still need to base64 encode it to store it in local storage keys which takes up around 30% more space than storing them as raw binary.
My suggestion to solve this problem and allow mods to be created that could include hundreds of megabytes of resources is to store the mod files in one of EaglercraftX’s virtual IndexedDB filesystems instead. In the package called
net.lax1dude.eaglercraft.v1_8.internal.vfs2the is a class calledVFile2which contains similar functions to ajava.io.Fileexcept it can be used on the TeaVM runtime to save files to a persistent IndexedDB database that can store hundreds of megabytes of data on the user’s hard drive without the browser complaining. I would strongly recommend changing the code to store mods this way as individual files in the IndexedDB filesystem instead of as JSON in a local storage key. No setup is required besides PlatformRuntime.initialize() which is called when the client launches.Besides using local storage keys I do think you’re on the right track with this project, my only other recommendation is to parse compiled class files to generate the reflection structures instead of parsing the raw source code, since the compiled class files gives the information you’re trying to get about each class in a format that’s machine readable. There are libraries like ObjectWeb ASM that can parse it for you very easily.
Beta Was this translation helpful? Give feedback.
All reactions