Famobi19's Forum Posts

  • 4 posts

  • Thanks for your feedback, but nope.

    As you can see from my fix parentElement is "undefined" here. Neither "window" nor "a". Otherwise the error would happen earlier.

  • Hi,

    I'm a little confused, so I don't know if this fits in this forum or not:

    I have a project in which I use the following behavior:

    construct.net/en/make-games/addons/544/bound-viewport

    During the export I encountered the first problem yesterday: An error that I also wrote on the linked page.

    I fixed that and was able to export successfully. However, when I start it, I get an error in main.js:

    I didn't see anything related to the addon until I removed it and re-exported and ran it again:

    The error has disappeared!

    So I just added another condition 

    &&typeof a.parentElement!=="undefined"

    to fix it, but of course that can't be the solution.

    What can be the reason? I created an empty project that also uses this behavior and the error doesn't come up. Hence my confusion I mentioned at the beginning.

  • Background: I want to encrypt the LocalStorage entries for games.

    Basically it's not a problem if I override setItem and getItem. With Construct2 games it was still possible to tell the localForage via "setDriver" that it should use LocalStorage instead of Indexed DB.

    If I understand correctly, this is no longer possible with Construct3, correct?

    What would I have to do with Construct 3? It would be important for me to be able to do this from "outside". The last possibility would of course be to write an addon, with which the data is decrypted/encrypted and can be used in the editor.

    However, I would like to avoid that!

    What would I need to address that basically takes care of writing and reading the data?

    Thanks in advance!

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • We sold a game to a customer and he gave the the following feedback. Maybe you have a solution for this?

    I’ll try to describe the issue as we faced and how we were able to drill down to the probable cause:

    Context on what we are doing:

    For loading the game on the android app, we download and cache the whole game bundle locally to reduce the download time for subsequent game loads. We leverage the request interceptor functionality of WebView to intercept the network request and then use the WebViewAssetLoader to load the response for the intercepted request from internal storage.

    Issue we faced:

    For android devices with Android 10 and lower, the game is unable to load from the local cache. Loading works fine if we load from the internet.

    The following error is observed:

    I/chromium: [INFO:CONSOLE(0)] “Failed to load module script: The server responded with a non-JavaScript MIME type of “text/plain”. Strict MIME type checking is enforced for module scripts per HTML spec.“, source: https://d2cx3uugochcmv.cloudfront.net/h5-game-bundles/smp_pets_rush-v15-pr_basic_table/scripts/c3runtime.js (0) I/chromium: [INFO:CONSOLE(27)] “Uncaught (in promise) #<Event>“, source: I/chromium: [INFO:CONSOLE(27)] “Uncaught (in promise) #<Event>“, source: https://d2cx3uugochcmv.cloudfront.net/h5-game-bundles/smp_game-v15-pr_basic_table/scripts/main.js (27)

    Debugging the issue

    From the error message, it seems that MIME type for the js files being loaded from the cache are being reported as “text/plain” instead of “application/javascript”. The MIME type is inferred by Android’s WebViewAssetLoader when it loads the game assets from internal storage.

    This seems to be the behaviour in pre Android 10 devices and is happening for all our games. For post android 10, the MIME type inference works properly for js files.

    If MIME type reporting is broken then why other games are not affected?

    If we revisit the above error log, we can see the following clause: “Strict MIME type checking is enforced for module scripts per HTML spec”

    This means that if we are using js modules in the games, then this issue will occur. It might be possible that other games are not using js modules while the game is using them.

    Goin through the code for the other games, we found out that js modules are not being used in those. Hence, the issue does not arise for other games.

    Earlier game version is unaffected? What changed?

    Comparing the diff between earlier and current versions of the game, we found out that indeed, js modules are being used now. In the AddScript function in c3runtime.js, we are dynamically adding script elements with type “module”. This change is not there in earlier versions. There are other instances too, but this one was the most obvious.

    Conclusion

    Since, the game asset loading on pre android 10 devices is not working due to this issue. I suggest we remove the use-cases of javascript modules from the game. This is because it is unknown what causes the MIME type issues in these devices. Until then, to get things working we might have to make this change.

    If you guys have any insights into the MIME type issue such that it can be resolved without removing js modules, please let us know.

    The initial build did not have this dependency on js module.

    Can you crosscheck, if we can remove the dependency because its something that only got added on later

    Thanks and Regards,

    ------

    What could be the best solution. No idea what feedback I could give them. Could you help me/them?

    THANKS IN ADVANCE

  • 4 posts