Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Auto updating an app (desktop)

Author
Message
JohnStabler
AGK Bronze Backer
10
Years of Service
User Offline
Joined: 16th Aug 2013
Location: Cardiff, Wales, UK
Posted: 22nd May 2021 17:41
Does anybody have any solution to auto update an AppGameKit app on Windows / Mac? Is it possible to download and overwrite the byte code file and other assets from within the app itself (and ask user to restart)? Any other considerations?
Loktofeit
AGK Developer
15
Years of Service
User Offline
Joined: 21st Jan 2009
Location: Sarasota, FL
Posted: 22nd May 2021 19:05
Have a launcher exe that checks for updates and then runs or updates the main program.

However, if this is a standalone app and not something that normally requires internet connection,
most users prefer a program that just polls for current version and then notifies them that an update is available.

LynxJSA's web games/quizzes - LynxJSA's Android apps
AGK Resource Directory
"Stick to a single main loop (DO...LOOP) and loop through it every frame.
Do everything inside functions.
Use finite state machines to control your game.
Use lots and lots of source files.
Use virtual resolution instead of the default percentage system." - Digital Awakening
JohnStabler
AGK Bronze Backer
10
Years of Service
User Offline
Joined: 16th Aug 2013
Location: Cardiff, Wales, UK
Posted: 22nd May 2021 19:21 Edited at: 22nd May 2021 19:21
Yes, I could write a dotnet launcher to do that.

But I'm asking if, given that AppGameKit apps are interpreted, could it all be done in the same app, without worrying about also building an additional launcher (for multiple platforms: windows, mac & Linux).
fubarpk
Retired Moderator
19
Years of Service
User Offline
Joined: 11th Jan 2005
Playing: AGK is my friend
Posted: 22nd May 2021 19:45 Edited at: 22nd May 2021 19:47
You cant update a file thats already in use.
but what can be done is launching another update app and closing all files while its the update app is updating
then the update app can restart your program

I dont think launching a program in agk basic is possible but the other flavours of agk like c# or c++ its quite possible
but a batch file that you launch at the beginning can check for updates and launch your program normally in all flavours of agk
fubarpk on Itch...………...https://fubarpk.itch.io/
fubarpk on googleplay..https://play.google.com/store/apps/developer?id=fubarpk
JohnStabler
AGK Bronze Backer
10
Years of Service
User Offline
Joined: 16th Aug 2013
Location: Cardiff, Wales, UK
Posted: 22nd May 2021 19:57
Is the bytecode file always in use? Does agk load the bytecode into memory and then, for some obscure reason, keep an open handle on it?

Does this not work on tier 1 desktop? https://www.appgamekit.com/documentation/Reference/Core/RunApp.htm
fubarpk
Retired Moderator
19
Years of Service
User Offline
Joined: 11th Jan 2005
Playing: AGK is my friend
Posted: 22nd May 2021 20:13 Edited at: 22nd May 2021 20:22
I believe the bytecode needs to stay open only way is to test to be sure i believe sandmans world builder updates itself so finding the posts on that may explain this better

and i forgot about the https://www.appgamekit.com/documentation/Reference/Core/RunApp.htm (good find)

either way im sure most software use a seperate program

simple test would be to get windows to abrubtly close the file and see if the exe still runs ok and doesnt get an error with the byte code
fubarpk on Itch...………...https://fubarpk.itch.io/
fubarpk on googleplay..https://play.google.com/store/apps/developer?id=fubarpk
JohnStabler
AGK Bronze Backer
10
Years of Service
User Offline
Joined: 16th Aug 2013
Location: Cardiff, Wales, UK
Posted: 22nd May 2021 22:48
I found out the answer myself, so I will share the knowledge here.

When AppGameKit tries to read a file it looks for it first in the *write* directory (e.g. $USER/AppData/Local/AGKApps/App_Name/media) and, if not found there, it will check the *read* directory (wherever your media installation is). This is also true for the bytecode.byc file. So if you create / overwrite a bytecode.byc file in the write directory then you can update your app while it is running. You just need the user to restart the app once it is done. Handy side-effect of this: by deleting the bytecode.byc file from the write directory, the app will revert back to the original one in the read directory, rolling back changes. Here is some code that worked for me.

