Messages

Glad to hear that it's working, but "intermittent" is the bane of my existence. Let me know if it resurfaces.

AGSteam doesn't do anything special in showing the overlay/pop-ups, that is handled entirely by the Steamworks backend. You may check how GOG Galaxy draws its overlay, though honestly I have no idea if it's the same as Steam (the Steamworks API doesn't include access to the sorce code, just the interface). That said, if it works on one DirectX, I don't see why it shouldn't work on OpenGL. Tons of Steam games use OpenGL. I'll ask about it in the private Steamworks dev forums and see if anyone has had similar symptoms.

P.S. Dave, to clarify, the overlay itself still works, just not the pop-ups?

This tool is now used for automatic releases of the Stack module, and my plan is to set up other modules on Github as well. The ags-module-stack repository on Github uses Travis CI to download the AGSModuleExporter tool and then invoke Mono to run it and build the module from the script sources. The scripts involved automatically bundle the exported script module, README, etc. and upload the zip archive to Github.

I'm proud to announce that all versions of this module are now available on Github:

https://github.com/monkey0506/ags-module-stack/releases

Version history between minor versions is now easier to visualize, and new releases are automatically built courtesy of Travis CI.

I wrote a tool that takes the ASC and ASH files and exports the SCM. That will sound more impressive once I finish setting up a project that uses this tool for fully automated builds (the process is already tested, I'm just getting things ready for a public release).

This tool is written in C# and works with Mono, so it can be used in Linux (despite the lack of an AGS editor for Linux as of yet).

Source and downloads are available on my Github.

[definition]

You just need to move the definition of the set_Minute extender method to be above the definition of set_Second. AGS can't call functions that have been imported (declared) but not yet defined ().

P.S. writeprotected members are public (for reading, not setting, obviously). You probably don't want to expose the same member in two different ways. Either use a writeprotected member with a SetMember public function OR make the member protected instead.

This stuff used to work, so the answer lies here somewhere

So, the biggest problem is building those native libraries for Android port?

He also edited the NDK build script, and I'm not certain that his modifications there work on Windows either, but I can't test it at all without the engine's native dependencies. I finally got an installation of Linux under Virtualbox running again (Debian 9 installer kept crashing, so I had to download a different distro). I should be able to rebuild the Android-native Allegro (etc.) and test the NDK build from Windows, or default to downloading the NDK for Linux and run it there.

Those libraries is probably something that should not be rebuilt every time. Would it be a viable solution if Nick could upload precompiled libraries?

Right, there's no reason that the Allegro libraries should have to be rebuilt every time the engine is rebuilt, so if they could be hosted (outside of the repo, obviously) elsewhere that would be ideal.

"Basically, this is where a person should stop trying and wait for further updates" is pretty much the understatement of the year.

I have been following with great interest and am waiting patiently for further updates but this made me smile.

Well... *sigh* Hopefully there will be a temporary fix soon, but the plugin will need to be kept up-to-date with regard to the Android engine files it uses or this whole problem will just resurface. What should be done is that the plugin should have a dependency that the Android engine files exist in an "Editor/Android" subdirectory, and if it can't copy the engine files from there then it can't deploy the APK. That way the engine files can be updated without having to rebuild the plugin.

The way things are now, the Android engine files are packed into "template.zip" from which a(n AGS) project-specific Android Studio project is created (including the engine files), and "template.zip" is packed inside the plugin! :/ Not very well planned out, but in my own defense it was thrown together as more of a proof-of-concept from which to move forward and is versioned as v0.0 (I'll keep shouting it 'til someone hears me! ). The engine files aside, "template.zip" should almost never have to change though, so.... [/technical-details-rant]

[0.0]

I would have to go back and investigate the plugin sources to be certain, but I think that it only extracts the prebuilt native libraries (e.g., the Android engine) if those files don't exist. So, in theory it would be entirely possible to just replace those native libraries in the "Compiled/Android/Studio" project folder and rebuild a working APK.

Part of my frustration in this comes from the fact that I've explained the entire process several times to Mehrdad, though I understand that those unseen interactions leave me sounding like a right arse in all this. The plugin itself is just one (minuscule) step further abstracted away from the osd-scourgeoftheunderworld-as Android Studio project, which explains the entirely simple deployment process. The plugin is released as version 0.0, tagged as alpha, and was last updated between build versions of AGS. "Basically, this is where a person should stop trying and wait for further updates" is pretty much the understatement of the year. The process is simple, but with building the Android port from Windows being currently impossible the barrier really falls well beyond the scope of the plugin.

[out-of-date]

Yes I build with 3.4.1

No. That's not what I asked. The 3.4.1 release you installed does not include any Android port of the engine. The plugin does. The engine that the plugin contains is out-of-date. This leaves you with two options:


1) Rebuild the Android port of 3.4.1 OR
2) Use the custom 3.4.0 editor from the plugin's downloads page (select "AndroidBuilder-Plugin.Editor.rar")

