It seems that Unity added encryption to purchases last week with the 1.0.0 ODK release. Since this ANE hasn't been updated since early February, I'm going to assume that it has no support for this, and this is why I'm getting an encryption-related error when trying to use it.
Gaslight, I hope that this side of things can be supported by your ANE soon. Please let me know if I can help! Perhaps I'll try poking around in the ANE code myself, though it's been a long time since I've worked in Java.
My bad!
*Slaps Wrist!*
Sorry folks... I will be returning to the ANEs, adding updated support to the controller(s) as there's been some changes there and updating/fixing the IAP ANE, too.
Things have just been insanely busy for us and I've just not had time to get back round to updating these projects. I haven't forgotten nor abandoned them! We'll be using them for our upcoming games, so I'll have to fix them for those projects.
Hopefully I can squeeze an hour or two later on today then I can get these updated, provide some full projects with both ANEs (I have some that work, so I know they're OK!) and also build instructions for everything... just takes time :-/
They've been pretty transparent about what's coming down the pipe for a while now. Though the OUYA addition is new.
Yeah, it's really exciting!
Until this support is added, working and supports all features of the controllers, I'll update the Controller ANE to make use of the latest changes and features.
On another interesting note, there are some new features added to the ODK including the saving/loading of Game Data that allows persistence across a few areas. Would folks be interested in this feature, too?
Not sure where to fit it... might put it in the Controller ANE for now and perhaps create an "OUYA Utils ANE" if more features come out that aren't relevant to the Controller or IAP? Could even merge the IAP into the Utils project and have fewer external requirements?
Glad to hear you having working IAP ANE stuff Gaslight. (BTW it was good to meet you briefly at GDC, I was the guy at the Adobe booth wearing plaid and a beard. :)
I thought I'd point out that Adobe AIR SDK 3.7 is now out and includes "GameInput", an API that is meant to support gamepads in general, and particularly Ouya (with broader AIR gamepad support apparently to come later). Here's some links:
That last link seems to provide a helpful wrapper that's basically made to be a perfect solution for Ouya gamepads. I plan to try to get all this working in an AIR Ouya game soon, within the next couple of days - perhaps the controller ANE will no longer be needed.
But a new ANE for IAP would definitely be greatly appreciated. :)
I agree that, with the upcoming Gamepad support (man, we've been waiting SOME time for this!), the Controller ANE becomes a little defunct. I'm finishing up support for the remaining features of the controller and fixing a few niggling annoyances, so at least it'll be up to date before the full AIR support comes our way.
I suspect the interesting part, for me, will be to see how they approach everything and how the "Adobe" approach returns all details and responses and is there a dip in performance of button press detection.
It's funny, they've done a similar-but-better approach to how I've handled the Player allocation for the controllers, in that they still have Players 1 through 4, but have a better way of dropping in and out.
As far as the IAP stuff goes, this is vital to myself and I imagine a few others, so will definitely be sorting it!
Was good to meet fellow AS3 and OUYA fans at GDC... somewhat surreal to be stood while you guys were discussing these ANEs, haha :-)
In the meantime, I have updated the Controller ANE.
It's now a Singleton on the AS3 side, along with support for the changes in the ODK. All buttons, including the MENU, work, so you should be able to see the Simple Test project to get an idea of how to make it work in your game.
I'm on the IAP today - the changes to the ODK are quite extensive, at least from the approach taken with the ANE back in February. Once I have this working, I'll post it here :-)
Make sure you read the "Notes" section of the ReadMe on the GitHub page, as there are several annoyances nuances (yeah, let's call them that) that can look like things are totally screwed, when in fact there's a mis-match in UUIDs.
Now that I've solved the issues with sending the key.der file, processing the ByteArray properly, the package name issue and gotten the purchasing to work... it should be trivial to move to the next step and get the receipts to work!
Then that looks to be it!
Oh and making sure we can use the Controller and IAP ANEs together - that comes after I fix the IAP ANE. Hope this helps some/any of you :-)
What I believe to be full support for ODK 1.0.3, encrypted receipt requests and responses are now implemented along with an update to the way of signalling "testing".
First of all, I resolved my previous problem, I mostly just needed to do the adt build myself on the command-line, and check that I was using the right parameters there... adding an "-extdir" parameter to my ANE directory was probably the most important part of that.
Second, to answer your query above Gaslight, yes I am interested in the AIROUYAIAP project, and now I'm trying to use it as well! However I'm getting a problem when running the adt command-line statement I mentioned; I get many warnings like this one:
trouble processing:
class name (tv/ouya/console/util/SerialNumber) does not match path (libs/tv/ouya/console/util/SerialNumber.class)
at com.android.dx.dex.file.ClassDefsSection.add(ClassDefsSection.java:123)
at com.android.dx.dex.file.DexFile.add(DexFile.java:143)
at com.android.dx.command.dexer.Main.processClass(Main.java:301)
at com.android.dx.command.dexer.Main.processFileBytes(Main.java:278)
...
I did some googling and found this error is caused by redundant/conflicting symbols. I wonder if this is because I'm including both the Controller ANE and now the IAP ANE, and they include some of the same symbols and classes?
It would be nice to have a working example project that included both the controller and IAP ANE's, for a start.
I want to thank you again, GaslightGames, for doing excellent work making these ANEs, I appreciate that I and other Flash-on-Ouya developers are getting the benefits of your hard work! I hope to see several AIR Mobile games on the Ouya store during the launch window; if there are, you'll deserve much of the credit!
Aaah, what a truly frustrating bug!
OK, it's entirely due to the inclusion of the class files from the ODK and that the packager from Adobe can only see these files once - any attempt to include a file of the same name causes a collision.
I've gone through both ANEs and stripped out all IAP class files from the Controller ANE and vice versa, stripped out all Controller class files from the IAP.
Tested and it now works :-D
Just in time for the Controller ANE to be defunct with the updates from Adobe, haha.
You are the man. I still have not experimented with Adobe's own gamepad solution; I will let you know how that works on the Ouya, though. Thanks for creating these ANE's, they are a lifesaver.
You are the man. I still have not experimented with Adobe's own gamepad solution; I will let you know how that works on the Ouya, though. Thanks for creating these ANE's, they are a lifesaver.
Glad they're going to be useful!
I want the OUYA to succeed and the community to continue to develop, so making these ANEs available to everyone should help to gain momentum with AIR developers and hopefully see even more great games on the OUYA itself :-D
I'm finally hooking up the IAP ANE! However, on my first attempt to run on the Ouya, I get these errors:
dx tool failed:
trouble processing:
class name (tv/ouya/console/api/CancelIgnoringJsonResponseListener) does not match path (libs/tv/ouya/console/api/CancelIgnoringJsonResponseListener.class)
...And then there are about 20 more similar errors. It appear that the "libs" path at the beginning is the trouble? I'm not sure exactly what's going on here...
Interesting - I have it working with a test application, s'how I know that I got the right class files in each ANE.
Did you remove the ANEs from the project(s) in Flash Builder and then re-add them? I find that if you just copy the ANEs over the old ones, then often the old ones are still being cached somewhere/somehow.
I'll check again, but I had it working so things appeared to be working fine :-S Hmm, I'll also check that the ANEs have definitely been updated when uploading! I may have missed them from the push to the repo.
I'm still using an old version of the ANE, so I should update. Right now in multiplayer, my controllers are canceling each other out for some reason. I'll update soon and see if I'm getting the same results.
I'm still using an old version of the ANE, so I should update. Right now in multiplayer, my controllers are canceling each other out for some reason. I'll update soon and see if I'm getting the same results.
The ODK has changed, so if you've updated your OUYA at all, then the old Controller ANE is probably broken from those changes... maybe?
I've had no issues with 2 controllers... but then, I am only testing in some pretty closed circumstances, so there could be issues! Keep 'em coming, folks - if you find bugs or hit on issues, do keep letting me know and I can investigate :-)
I just tried running your AIROUYAIAP_Test project in FB4.7, compiling on a Mac. It doesn't give me the error I mentioned above, but I do get this error when the app starts launching:
VerifyError: Error #1014: Class com.gaslightgames.nativeExtensions.AIROUYAIAPANE::AIROUYAIAPANE could not be found.
Also note that I tried several ways to get my project itself compiling with your ANE but I'm still encountering the errors described above (the "dex tool" errors with what looks like a wrong path with "lib." added to the start of it).
You may need to remove the ANEs and re-add them to the project, as the paths *could* be formatted in a Windows way, rather than a generic/unix manner?
Once I get into the office tomorrow, I'll upload another project - test, with both ANEs in. It's really quite odd! And what's frustrating is it works for me, so not being able to replicate means I can't narrow down what's breaking and fix it!
I thought I'd update this thread and mention that since this issue is the only one remaining for me getting my game finished and onto the Ouya (which I want to do), I'm going to explore creating my own ANE from scratch myself, using your code as a guideline. Hopefully it won't be too hard, and will get around whatever problem I'm having.
I'll also a share a bit more info about the errors I'm getting. First, I'm using FB 4.7 on a Mac, and I've been using AIR SDK 3.7. When I go to Project Properties -> ActionScript Build Path -> Native Extensions, both of my ANE's have red X's next to them; expanding them shows an error: "This ANE does not support Desktop(Mac) platform." However note that none of this seems to be a problem because the controller ANE has run fine! My only issues seem to be with the IAP ANE. Note that I'm just trying to build and run a debug build directly on the Ouya. (It occurs to me now that I should try a release build, I'll do that soon.)
Second, I think I forgot to mention that when I do try to build and run from FB, it gives me an unusual error popup during the "Launching : Packaging application for Google Android..." step. The error says "There are packaging errors/warnings. Check Flex Build Packaging page for the built target and launch target association. Platform: Android. Build target: device. Launching on: device. Would you like to continue?" I have no idea what any of this means, is it telling me I can see warning/error details? If I hit "yes" then I proceed to get the other errors I listed above - but I'd forgotten to mention that I saw this first.
Okay I backed up a step and decided to just get the IAP Test project running if I could.
The first thing I've had to do when running that test was replace the ANE inclusion in it: there's an ANE inclusion, but it's set to an absolute path on Gaslight's machine, which of course didn't work on my machine. But even once I dropped this ANE and replaced it with a path to the ANE on my machine, things weren't working.
My breakthrough this time was a realization about the error I mentioned above - the one that says to "check Flex Build Packaging page" for more info. Well there is no page with that name in FB4.7... but there IS a page named "ACTIONSCRIPT Build Packaging". (And it's in the Project Properties dialog btw.) Anyway yeah Adobe decided to play musical chairs with what is and isn't named "Flex" versus "Actionscript" recently, and they didn't update their error messages' text. Ugh.
When I finally looked up this page, I saw that 1) the invalid-path ANE was still there - and couldn't be removed, but it seems to do no harm, so whatever... and 2) the ANE I had added was NOT checked to get packaged into the app! Weird. I checked that box. Then I also made sure to create a Digital Signature (.p12 file), which didn't exist... not sure if that was necessary or not.
In any case, then I was able to run and I got to the error that I didn't have a key.der file! One download later and everything seems to be running fine!
Next step is to get all this working in my game - now that I have the test app running I have a template to build from. Thought I'd share the issues I experienced and how I overcame them, in case it helps anyone else!!
Thanks IQpierce for not only delving into the problem more deeply, but for the detailed solution!
It's a strange one that, even after removing, the references to the old ANEs remains in the project - but the plus side is that, as you've discovered, things are now working!
I wish we could put relative paths in the projects, then this issue wouldn't happen. As I could just set the ANE discovery path to something like "../ane/blah.ane" and be done with it. But apparently it's an issue with Eclipse, not just Flash Builder.
Okay, I've had various snags... all I'll say is I wish I had paid attention to your warning that your app name MUST have "air.*" at the beginning, since apparently that gets added at some layer. That was a pain, especially since I had already registered my app here in the Ouya Dev portal and I couldn't delete it OR change its app ID. So I had to make a new one with a slightly different name. Hmm.
Anyway here's another thing I'm hung up on: my app icon. Aside from some references to a "-C" flag for adt (which from what I'm seeing just doesn't work unless you're making an ANE), I haven't found any way to tell ADT or Flash Builder to put certain files under the "res" folder - specifically the ouya_icon.png file that I have to put in there.
The next thing I'm going to try is manually unzipping my release APK, adding this file to the right place, and re-zipping it. Hopefully this will work and won't cause a checksum error or something... will update when I try it. It would be a pain of a workaround but acceptable... I'd hope that AIR made this easier.
I look forward to shipping this AIR-based Ouya game soon! Has anyone else shipped an Ouya game made with AIR yet? I'm afraid I haven't been following the Ouya store releases very closely.
Yeah, the air.* pre-requisite is a little frustrating, as it's added outside of the application. I believe it's added even if you use captive runtime and not an "installed" version of AIR. This was a real pig of an issue to find and suss out, as the first lot of payments threw errors that the package names didn't match with what was registered and the AIR APK name... and the air.* was the reason!
As far as icons go, you should be able to set them in the descriptor XML:
Ouya has a unique icon need, it expects a special icon named "ouya_icon.png" under the few folder, as listed here: https://devs.ouya.tv/developers/docs/setup ... My understanding was that the descriptor file had nothing to do with this.
Or am I wrong? Is there a way to specify that file getting copied to the right place by using the descriptor file?
And again: do you know whether anyone's shipped an Ouya game using AIR tech? Will I be the first?
The <icon> tag is the approach you must take for iOS and generic Android, so I would wager that this is how to support the icon on OUYA.
Have you tried?:
<icon>
<image732x412>images/your_icon.png</image732x412>
</icon>
Also, are you using AIR 3.7? As the updated OUYA support should be present in the latest release :-)
As far as OUYA games under AIR, I've caught a few other people around the Internet who are developing such... but I don't know of any that have been released, so you may be the first!
AIR's GameInput doesn't work on Windows - I just get an "Unsupported = False" when I try to run it on Wednesday. But on the OUYA, yup, got it working nice and easily.
With that error, have you definitely updated all of your SWC's?
Sometimes Flash Builder will hold old SWCs, or some of the libraries aren't updated/overwritten.
I always try to target a completely new Flex folder when copying/updating the AIR components... then use that to overwrite those in the Flash Builder install directory. Hope that makes sense :-)
I'm not using Flash Builder at all! The only extensions I've ever implemented before have been standalone SWC files. Sounds like that is the issue so I'll have to look into it.
Is that the case with your extension too by the way? The user has to do something with it other than extract the SWC/ANE?
Aaah, OK - are you using Flash Pro? Flash Develop? Or hardcore and mxmlc on the command line!? :-)
Just make sure that your AIR SDK download is definitely being used and specifically the latest airglobal.swc is being targeted.
With the ANEs for OUYA (if you get GameInput working, you should only need the IAP ANE) you add them like a SWC and your IDE should detect that the packages are available. But that depends on what compiling method you're using.
I'm using Flash CS6 with the very latest AIR 3.8 beta, debugging at the desktop with no OUYA. No matter how I try to include that "gameinputcontrolname.swc" I get the same resistance.
How far could I get in your ANE without an OUYA? Would it recognize an Xbox controller in Windows?
Interesting. Once you have your project linked to the latest AIR, then the Game Input API is part of it, so you shouldn't need to add the SWC again. If you can call "import blah.blah.GameInput" and Flash CS6 finds that package, then you should be OK.
It's certainly a strange one, as I'm only using AIR3.7, modified my Flex folder with that AIR SDK and restarted Flash Builder.
The similar procedure, only overriding AIR3.8 SDK on top of the existing Flash CS6 SDK in the install directory - that should work. It's worked for me in the past when I used CS5 before jumping to Builder (best decision, ever, btw!).
The OUYA Controller ANE will only work on the OUYA. You'll get isSupported() returning "false" on any other platform, so that your app will still compile, just wont do anything.
Also, GameInput only works on Android - I got stung by that when trying to test on Windows. There are WIndows controller ANEs, but they're a little sketchy iirc - of course, they could be amazing and my quick glance was insufficient and I'm totally out of touch with how they work!
Just to try and break it down: What procedure did you take to update your AIR SDK in CS6?
Comments
Yeah, it's really exciting!
OK, so I'm about 90% there with the update to the IAP ANE... latest version on GitHub:
Oh and making sure we can use the Controller and IAP ANEs together - that comes after I fix the IAP ANE. Hope this helps some/any of you :-)
I've gone through both ANEs and stripped out all IAP class files from the Controller ANE and vice versa, stripped out all Controller class files from the IAP.
Just in time for the Controller ANE to be defunct with the updates from Adobe, haha.
I'm finally hooking up the IAP ANE! However, on my first attempt to run on the Ouya, I get these errors:
...And then there are about 20 more similar errors. It appear that the "libs" path at the beginning is the trouble? I'm not sure exactly what's going on here...
At the bottom we finally have:
The "always added" part makes me wonder whether there's still a collision between classes included in both ANEs?
If this is the problem, have you considered making a third ANE that is a combination of both...?
Did you remove the ANEs from the project(s) in Flash Builder and then re-add them?
I find that if you just copy the ANEs over the old ones, then often the old ones are still being cached somewhere/somehow.
Hmm, I'll also check that the ANEs have definitely been updated when uploading! I may have missed them from the push to the repo.
The ODK has changed, so if you've updated your OUYA at all, then the old Controller ANE is probably broken from those changes... maybe?
I wish we could put relative paths in the projects, then this issue wouldn't happen. As I could just set the ANE discovery path to something like "../ane/blah.ane" and be done with it. But apparently it's an issue with Eclipse, not just Flash Builder.
Anyway, glad that you have it running!
Or am I wrong? Is there a way to specify that file getting copied to the right place by using the descriptor file?
And again: do you know whether anyone's shipped an Ouya game using AIR tech? Will I be the first?
Has anybody successfully implemented Adobe's own "GameInput" extension yet?
http://www.adobe.com/devnet/air/articles/game-controllers-on-air.html
Despite including the SWC provided, I'm getting "Class flash.ui::GameInput could not be found" on AIR 3.8 at the desktop.
Seems I was naive to think I could test it on Windows with an Xbox controller, but I don't yet own an OUYA.
With that error, have you definitely updated all of your SWC's?
I always try to target a completely new Flex folder when copying/updating the AIR components... then use that to overwrite those in the Flash Builder install directory. Hope that makes sense :-)
<extensions>
<extensionID>com.gaslightgames.OUYAControllerANE</extensionID>
<extensionID>com.gaslightgames.AIROUYAIAPANE</extensionID>
</extensions>
...Flash Builder added these automatically when I added the ANE's, but this step might need to be done manually.
Once you have your project linked to the latest AIR, then the Game Input API is part of it, so you shouldn't need to add the SWC again. If you can call "import blah.blah.GameInput" and Flash CS6 finds that package, then you should be OK.
The OUYA Controller ANE will only work on the OUYA. You'll get isSupported() returning "false" on any other platform, so that your app will still compile, just wont do anything.
Also, GameInput only works on Android - I got stung by that when trying to test on Windows. There are WIndows controller ANEs, but they're a little sketchy iirc - of course, they could be amazing and my quick glance was insufficient and I'm totally out of touch with how they work!