Loktofeit
AGK Developer
15
Years of Service
User Offline
Joined: 21st Jan 2009
Location: Sarasota, FL
Posted: 22nd May 2021 23:56
Interesting, and that certainly seems to work, although I would caution against building code around wonky backend weirdness, as that has a tendency to change without notice.
LynxJSA's web games/quizzes - LynxJSA's Android apps
AGK Resource Directory
"Stick to a single main loop (DO...LOOP) and loop through it every frame.
Do everything inside functions.
Use finite state machines to control your game.
Use lots and lots of source files.
Use virtual resolution instead of the default percentage system." - Digital Awakening
JohnStabler
AGK Bronze Backer
10
Years of Service
User Offline
Joined: 16th Aug 2013
Location: Cardiff, Wales, UK
Posted: 23rd May 2021 00:58 Edited at: 23rd May 2021 00:59
I don't know if I'd call it weirdness or wonky. The write / read directory behaviour is exactly as described in documentation. I was just glad it also applied to the byte code file. Not sure why people would assume there would be a file lock on a non-executable file that was only ever read from by the AppGameKit player on start-up.
Loktofeit
AGK Developer
15
Years of Service
User Offline
Joined: 21st Jan 2009
Location: Sarasota, FL
Posted: 23rd May 2021 01:30
"The write / read directory behaviour is exactly as described in documentation." I agree that it is documented. Maybe I should have used the terms odd or non-standard in reference to a program that reads from one directory but writes to another by default for the same file.
LynxJSA's web games/quizzes - LynxJSA's Android apps
AGK Resource Directory
"Stick to a single main loop (DO...LOOP) and loop through it every frame.
Do everything inside functions.
Use finite state machines to control your game.
Use lots and lots of source files.
Use virtual resolution instead of the default percentage system." - Digital Awakening
JohnStabler
AGK Bronze Backer
10
Years of Service
User Offline
Joined: 16th Aug 2013
Location: Cardiff, Wales, UK
Posted: 23rd May 2021 10:31
I still don't know what you mean by odd or "non standard".

AGK does a few things in ways different to other frameworks. Are we not to use any of those features?

If it's a documented behaviour and not some unintended consequence that could be changed in a future update then it's fine surely?
Loktofeit
AGK Developer
15
Years of Service
User Offline
Joined: 21st Jan 2009
Location: Sarasota, FL
Posted: 23rd May 2021 13:36 Edited at: 23rd May 2021 14:39
I still don't know what you mean by odd or "non standard".

"When AppGameKit tries to read a file it looks for it first in the *write* directory (e.g. $USER/AppData/Local/AGKApps/App_Name/media) and, if not found there, it will check the *read* directory (wherever your media installation is)."

Based on the programming languages and development environments that you have used, is that standard behavior?
LynxJSA's web games/quizzes - LynxJSA's Android apps
AGK Resource Directory
"Stick to a single main loop (DO...LOOP) and loop through it every frame.
Do everything inside functions.
Use finite state machines to control your game.
Use lots and lots of source files.
Use virtual resolution instead of the default percentage system." - Digital Awakening
Raven
19
Years of Service
User Offline
Joined: 23rd Mar 2005
Location: Hertfordshire, England
Posted: 24th May 2021 00:22
As far as I'm aware., AppGameKit actually runs the Application from a Temporary Directory: System:\Users\[Username]\AppData\Local\AGKApps\[YourAppName]
The result of this is that you can still Modify the Installed Directory version., and it will Shadow it to this Directory when you next run the Application