There are known issues to either approach:

1) Rebuilding the Android port is currently only possible from Linux AFAICT. The 3.4.1 branch is unstable and the Android port may not run (this has not been confirmed). If you rebuild the 3.4.1 Android port, you may encounter issues which already exist in 3.4.0, or you may encounter entirely new issues.
2) The custom 3.4.0 editor is not the same as the current 3.4.0 release (patch 4), and the two are not compatible. The custom editor is out-of-date with the 3.4.0 patch 4 release, and contains source code modifications which have been adopted into 3.4.1 (some, not all of the source code changes of 3.4.1). The Android engine port the plugin contains is from the same out-of-date version of 3.4.0, and may not be compatible with 3.4.0 patch 4. Additionally, the plugin itself is unstable, which means there may be unknown/unforeseen issues.



What you have is an APK with a game data file reporting AGS version 3.4.1 and an engine reporting AGS version 3.4.0. The engine is not able to load the game data file, which is why you get only a black screen. The error is not properly detected by the plugin nor the Android engine port (or, in the case of the latter, is not reported to the user). Even if the 3.4.0 patch 4 Android port were rebuilt, the plugin still depends on those changes from 3.4.1.

The plugin depends on the jobb tool, which recurses a directory and adds its entire contents to the OBB file. This tool cannot simply be given a list of files to add without major changes to the source of the tool, they must reside in their own, separate directory (e.g., "Compiled/Data" and not "Compiled"). Therefore there is no simple way to solve this problem at the present time. You must either use a custom build of the editor, or else you must rebuild the 3.4.1 Android port. I do not have any plans to fix the plugin to work with 3.4.0, for the reasons described here. I am actively working to try and rebuild the 3.4.1 Android port, and that is the approach that I suggest be taken moving forward, despite 3.4.1's current unstable status.

Objects:  Object.Animate

Mouse cursors:  Setting up the game - Cursors and Mouse.ChangeModeView

Inventory items:  No built-in solution, but InventoryItem.Graphic is writable... (will return with module momentarily)

Did you actually build 3.4.1 and test it on Android, or you're just saying things that you don't know what they mean? The plugin depends on editor features of 3.4.1, the actual build process does not. I've explained this to you before. However, since the build server is out of date and sonneveld has completely broken the ability to build the Android libraries from Windows, there's not really much that can be done in the way of building the native libraries.

I figured that's what you meant, but just clarifying.

Right, for some reason I forgot that the engine can't load any game files from a newer AGS than itself... even though CW mentioned it above.

The plugin's native libraries are out of date. I'll rebuild them and upload them somewhere, but be advised of the things CW stated above that 3.4.1 is unstable and may not work as expected.

I may toggle a game to a window from fullscreen if I want quick/easy access to my music player, Facebook, or something else which is distracting me from my distractions. I may wish to switch back to fullscreen for a more immersive experience though.

Personally, I don't think it should be persisted across save games, if that's what you're asking, but it does make sense to save that setting to the configuration file.

[P.S.]

3.4.1 and the plugin itself are both currently in "unstable" status. If something doesn't work properly then that isn't actually much of a surprise, is it? That's the whole reason for not calling it stable. And the status of the plugin itself isn't really the concern of the AGS dev team proper, but just myself (the sole author/maintainer of the plugin). Really, this thread doesn't even belong in this forum, and should probably be merged with the plugin's thread.

P.S. I do understand the concerns about basing work off of an unstable release of AGS, don't get me wrong, but the plugin itself is still considered to be in "alpha" stage. The whole process is still very messy and potentially error prone (e.g., creating an APK with no game files if wrong AGS version is used, no compile error if building OBB or APK fails, etc.). However, there are technical reasons why 3.4.1 is needed...

Spoiler

The "OBB" (Opaque Binary Blob) file used by the APK is required to be formatted as a FAT16 virtual drive, into which the game files are mounted. This is done by a modified version of the Android SDK's "jobb" (Java OBB) tool. The jobb tool recurses an entire directory and adds its contents to the FAT partition that it creates, thus the game's data files being moved into the Compiled/Data folder was necessary to avoid further modifying the jobb tool. Which isn't to say that that's the only reason why the files are in the Compiled/Data subdirectory -- that change does make sense in its own right and should have been done from the start, an error on my part. I just mean that since 3.4.1 is the earliest version to have the data files built into its own directory, that is the lowest supported version the plugin can use.

