The Openbrowser() command needs a catch in it for java and probably obj-c too
Currently the correct method to link to other apps like Google Play or Facebook is something like this:
Google Play
market://details?id=com.naplandgames.sudokuinspace
Facebook
fb://profile/yourprofileid

These links will open the native apps (i.e. Google Play Store or Facebook) if they are installed. Unfortunately if they are not installed then the app will crash because there is no exception catch. Makes the app look bad.

A great alternative would be if OpenBrowser returned a pass/fail value so that we can attempt a different URL if the first fails and so forth. Would be really easy to do in java, but the Openbrowser command doesn't seem ot have any java companion code...

PS - I'll work on updating the original thread soon with the suggestions.
Maybe when Paul is ready to consider some of this stuff then we can do a poll to help him set priority.

I bought AppGameKit 2 for one reason only, and that was so as I could create a Bluetooth Serial connection with an Android and IOS device.

Still waiting...

SPARTAN:
That has, to my knowledge, never been announced or even talked about.

The promised enhancements to the 3D Engine tops my wish list.

Support for multi-textured .x models would allow me to port my work across from DarkBasic. Bone based animation isn't essential, although it would allow for FPSC models to be used.

AGK is a fantastic product to work with and better 3D support would allow for some really exciting games to be made with it.

Here's another feature request that we get sometimes and I've forgotten about. It's something I would want.

Media protection - Some way to pack our media files so they are not as open and visible as they are now. This of course is something we only need for Windows and Mac OS (and Linux). Android and iOS releases are already protected in some way. This could potentially be a required to use royalty free media or getting help from artists/composers etc.

Media protection would be great. I thought Paul said somewhere that they were going to do this, but I can't find it.
Android and iOS are not really protected much. If you root your device (or jailbreak) you can pretty easily get to the assets folders. For this reason I encrypt anything I want protected.

Still is better protected than on PC. Sure would be nice with good protection but even simple protection is better than none.

Indeed, but I worry that whatever they implement will be terribly slow. But then again it can't be much slower than opening a file, unencrypting it, saving it, loading it, and then deleting it... though I've never noticed any slow down with that, it is invariably slow. I also worry that whatever they implement will still be able to be read by any other person who buys AGK. Some simple xor encryption works very well for me.

Are you doing your own encryption using memblocks or something else?

I make a "key" array and hard code it into the program.
The just open the encrypted file to read, open a destination file to write to, read each byte of the encrypted file that I need to, xor the bytes with the key and write the bytes to the destination file, load the file (I do this mainly with images), and then delete the file.
For Wordspionage I used a memblock for the game data file because it was potentially too large and used too often to justify the above process. But it gets written a lot anyway.
Surprisingly there has been little to no difference in the two methods. Mobile devices seem to be just fine with this. Also all of my images are in atlases so it's not done very often at all. It's a very simple, efficient, and effective method. Someone could probably crack it for the images, but with the key hardcoded I feel like it wouldn't be easy. That is unless you were fast enough to halt the program right between the save/load/delete phase. I've tried doing this on my Windows machine and it hasn't been possible

With the image and sound facilities in memblocks there isn't a lot of need to actually save the file at all.

Probably, but it sure is easy. To do an image memblock requires knowledge of the image file structure and that can be a pain. Just not worth the time.

What do you do when you xor the bytes?

To do an image memblock requires knowledge of the image file structure and that can be a pain. Just not worth the time.

I don't understand. What's wrong with:

image = LoadImage("my_image.jpg")
memblock = CreateMemblockFromImage(image)
decrypt the image data
CreateImageFromMemblock()

@DA - I'm not sure what you're asking exactly. I have an array that is the key. The process loops through the array with each byte and xors it. Then I save the new byte to a file.

@Jim - Really? That's it? After reading the command's help file it seemed much more complex. Maybe I'll try what you say, though I've already got all of my commands written for encryption the other way and they are plenty fast.

Naphier - The key factor if you want to keep small jpgs is to encrypt them using an external program, and in that case, don't write over the header area. Only decrypt inside AGK.

I can knock up an encryption program using Delphi in about 10 minutes if that would help you guys.

Thanks, Jim, but that's OK. What I use only takes about 30 lines of code and I'm very happy with it. Here it is for anyone who wants it.
I use the same function to do the encryptions. Just make up your own key. I only show an 8-byte key here for simplicity, make it as long as you want.

Naphier:
Looked up bitwise operators, now I get what you mean

The new sound commands are very good. But it would be handy not to have to get the sound instance immediately, but wrap that into an overloaded PlaySound() which would take an additional two parameters: Balance and Rate.

I would put that above the not yet implemented Priority.

So I would like to see:

integer PlaySound( iID, iVol, iLoop, fBalance, fRate, iPriority )

That would be easy to implement in the library and would save a lot of extra code in programs.

HTTP POST HEADER VALUES: The ability to set custom header values when doing a http POST command. Without this, the ability to integrate into back-end systems would be extremely crippled.