Yes, updating the Bytecode.byc will update the AppGameKit Script (i.e. what you've written) but remember that the AppGameKit Player embedded in the Runtime is Dynamic; including ONLY the Packages that you've used Commands from.
This means if your Bytecode.byc suddenly decides it wants to use Audio when you never used said Commands when you first compiled; then it will simply crash the Application with a Runtime Error.
A way around this is to deliberately use a Command from each Package; but unlike DBPro this isn't quite as easy as AppGameKit doesn't have a clear list of Package Libraries.

As best as I can tell the Help Sections seem to coincide with it, but don't quote me on that.
You'll actually find A LOT of Apps nowadays don't patch themselves... as Steam, Microsoft Store, Origin / EA Launcher, etc. well they all have built-in Delta Patching.
So unless you're planning to Self Publish, chances are whatever platform you intend to use will support patching outside of the Application that will perform automatically when you add a new Patch.

In-fact with Microsoft Store, when you add a new version of your Application Package; it will automatically generate the Delta Patch for you and push it out when you enable it on the Developer Account.
Virtual Nomad
Moderator
18
Years of Service
User Offline
Joined: 14th Dec 2005
Location: SF Bay Area, USA
Posted: 24th May 2021 01:05 Edited at: 24th May 2021 01:26
Quote: "the Runtime is Dynamic"

are you sure about that, Raven? either of the .exes produced by these 2 snippets run either .byc, interchangeably:

Print

3D

both exes are 7,351,296 bytes and, i've always understood the exe to be a generic player which is simply a copy of the current version's /player/windows/ .exe (64 bit, in this case. version 02.12.21).

ack!, there is something going on. i searched my project folder for *.exe and, while every same version of the player was the same size, a couple "new"/may versions were over 9mb. recompiling and they were back to 7.1mb (and i don't remember modifying them this month while their dates said i did). maybe a difference in studio (which i rarely use) and classic?
[My Itch.io Home] [Community Apps on Itch.io]
[AGK Resource Directory] [TGC @ GitHub]
[CODE lang=agk] YOUR CODE HERE [/CODE]
[VIDEO=youtube] VIDEO ID [/VIDEO]
[AGK Showcase][Google Forum Search]
Raven
19
Years of Service
User Offline
Joined: 23rd Mar 2005
Location: Hertfordshire, England
Posted: 24th May 2021 16:23
Quote: "ack!, there is something going on. i searched my project folder for *.exe and, while every same version of the player was the same size, a couple "new"/may versions were over 9mb. recompiling and they were back to 7.1mb (and i don't remember modifying them this month while their dates said i did). maybe a difference in studio (which i rarely use) and classic?"


Not sure, AppGameKit obfuscates so much of what it does under-the-hood.
Still it's a good idea to never rely on behaviour that isn't well documented (i.e. not subject to change) or that you have full control over the behaviour of (say a Launcher / Bootstrapper)



PartTimeCoder
AGK Tool Maker
9
Years of Service
User Offline
Joined: 9th Mar 2015
Location: London UK
Posted: 25th May 2021 14:27
Quote: ""the Runtime is Dynamic""


The runtime is precompiled and all functions are in the AGK:: namespace, there is nothing dynamic about it, there are some internal flags set for platform but most of these are for the rendering engine, all functions are exposed on all platforms (see AGKWrapper.h), when compiling the game the runtime is simply copied to the target dir and the bytecode is generated, the runtime never changes.

Quote: ""new"/may versions were over 9mb. recompiling and they were back to 7.1mb ...... maybe a difference in studio (which i rarely use) and classic?"


Yes, bear in mind the Studio runtime also contains the Vulcan code/libs weather you use them or not (as above, not dynamic) so I would expect the runtime to be larger than Classic in all cases, I would expect any bytecode file generated by classic to run with any classic runtime and same for studio but I would also expect a few issues when mix'n'match the 2 (not tested so pure speculation)

As for auto updates, if any app on my system tries to download files without first asking for approval is soon removed from my system ... with the expectation of Windows of course, MS updates seem to have unmitigated access to my system and I hate it and will not tolerate it from 3rd party apps, just saying .... if you want to lose users then allowing your app to download files without user approval is a perfect way to go about it.




Login to post a reply

Server time is: 2024-03-28 17:22:42
Your offset time is: 2024-03-28 17:22:42