Regarding the modifications to the jobb tool:  The jobb tool distributed with the Android SDK is bugged in that it uses a FAT library's function to determine (from file size) which FAT partition type to use (incorrectly, I might add! It returns FAT32 for anything over 511 MB...) despite the fact that Android API's "mountObb" function requires a FAT16 partition type. The modified jobb tool that the plugin uses correctly selects a FAT16 partition type for anything under 2 GB, which is the upper limit of a FAT16 partition and also the upper limit on the expansion file (the OBB file) uploaded to the Google Play Store alongside an APK. Games over 2 GB would require an alternative approach to supplying the game assets to the end-user and cannot use the GPS expansion file.

[close]

[experimental]

I think there may be some misunderstanding as to how the AndroidBuilder plugin is working. The APK it provides depends on prebuilt native libraries (including the engine, of course), and does not do anything in the way of pulling those libraries from the editor directory... That is, WindowsBuildTarget grabs acwin.exe and LinuxBuildTarget tries to pull the Linux native engine files from the editor directory, but the AndroidBuilder plugin does not. The plugin's native libraries are packaged inside of the "template.zip" which contains a template from which an Android Studio project is created. The native libraries are contained in the libs folder inside template.zip. The end-user may later replace the extracted native libraries in the "Compiled/Android/Studio/libs" folder, but that goes beyond the plugin's scope of control.

Further, the AndroidBuilder plugin does not use the "AGS game launcher" APK in any way, so that project is unrelated.

The native libraries that are currently packaged with the AndroidBuilder plugin are from September of last year, well before you started any work on OpenGL.

Finally, the AndroidBuilder plugin is experimental and is explicitly designated as not fit for regular production releases. However, it absolutely depends on the 3.4.1 editor to work properly.

That said, a future "stable" release of the plugin would expect to be able to read prebuilt native libraries from the editor directory, but the plugin is not that far developed yet.

[AGS 3.4.1]

The AndroidBuilder plugin was last updated in September 2016 and depends on features of AGS 3.4.1, however, the AGS version was not increased to 3.4.1 until October 2016, so the plugin (at the time it was last updated) did not have a way to detect the proper minimum AGS version. However, it could also be updated to have a formal dependency on the game data file itself (e.g., Compiled/Data/GameName.ags), which it currently doesn't have. I will push an update to the plugin, but please make sure you are using AGS 3.4.1 (or later, for you future readers!).

P.S. The dependency on 3.4.1 is mentioned in the plugin's README Prerequisites section.

[editor]

APK files are just ZIP archives. Could you open the APK with a ZIP archive tool (7-zip, etc.) and provide a list of the contents of the APK itself? Also, what is the size of the OBB file?

Also I think you need to clarify which version of AGS this Android creator plugin supports

The AndroidBuilder plugin itself requires the AGS editor version 3.4.1 (has a dependency on #354), but it should be agnostic of the actual engine version. The plugin includes prebuilt native libraries from September 2016 (when the last plugin version was published), which were from the latest 3.4.1 dev branch at that time...



I was looking over the plugin source to try and figure out what might be the problem, and I think I've figured it out. Are you using AGS 3.4 to build the APK, or do you just mean that you took the demo game project from 3.4? Despite the 3.4.1 dependency, I don't see that the plugin would actually report an error if using an earlier version. I don't recall if the AGS version was actually updated to 3.4.1 at the time, but the plugin's "RequiredAGSVersion" attribute is set to 3.4.0, and the build process itself doesn't detect if the "Compiled/Data" directory doesn't exist. Therefore, I believe the problem is simply that you're using the wrong AGS version and the plugin isn't detecting that, so you're getting an empty OBB file.

Did anyone ever find a way to get games with Steam/GOG Galaxy achievements working in the Android player? I've looked around the forums and there's several mentions of a stub plugin for AGS2Steam/AGS2Client, but I can't tell if a solution was ever released.

Source of the stub may be found here. I haven't tested running this plugin on Android, but it should (theoretically) work out-of-the-box, but rebuilding with the NDK would be necessary. There isn't currently a Makefile, but the Code::Blocks project file may be used for reference (I will try to look into writing a Makefile, I don't have much experience working with them).