Browser caching

Post reply
0 favourites
  • 15 posts
From the Asset Store
Building "Collapsing Blocks" Browser Games
$7.99 USD
This is a single chapter from the Construct Starter Kit Collection and the Student Workbook from the Workshop.
PBMCube's avatar
PBMCube

  • Hi,

    problem statement as follows. I deploy a game on an NGINX server having used the export functionality of construct 3. Now after a first deployment I had to correct a bug.

    Reploying the game on the website (I SFTP the corrected filed) didn't result into the bug fix being applied, I had to hard reload the game in Chrome in order to make it work.

    So I checked a couple of older caching threads, but they never provided any concrete solutions.

    Is there a way to allow caching, but disable it when the files are updated via export?

    Any other experience?

    LegacyTRX

    Tagged:

  • I'm having a big problem with caching as well.

    I host games on my website and I have about 350-450 people playing these games each day. I noticed that when I do an update, I've been getting a lot of calls that the web apps are broken. Then I realized the caching problem (which I now see frequently on my side). I tell my customers to delete the browser's cache, however I use a lot of local memory and the player will lose a lot of stuff (not a happy customer). I realized that I can tell them to open up F12 and then do a refresh and it will completely update (in Chrome and Edge). But my players are not tech savvy and this is too much for them.

    I rename the project with every update, but sometimes parts update and other parts don't. So if I added a new sprite, it won't be there, but the new revision is listed. When I go into F12 and do a refresh, then I see the sprite. So, parts update and parts don't. Not good.

    This is driving me crazy. I would love to do updates, to give my customers weekly notifications of new things going on, but I can't risk breaking the app for them since my apps are tied to books, and when the apps don't work they can and will give a bad Amazon review (a bad risk to take).

  • I've been wiping everything before uploading a new version. I guess because of the way sprite sheets are generated they may be different in different exports while retaining the same file name. In that case things will look messed up ( Code pointing to images on a sprite sheet that now in the new version does not contain those same images, or in the same order.

    So, I really don't see a solution, if you really want to be sure everything works, other than having them download everything again with each new export. This should make sure all sprite sheets are correct and they will not lose any data saved in local storage since they are not clearing their cache.

    Of course they still may have to refresh the page once in a while.

  • If you have control of the server, and what ever method is used to point to the game, then a different directory is by far the most dependable method.

    Its also better for testing, version control, etc.

  • If you have control of the server, and what ever method is used to point to the game, then a different directory is by far the most dependable method.

    Its also better for testing, version control, etc.

    The problem with doing it this way is, for people already using the game, the browser will set and get local memory from a new area, so they will be starting all over (unhappy customer).

  • This is my fix for the caching problem (I'm still testing it and it seems to be working).

    Create an .htaccess file that will tell the browser not to cache certain files. I chose to not cache the following files with the extensions: css,html,js. I do want to cache my images and audio files.

    Make an .htaccess file (in the root directory of the export files - where the index.html file is) with the following code:

    RewriteOptions inherit

    # php -- BEGIN cPanel-generated handler, do not edit

    # Set the “ea-php56” package as the default “PHP” programming language.

    <IfModule mime_module>

    AddHandler application/x-httpd-ea-php56 .php .php5 .phtml

    </IfModule>

    # php -- END cPanel-generated handler, do not edit

    # DISABLE CACHING

    <IfModule mod_headers.c>

    Header set Cache-Control "no-cache, no-store, must-revalidate"

    Header set Pragma "no-cache"

    Header set Expires 0

    </IfModule>

    <FilesMatch "\.(css|htm|html|js)$">

    <IfModule mod_expires.c>

    ExpiresActive Off

    </IfModule>

    <IfModule mod_headers.c>

    FileETag None

    Header unset ETag

    Header unset Pragma

    Header unset Cache-Control

    Header unset Last-Modified

    Header set Pragma "no-cache"

    Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"

    Header set Expires "Thu, 1 Jan 1970 00:00:00 GMT"

    </IfModule>

    </FilesMatch>

  • I've been wiping everything before uploading a new version. I guess because of the way sprite sheets are generated they may be different in different exports while retaining the same file name. In that case things will look messed up ( Code pointing to images on a sprite sheet that now in the new version does not contain those same images, or in the same order.

    So, I really don't see a solution, if you really want to be sure everything works, other than having them download everything again with each new export. This should make sure all sprite sheets are correct and they will not lose any data saved in local storage since they are not clearing their cache.

    Of course they still may have to refresh the page once in a while.

    You really don't have to wipe out everything. If you export to HTML just overwrite your files and then open the game. If it didn't go to your latest and greatest, open F12 then hit refresh (Edge and Chrome). I used to always clear my browser, until I realized I could do this.

  • Supposedly you can do all that via the Browser plug using "on update found", and "on update ready" followed with a "reload" given that you have uploaded a new offline.json with the new export.

    construct.net/en/tutorials/offline-games-construct-8

    I'm thinking that this being tied to the offline settings is causing some confusion.

    Here's a simple project to show the basic idea.

    Export and upload the project then add some content and re export and upload again.

    dropbox.com/s/joqtfag6eptv0jj/updater.c3p

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • When I say wipe out everything, I meant everything in the game folder, not my browser cache.

    Overwrites will happen only if there is exactly the same number of files and with same names

    I do this because Construct creates sprite sheets and gives them names without my input. It is possible that a different export will have more,fewer and/or differently named sprite sheets, so if your javascript files do not all update you get code pointing to a sprite sheet that is still there from the old version and a screen that makes no sense ( random sprites all over the place )

    So just to be safe, delete everything, then opload the new export

  • Supposedly you can do all that via the Browser plug using "on update found", and "on update ready" followed with a "reload" given that you have uploaded a new offline.json with the new export.

    https://www.construct.net/en/tutorials/offline-games-construct-8

    I'm thinking that this being tied to the offline settings is causing some confusion.

    Here's a simple project to show the basic idea.

    Export and upload the project then add some content and re export and upload again.

    https://www.dropbox.com/s/joqtfag6eptv0jj/updater.c3p?dl=0

    I'm confused how this works. Shouldn't there be a line that checks the local memory to see if the browser should be reloaded?

  • When I say wipe out everything, I meant everything in the game folder, not my browser cache.

    Overwrites will happen only if there is exactly the same number of files and with same names

    I do this because Construct creates sprite sheets and gives them names without my input. It is possible that a different export will have more,fewer and/or differently named sprite sheets, so if your javascript files do not all update you get code pointing to a sprite sheet that is still there from the old version and a screen that makes no sense ( random sprites all over the place )

    So just to be safe, delete everything, then opload the new export

    I didn't think doing this was necessary. I do see the sprite sheets changing, but I just have to make sure to send them out to the server with all the other files. When I forgot, I did see strange things in the layouts!

  • I'm confused how this works. Shouldn't there be a line that checks the local memory to see if the browser should be reloaded?

    On update ready. The offline games link goes into detail on what's going on.

    There's also the condition "On update found" if you want to warn the user its about to refresh, or if you want to allow the user to do it.

    Keep in mind that if you have a cdn it could take minutes to hours for an update to be deployed.

    In fact I usually have to stand on the refresh button when using GitHub user pages.

  • Nothing other than address your local memory concern.

    Note the update feature has nothing to do with local memory.

  • Nothing other than address your local memory concern.

    Note the update feature has nothing to do with local memory.

    Ah, got it! Thanks! :)

  • Hej CoGames, reach out to me I have an Idea I would like to test with You:

    contactiiw@garp.io

    Legacytrx

Post reply
  • 15 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)