• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Android Google Play Billing extension problem

Hi Gamemakers!
My app is using old Billing extension and as of September, my players can not make purchases anymore.
I am using GMS version 2.2.5.481 because I had major bugs appear in game after migrating to 2.3, so I reverted back.
Now, I can't find an updated Google billing extension for GMS 2.2.
Also, I can't log in to Marketplace, the log-in screen does not show input fields.
Yoyo tech support does not accept tickets for GMS 2.2 anymore.
Please help!
 
That's the extension version I have now, Google store now disabled purchases for this version. (It was supposed to happen in November, but no...they rushed it)
 

FrostyCat

Redemption Seeker
I have proof they were not supposed to change it until November 1st. Is it because of the lawsuit?
No, it was because the migration was designed to be in 2 steps.

The first deadline just passed on August 2. That was the date after which new products began to be rejected if they used Billing API v2 or below.

The second deadline will be on November 1. That is the date after which product updates will be rejected if they still use Billing API v2 or below.

See: Google Play Policies
Starting August 2, 2021, all new apps using Play Billing must use Billing Library version 3 or newer. By November 1, 2021, all updates to existing apps using Play Billing must use Billing Library version 3 or newer.
You have had more than a year to figure out what the incompatibilities with GMS 2.3 are and either fix or rewrite them, but you didn't take the opportunity. YoYo will not and cannot help anymore. If I were you, I'd bite the bullet and start reworking the project for GMS 2.3, instead of waiting for rescue.
 
@FrostyCat
Starting August 2, 2021, all new apps using Play Billing must use Billing Library version 3 or newer. By November 1, 2021, all updates to existing apps using Play Billing must use Billing Library version 3 or newer.
My app is existing, I was posting an update to it.

Before this, I didn't even think there will be a problem finding one of the most used extensions. When I first created the game, I really didn't know what I was doing, so I created Json save system where instead of asset_get_index I used sprite_index=.... In GMs2.3 this created lots of problems and I don't know how to fix it. The game is live and I have active players who would hate to lose months of progress. I don't know how to fix it, honestly.

@Mert
Thank you for the tip!
 
My last update went in on August25th and the last purchase was made on August30th, so it 's must have been working fine until that point. It means that my app was not a part of the August deadline.
I thought I had two months to work out the Billing problem...unless I live in a bizzaro world...is it still September for everyone else, no?
 

chamaeleon

Member
When I first created the game, I really didn't know what I was doing, so I created Json save system where instead of asset_get_index I used sprite_index=.... In GMs2.3 this created lots of problems and I don't know how to fix it.
With the understanding that you have carefully backed up your project and can easily undo what I mention, create an object whose sole purpose in life is to create a mapping from id number to asset name in your existing project (using the same version of GMS that you used for creating the game that saves using numbers instead of names to ensure the mapping is valid). When moving forward with switching to using names instead of hard-coded asset id numbers in save files, add something in your JSON file to indicate it is a new version (perhaps a top-level version key to a number or a string).

When saving using a new version of the game, use the new format that is more resilient to changes.

When loading a save file using the new version of the game, check for the presence of the version field in your ds_map (I assume, if implemented before structs). If you don't find it, iterate through the saved data and replace the values of relevant entries with the name of an asset based on looking up the key you have previously generated, and perhaps save the result right away using the new format. How you include the mapping in your new version of the game doesn't matter. Maybe it's hard coded as GML code, perhaps it's an included file in a more or less easy to parse format.

Whether this is feasible depends an awful lot on whether you have more than one version out in the wild, and whether they use different ids due to your development efforts.
 
It didn't work for me then because I guess I created new save file in GMS2.3? Maybe I don't belong on these forums as I still don't understand a lot of what has been explained to me.
What I did in February (roughly, I don't remember now)


Code:
///load in room start event

if instance_exists (starter_o) //only run once at the game start, loops  once through all of the rooms

{

if version=1

{

if file_exists ("whatever.sav")

{

//lists and maps  here, not gonna type it here

        sprite_index= asset_get_index(a_map [? "sprite_index"]);

}}



if version=0

{

if file_exists ("whatever.sav")



{

//lists and maps  here, not gonna type it here

sprite_index=a_map[? "sprite_index"];

}

version=1

}

}
save code for version=1

ds_map_replace (a_map,"sprite_index", sprite_get_name(sprite_index))

version is saved to another file

After that, on my internal test from Google, sprites showed up all screwed up. After two weeks of trying, I said @#$! it and went back to 2.2.4. In my country we have a saying
"Don't fix it if it's not broken".
Well, well, well...look who is crying now.
 
Last edited:
Did anyone ever do this : replace existing sprites created by GMS in the project file with Tinypng compressed png ? ( I was able to get my .aab file from 275mb to 103 mb by doing this). Could this be the root of the problem why my sprites messed up in GMS2.3? If so...
 
I would not replace the sprites with compressed ones directly in the folder, sounds like asking for all sorts of trouble. You can however use gml_pragma("PNGCrush"); to reduce your final game size.
You just put this line of code basically anywhere (I recommend in an initiation script, tho, just for organization)
gml_pragma
 
Top