PT Forum

JohnStabler 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 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.

JohnStabler Joined: 16th Aug 2013
Location: Cardiff, Wales, UK

Posted: 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 Joined: 11th Jan 2005
Location: AGK is my friend

Posted: 22nd May 2021 19:45

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

JohnStabler 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 Joined: 11th Jan 2005
Location: AGK is my friend

Posted: 22nd May 2021 20:13

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

JohnStabler 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.

+ Code Snippet

function CheckAndUpdateVersion()
	
	if GetInternetState() = 0 then exitfunction
	
	http = CreateHTTPConnection()
	SetHTTPHost(http, GCN_WebHostname, 0)
	SendHTTPRequestASync(http, "VersionCheck.aspx?ver=" + GCN_Version)
	downloadState = 0
	
	while downloadState &lt; 1
		
		ready = GetHTTPResponseReady(http)
		if ready = 1
			
			if GetHTTPStatusCode(http) = 200
				
				response$ = GetHTTPResponse(http)
				
				if Left(response$, 8) = "VERSION:"
					
					ver$ = Right(response$, Len(response$) - 8)
					
					if ver$ &lt;&gt; GCN_Version
						GetHTTPFile(http, "builds/latest-media.zip", "latest-media.zip")
						downloadState = 1
					else
						downloadState = 100
					endif
					
				else
					downloadState = 100					
				endif

			else
				downloadState = 100
			endif
			
		elseif ready = -1
			downloadState = 100
		endif
		
		Print("Checking version...")
		Sync()
		
	endwhile
	
	while downloadState &lt; 2
		
		ready = GetHTTPResponseReady(http)
		if ready = 1
			
			if GetHTTPFileComplete(http) = 1
				ExtractZip("latest-media.zip", "")
				downloadState = 2
			endif
			
		elseif ready = -1
			downloadState = 100
		endif
		
		Print("Updating...")
		Sync()
		
	endwhile
	
	CloseHTTPConnection(http)
	if downloadState = 100
		exitfunction
	endif
	
	do
		
		Print("Data files have been updated.")
		Print("Please restart the application to use the new version.")
		
		Sync()
		
	loop
	
endfunction

Loktofeit 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.

JohnStabler Joined: 16th Aug 2013
Location: Cardiff, Wales, UK

Posted: 23rd May 2021 0:58

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 Joined: 21st Jan 2009
Location: Sarasota, FL

Posted: 23rd May 2021 1: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.

JohnStabler 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 Joined: 21st Jan 2009
Location: Sarasota, FL

Posted: 23rd May 2021 13:36

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?

Raven Joined: 23rd Mar 2005
Location: Hertfordshire, England

Posted: 24th May 2021 0: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 Joined: 14th Dec 2005
Location: SF Bay Area, USA

Posted: 24th May 2021 1:05

the Runtime is Dynamic

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

Print

+ Code Snippet

do

    If GetRawKeyState(27) then Exit    

    Print( ScreenFPS() )
    Sync()
loop

+ Code Snippet

ThisBox = CreateObjectBox(10,10,10)

do

    If GetRawKeyState(27) then Exit    

    Print( ScreenFPS() )
    Sync()
loop

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?

Raven Joined: 23rd Mar 2005
Location: Hertfordshire, England

Posted: 24th May 2021 16:23

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 Joined: 9th Mar 2015
Location: London UK

Posted: 25th May 2021 14:27

"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.

"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.

<1 >

Sign In