mekonbekon Hi there! The ffmpeg.js script is a minimal port of the ffmpeg library which we use to allow WebM Opus audio files to work in pretty much every browser.

It is required primarily for Safari, although it is expected that Safari will support WebM Opus in the future, as it's been chosen as a standard for peer to peer audio/visual for web browsers (think skype in your browser).

It runs on start up to decode audio files (only if required) so it is possible that your preloading is upsetting it, but report a bug anyway so we can look into it.

The increased size is a bit of a downside, but the script compresses quite well (~670KB) so it shouldn't be a problem so long as your project is served over gzip. Also it means you don't have to include multiple audio formats any more to get complete browser support, so once you get past a few audio files you may find the export is actually smaller than what C2 would produce.

For comparison a 2 minutes audio track:

Raw audio

pcm = 21MB

C2 export

aac = 2MB

ogg = 1.2MB

C3 export

opus = 1.8MB

rhg1968 I've had a look and there's a missing dependency for the C2 runtime in iOS builds, I'm working on a patch that can go out on the server which will fix the problem.

sizcoz glad you got it working!

I do remember having that issue with installing an APK from the file explorer a couple of years back, the only way I could get it to work on that device was to use a 3rd party file manager.

It seems to install directly from chrome on my current test device (oneplus 3), but I guess the mileage may vary a little. I've also had success installing directly from google drive, which is helpful if your working on your desktop and you want to test a build quickly.

If you were having trouble accessing the zipalign tool I believe it's hidden away inside the AndroidSDK, so you can't access it without adding it to the PATH.

rhg1968 I'll take a look in when I get to the office tomorrow, just finishing up for the day at the moment.

sizcoz Just to sanity check, do you have developer mode enabled on your phone and did you select the correct version of Android for your device when you exported?

It might be a memory issue, but I would find it surprising. I checked and your device should have 2GB of RAM, even taking into account the device being busy C3 generally uses less than 0.2 starting up and drops back fairly quickly. The only known major memory pinch point is during export.

Nepeo

First I would like to say thank you for your response.

It's nice and reassuring to know someone is working on this.

Background

I have several Apps/Games of which I need to maintain, bring new versions enhancements to.

These games were wrapped into an APK from Intel XDK.

Ok I have my .keystore file from these games, from XDK.

Problem

I need to sign these future versions, with whatever will work.?

I signed the release version with jarsigner and zipaligned it with Java SDK, Android SDK, Signed ok, and Aligned ok, from the command line, but was unrecognised on my mobile, I must be doing something wrong somewhere, as this is a tedious process, involving application permissions, incompatable Java versions, Etc, as you are probably aware.

Retro signing an APK with a Keystore is not possible in Android studio as far as I am aware, which means, as you say exporting your project into android studio and building and signing from there, a bit complex.

So essentially what I was asking is there a cohesive roadmap of intent, to try and bring an APK signing process to C3 when you have already have a valid .Keystore file, as you need this .Keystore signed to be able to update your existing apps/games.

Also is there intent to provide a service for maybe any new apps/games created in C3 to get a new .keystore, auto signed, with maybe using our login details from C3 for our Alias, and Keystore file Passwords, using these details would probably make this process less complicated.

Anyway, Thank you again for your earlier response.

EDIT

To be fair I don't mind doing this myself if Scirra provided a comprehensive tutorial, and I am sure most would go with that too.

Cheers

As far as I'm aware this should all be completely possible provided you have the keystore. The requirements should be that the APK has the same package name, same signature, same signature type, higher version number and that it had zipalign applied to it.

I believe your right that you cannot "retrosign" an APK in android studio, but creating a new APK that is signed isn't all that scary.

This is the process I use for signing APK's from the build service via the command line. While testing the build service I've published project using these methods to the play store alpha release channel successfully and tested purchases on device.

METHOD A: Using apksigner

1. Export and build a release APK in Construct 3

2. Move the resulting APK into the same folder as your keystore (or close, you just need to know where they are)

3. Run the command

zipalign -v -p 4 UNSIGNED_RELEASE.apk ALIGNED_UNSIGNED_RELEASE.apk[/code:2xywc8t8]
4. Run the command [code:2xywc8t8]apksigner sign --ks MY_KEYSTORE --ks-key-alias KEYNAME--ks-pass pass:KEYSTORE_PASSWORD --key-pass pass:KEY_PASSWORD --out SIGNED_RELEASE.apk ALIGNED_UNSIGNED_RELEASE.apk[/code:2xywc8t8]

METHOD B: Using [b]jarsigner[/b]

1. Export and build a release APK in Construct 3
2. Move the resulting APK into the same folder as your keystore (or close, you just need to know where they are)
3. Run the command [code:2xywc8t8]jarsigner -keystore MY_KEYSTORE  -signedjar SIGNED_UNALIGNED_RELEASE.apk UNSIGNED_RELEASE.apk KEYNAME [/code:2xywc8t8]
4. Give the passwords for your keystore and key when prompted
5. Run the command [code:2xywc8t8]zipalign -v -p 4 SIGNED_UNALIGNED_RELEASE.apk ALIGNED_RELEASE.apk[/code:2xywc8t8]

METHOD C: Using [b]jarsigner [/b]and [b]apksigner[/b]
You can apply both signing methods to the same APK, I won't give the full commands as they are derivatives of the ones above but the flow is roughly:

1. Sign with jarsigner
2. Align
3. Sign with apksigner

MY_KEYSTORE is the location of your keystore file
KEYNAME is the name of the key within your keystore that you use for signing, it's normally "production"
KEYSTORE_PASSWORD is the password for the keystore
KEY_PASSWORD is the password for the specific key, this is probably the same as your KEYSTORE_PASSWORD

Bear in mind that when using apksigner specifically and giving the passwords as options in the command they need the "pass:" prefix in front of them.

I'm not sure which of these methods intelXDK uses but I believe the signature method needs to match if your trying to update an application. So this may require some trial and error. I tested all 3 of these methods with space blaster on my local computer and all 3 installed from fresh on my phone and ran correctly. I'm using JDK 1.8.0_131 x64 and Android SDK Tools 25.2.3 (although that shouldn't matter).

As for our roadmap, I sorry but I can't officially announce what our exact plans are going forward for application signing. But I can say we intend to continue developing the build service.

@at09

C3 plugins can specify cordova plugins as export requirements, and these are currently not restricted when you export a cordova project. However, the build service itself has strict limitations on what plugins are allowed to be included. Any other plugins will be not be included when the project is built. If you intend to use 3rd party cordova plugins you will likely need to run cordova locally and build the APK yourself.

1. Right click on your the "Files" folder of your project

2. Select "New" - "Array"

3. Fill in your data and close the array editor

4. Go to your layout and add the Array object and AJAX object

5. Add an "System - on start of layout" event and give add the action "AJAX - Request project file" to it , selecting your "New Array.json" the tag "array"

6. Add an "AJAX - on completed" event with the "array" tag and add the action "Array - load" to it, giving the expression "AJAX.LastData"

That should do the job! At the moment there's a bug with the data editor / text editor where they don't sync with the project unless you save the project or close the data editor / text editor which might cause you some confusion.

caad8user yes that's pretty much it, but remember you can use debug builds to try your game out on a mobile without needing to sign or publish. Also once you've figured out how to sign an APK it's only 2 commands to converted your unsigned APK to a release ready one.

To help you out a little:

https://developer.android.com/studio/command-line/apksigner.html tells you how to sign an APK.

https://developer.android.com/studio/command-line/zipalign.html tells you how to align an APK.

https://developer.android.com/studio/publish/app-signing.html has some additional information about the signing process and instructions on how to do it through android studio.

As for IPA's... well let's say apple don't make it easy but I'll be revisiting it at some point.

Hi there, I'm the developer for the build service so you can place any questions through me. I can't really comment on future development, but am happy to discuss the current situation and how things work.

To answer the current queries:

At the moment the build service will only provide an xcode project for iOS applications, to take this any further you will require a mac, xcode and an apple developer account. We don't have any tutorials on this at the moment, but there should be plenty of tutorials available for publishing applications from xcode made by other people.

Android development provides more options; you can choose to produce an android project, a debug APK or a unsigned release APK. Unless you are publishing to the store I would advise you to use a debug APK as this can be installed directly onto a development device without any extra steps.

Release builds must be signed to use on a device. Signing an APK is a pain point at the moment, but we will provide at a guide on how to perform this at some point.

If you dislike the command line and want to publish a android game then I would recommend choosing the project option and building an APK through android studio. It will provide the options for producing a debug APK or a release APK like the build service, but will handle signing release builds and generating a developer key if you do not yet have one.

caad8user Versioning of an APK can be specified by using the project version property in the main C3 editor, it should be in the format MAJOR . MINOR . MAINTENANCE for example

[quote:23gdo7rq]1.0.4

paala if you request both an iOS project and a android build then the zipfile you get back will contain the iOS project folder and an Android APK. If you request only one option, say just a debug Android build, then you will receive just an APK instead of a ZIP file.

sizcoz You probably found most of this out already but to sign an APK you need a developer private key, the unsigned apk, the apksigner tool and the zipalign tool. If you don't have a keystore file you need keytool from the JDK to create one. Both apksigner and zipalign are part of the androidSDK. I can't remember exactly but I expect even a signed release build must go via the play store to install, so debug APK's are the way to go unless your publishing.

In the settings menu there is an option called "periodically back up projects" which will create an autosave of the current project every 30 seconds. These are stored in the local browser saves. It's not working in r28 but it should be fixed in r29.

Cryptwalker themes are a work in progress keep an eye on the blog for more news!

Andrex Thanks for the feedback! If you dislike the delay on the animations then you can disable them in the settings menu for the time being.

Certainly I'd always choose x horizontal and y as vertical when making a table. It's the standard for 2D space after all, so long as your not talking about kinematics which uses i and j instead.

I was more commenting on the fact that internally in construct the JSON data is stored as columns which is nice and logical for reading a cell.

[quote:1ki6m6w6]

| | | | | | X

| | | | | |

| | | | | |

| | | | | |

Y

var cell = obj[x][y];[/code:1ki6m6w6]

However, typically table data is stored as rows, as it makes it easier to insert new rows. When you're using rows getting the entry for a cell in that format is the opposite way around.
[quote:1ki6m6w6]
___________
___________ X
___________
___________
___________
Y



[code:1ki6m6w6]var cell = obj[y][x];[/code:1ki6m6w6]

Column major / row major can be pretty confusing, when I was developing the array editor I actually had it the wrong way round for several months. During the alpha Kyatric noticed it was flipping the data around each time you saved and re-opened a file. It should match how the runtime actually reads the files currently.

I guess if it gives you real headaches then you could create a feature request for a "invert array editor" setting? Can see how much traction it gets