When I preview the game by clicking on either purchase or restore, this message appears "In App is not supported in the Viewer." How can I simulate the user experience and see what it would look like when I purchase, restore or cancel? No matter which actor I press, the same message always appears.
You can only test the IAP to a limited extent in the Viewer. You'll always get this message, and you'll get a message saying the game is sending the request to fill the table, and a message saying the game is attempting to send a purchase request, but the table itself is not filled so you cannot accurately test. I set up that template to allow you to "simulate" the responses you might encounter (table fill success, failure, purchase success, failure etc.) but to test IAP you need to put the game on your device.
Are the "Purchased" "Pending" and "Unpurchased" expressions case sensitive? Would an in actor text expression not recognize the table cell value because one is uppercase and the other lowercase?
I honestly can't remember for certain, but it seems safe to assume they are.
What's stopping someone from purchasing a non-consumable "remove ads and unlock full game" IAP, playing the full game, and then just restoring the IAP when done?
I'm not sure I understand the question. Are you saying what's to stop someone buying the IAP, requesting a refund from Apple for the IAP, then enjoying the still unlocked game? Very little. But very, very few people would do this. If you wanted to you could avoid this to some extent by running the "Restore" behaviour every time they launch the game, but like most anti-piracy measures that'll annoy your honest customers way more than it'll stop the dishonest ones.
I don't understand the point you're trying to make. Simply that a gamer can unlock the full game across different platforms by tapping on "restore purchase" once she/he purchased the non-consumable IAP?
Just to verify, the ID you use to refer to your non-consumable IAP when coding is "item", correct? Meaning I would have to substitute that with the corresponding ID I use in iTunes connect.
What if I just change that to tableCellValue( game.PurchaseTable ,1,1) [I am still waiting to set the ID part up within iTunes connect]. Would it work just as well?
As explained, I am offering four levels for free. When tapping on "next level" I will trigger the non-consumable IAP. There is no tidy way I can incorporate the "restore now" in that same page. What if I create a "restore now" button in my splash page. Would that make a difference?
and you'll get a message saying the game is sending the request to fill the table, and a message saying the game is attempting to send a purchase request
I only got these messages in your template. In my game, when I dismiss the the "not supported in viewer" message, I am free to move on to the next page, what am I doing wrong?
It seems safe to assume they are case sensitive.
Do we know whether Apple uses uppercase or lowercase when changing the IAP's state?
@gfb08174 said:
1. Just to verify, the ID you use to refer to your non-consumable IAP when coding is "item", correct? Meaning I would have to substitute that with the corresponding ID I use in iTunes connect.
Correct. It needs to be the same in three places: 1. The Buy behaviour. 2. The PurchaseTable table. 3. iTunes Connect.
What if I just change that to tableCellValue( game.PurchaseTable ,1,1) [I am still waiting to set the ID part up within iTunes connect]. Would it work just as well?
That should work. I personally prefer to put it in each place by hand when that's an option, but there are times it's not really an option and my reasons for doing it by hand are pretty much non-existent, other than "because I do".
As explained, I am offering four levels for free. When tapping on "next level" I will trigger the non-consumable IAP. There is no tidy way I can incorporate the "restore now" in that same page. What if I create a "restore now" button in my splash page. Would that make a difference?
As long as you put the Restore button somewhere, it should be fine.
Do we know whether Apple uses uppercase or lowercase when changing the IAP's state?
Do you mean the "unpurchased/pending/purchased"? These are set by GameSalad based on things happening that we don't see, and as far as I'm aware they're always lowercase.
Is there nothing unusual then about the fact that I can move on to the next level by simply clicking "back" when the notice "In App is not supported on the Viewer" message shows? Clicking "back" also doesn't change the "state" of the IAP (I think). I very much liked the message format of the deprecated IAP behavior, and it's what I've become used to now. This new format is causing me quite some confusion (subtle hint to the GS Team)
I've got to program this code into several dozen actors now so I want to get this correct right off the bat.
Since this is also to remove ads, I have to go to the prototype of my ad banner actor, and create a rule that says:
when game.itemPurchased is false
Show banner
Otherwise
Destroy this actor
Right?
Another idea popped to mind. What if the "restore IAP" actor in my splash screen also serves as an "unlock levels/remove ads" actor when tapped? This would allow gamers to keep playing without interruption and without being asked to buy the game come level.
For example: When game.itemPurchased is false display text: retrieve (and carry out the retrieve behaviors) otherwise: display text: unlock (and carry out the purchase IAP behaviors).
@gfb08174 said:
1. Is there nothing unusual then about the fact that I can move on to the next level by simply clicking "back" when the notice "In App is not supported on the Viewer" message shows? Clicking "back" also doesn't change the "state" of the IAP (I think). I very much liked the message format of the deprecated IAP behavior, and it's what I've become used to now. This new format is causing me quite some confusion (subtle hint to the GS Team)
Since when you click Back in the Creator, nothing has actually happened yet - no table data has changed, nothing should have triggered your "bought" attribute - this implies it's an issue elsewhere in your logic, either in how you're controlling the move to the next level, or your in-app logic (you must be triggering the change of your "bought" attribute before it's supposed to be triggered). You can easily check by displaying the "bought" attribute with a Display Text and seeing when it gets changed. If it doesn't get changed, the problem isn't related to in-app, if it does, you're triggering incorrectly.
I've got to program this code into several dozen actors now so I want to get this correct right off the bat.
The vast majority of the logic can be placed in one (or two counting the restore button) actors. There's no need to put it in each actor - in fact, that might cause avoidable confusion!
Since this is also to remove ads, I have to go to the prototype of my ad banner actor, and create a rule that says:
when game.itemPurchased is false
Show banner
Otherwise
Destroy this actor
Right?
Sure, something like that should work.
Another idea popped to mind. What if the "restore IAP" actor in my splash screen also serves as an "unlock levels/remove ads" actor when tapped? This would allow gamers to keep playing without interruption and without being asked to buy the game come level.
Assuming you want to be running the restore request automatically, this should be able to work. You should note though that you still need to fill the PurchaseTable first, and I personally recommend against doing this un-prompted. It can cause a "enter your password" prompt to pop up, and that can freak some users out ("I just launched this game and it wants me password!"). But if you're happy with that, yes you could combine the buttons. However, Apple might reject you if you don't have a Restore button. I'm not sure if anyone has tried just adding a note to their submission saying "Restore items is attempted automatically".
Since when you click Back in the Creator, nothing has actually happened yet - no table data has changed, nothing should have triggered your "bought" attribute - this implies it's an issue elsewhere in your logic, either in how you're controlling the move to the next level, or your in-app logic (you must be triggering the change of your "bought" attribute before it's supposed to be triggered). You can easily check by displaying the "bought" attribute with a Display Text and seeing when it gets changed. If it doesn't get changed, the problem isn't related to in-app, if it does, you're triggering incorrectly.
I can't get it to work. I tried everything, moving it in, and out of rules, but nothing. I must be overlooking something banal. I've spent all day on this and haven't gotten any studying done. Could you please take a look at what I'm not seeing? As you can see, clicking "next" just allows you to move on instead of telling you to purchase an IAP in order to move on. It's driving me nuts.
Assuming you want to be running the restore request automatically, this should be able to work. You should note though that you still need to fill the PurchaseTable first, and I personally recommend against doing this un-prompted.
I agree with not harassing people with logins. So there's no way for the prompt to only fire up when the player taps on the restore icon?
ie.
When actor receives tap AND game.itemPurchased is false display text: retrieve (and carry out the retrieve behaviors) otherwise: display text: unlock (and carry out the purchase IAP behaviors).
@Armelline thank you for taking a look. I really appreciate that a lot.
How would you distinguish between people who need to restore and people who have never bought a purchase and need to buy it for the first time?
When a gamer taps on the restore actor they will be prompted to log in, if they aren't already. When logged in, the relevant IAP's state will be fetched. It will be either unpurchased, or purchased. There are then two routes to follow depending on the table's state. A simple restore, if it's already purchased, or an outright purchase as you showed in your template.
It’s a good idea to have another table that stores the values that can be changed by your IAP’s and to save that table when a purchase is made (only the saving is shown in the image below not the table change). This will ensure that the users purchases will be saved and they won’t have to restore their purchases every time the game is closed etc.
The secondary table, as well as the timer saving the table every 0.03 seconds.
Did you replace this part with the game.ItemPurchased boolean and save attribute just without the timer?
I am hoping that someone can possible glance at my IAP setup and tell me why its not working. I have tried everything i can think of. This is the base at which i started. I have tried setting it up just lake Gamesalad Guru did in his video, and like Armelline did in his, and neither worked. When i first started testing on my ipad with my sandbox account, it would prompt me all the time for the password. Now, it never prompts me and the purchase never works. Or the purchase get started and will only finish after i close the game and come back. I am truly frustrated, but i am wondering if this should work and maybe there is an issue with my ipad setup?
I would appreciate any help or suggestions the community has.
No solution yet. Although it seems as though it should work, it does not work correctly. I am going to have to build in some controls and troubleshooting to see if I can determine where this is going wrong. Beyond that i am not sure. I am slowly growing increasingly frustrated with lack of support and issues in gamesalad. @gfb08174
@gfb08174@kganczak I'm afraid you're going to struggle to find solutions to your problems on the forums. They're problems that will require carefully looking at the logic, asking you a number of questions, and most importantly on device testing to see exactly what point things are going wrong. It's unlikely someone is going to spend 1+ hours working out an IAP issue for someone else - people will find help on the forums if the questions is quick to answer or an interesting problem that's fun to solve. I'm afraid neither are true in both your cases.
@kganczak Your rules posted above will definitely not work, but the suggestion I would have first made you mentioned in your last email you'd already done. My next step would be to set up a bunch of monitoring display texts and then run some tests on device using an ad hoc build. I'm afraid without seeing the changes you made since the screenshots and the results of those tests I'm not sure what I'd recommend next.
@gfb08174 I looked at your project and on an initial glance it looks fine, but again on device testing will be needed to establish exactly what's going wrong and exactly what point it's going wrong. Again, I just don't have time (or, to be honest, the motivation) to be pushing ad hoc builds to trouble shoot an issue that will take non-nominal amounts of time.
This is further compounded by this kind of issue being exactly the kind of thing I will charge people for. I'll sometimes help someone with an issue like this for free, despite the time involved in doing so, but only when I have an abundance of free time myself. Right now I'm afraid I simply don't have that free time. I can make time for paying customers but I have far too much I need to be doing in my free time to be so generous as to do it for free. This is boring stuff, I'm afraid, so you're going to struggle to find someone who will.
I'd recommend you both post your problems in separate threads with clear titles and detailed explanations of what you've tried so far, as well as screen shots of the state of the purchase table, call back attribute and whatever attribute you're changing upon successful purchase, before, during and after a purchase attempt. You'll be much more likely to get responses to individual threads than at the end of an old thread that most people are going to skip over. It's vital you provide as much information as you can, though.
Comments
You can only test the IAP to a limited extent in the Viewer. You'll always get this message, and you'll get a message saying the game is sending the request to fill the table, and a message saying the game is attempting to send a purchase request, but the table itself is not filled so you cannot accurately test. I set up that template to allow you to "simulate" the responses you might encounter (table fill success, failure, purchase success, failure etc.) but to test IAP you need to put the game on your device.
I honestly can't remember for certain, but it seems safe to assume they are.
I'm not sure I understand the question. Are you saying what's to stop someone buying the IAP, requesting a refund from Apple for the IAP, then enjoying the still unlocked game? Very little. But very, very few people would do this. If you wanted to you could avoid this to some extent by running the "Restore" behaviour every time they launch the game, but like most anti-piracy measures that'll annoy your honest customers way more than it'll stop the dishonest ones.
Do Apple even do refunds on IAP, though?
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
No they don't (it's in one of their agreements) so this is a non issue
My guess is a big reason they don't, then, is to avoid this becoming an issue.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
yes, they do what they legally can in order to try to prevent people from abusing their systems
Can't wait for this, very helpful of you mate
@NipaDidIt
I don't understand the point you're trying to make. Simply that a gamer can unlock the full game across different platforms by tapping on "restore purchase" once she/he purchased the non-consumable IAP?
@JSproject @Armelline @NipaDidIt
I understood "restore" to mean, "return" and "refund" instead of, "retrieve data".
@Armelline
What if I just change that to tableCellValue( game.PurchaseTable ,1,1) [I am still waiting to set the ID part up within iTunes connect]. Would it work just as well?
I only got these messages in your template. In my game, when I dismiss the the "not supported in viewer" message, I am free to move on to the next page, what am I doing wrong?
Do we know whether Apple uses uppercase or lowercase when changing the IAP's state?
Correct. It needs to be the same in three places: 1. The Buy behaviour. 2. The PurchaseTable table. 3. iTunes Connect.
That should work. I personally prefer to put it in each place by hand when that's an option, but there are times it's not really an option and my reasons for doing it by hand are pretty much non-existent, other than "because I do".
As long as you put the Restore button somewhere, it should be fine.
Do you mean the "unpurchased/pending/purchased"? These are set by GameSalad based on things happening that we don't see, and as far as I'm aware they're always lowercase.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
@Armelline thank you.
I've got to program this code into several dozen actors now so I want to get this correct right off the bat.
Since this is also to remove ads, I have to go to the prototype of my ad banner actor, and create a rule that says:
Right?
For example: When game.itemPurchased is false display text: retrieve (and carry out the retrieve behaviors) otherwise: display text: unlock (and carry out the purchase IAP behaviors).
What do you think
Since when you click Back in the Creator, nothing has actually happened yet - no table data has changed, nothing should have triggered your "bought" attribute - this implies it's an issue elsewhere in your logic, either in how you're controlling the move to the next level, or your in-app logic (you must be triggering the change of your "bought" attribute before it's supposed to be triggered). You can easily check by displaying the "bought" attribute with a Display Text and seeing when it gets changed. If it doesn't get changed, the problem isn't related to in-app, if it does, you're triggering incorrectly.
The vast majority of the logic can be placed in one (or two counting the restore button) actors. There's no need to put it in each actor - in fact, that might cause avoidable confusion!
Sure, something like that should work.
Assuming you want to be running the restore request automatically, this should be able to work. You should note though that you still need to fill the PurchaseTable first, and I personally recommend against doing this un-prompted. It can cause a "enter your password" prompt to pop up, and that can freak some users out ("I just launched this game and it wants me password!"). But if you're happy with that, yes you could combine the buttons. However, Apple might reject you if you don't have a Restore button. I'm not sure if anyone has tried just adding a note to their submission saying "Restore items is attempted automatically".
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
@Armelline
I can't get it to work. I tried everything, moving it in, and out of rules, but nothing. I must be overlooking something banal. I've spent all day on this and haven't gotten any studying done. Could you please take a look at what I'm not seeing? As you can see, clicking "next" just allows you to move on instead of telling you to purchase an IAP in order to move on. It's driving me nuts.
http://www.mediafire.com/download/p1ai98w5fzfpr4m/please_help_me.zip
I agree with not harassing people with logins. So there's no way for the prompt to only fire up when the player taps on the restore icon?
ie.
When actor receives tap AND game.itemPurchased is false display text: retrieve (and carry out the retrieve behaviors) otherwise: display text: unlock (and carry out the purchase IAP behaviors).
Why couldn't that work?
I'll take a look as soon as I have some time.
How would you distinguish between people who need to restore and people who have never bought a purchase and need to buy it for the first time?
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
@Armelline thank you for taking a look. I really appreciate that a lot.
When a gamer taps on the restore actor they will be prompted to log in, if they aren't already. When logged in, the relevant IAP's state will be fetched. It will be either unpurchased, or purchased. There are then two routes to follow depending on the table's state. A simple restore, if it's already purchased, or an outright purchase as you showed in your template.
No?
I read this and noticed you omitted or substituted two steps. https://help.gamesalad.com/hc/en-us/articles/202036553
The secondary table, as well as the timer saving the table every 0.03 seconds.
Did you replace this part with the game.ItemPurchased boolean and save attribute just without the timer?
I am hoping that someone can possible glance at my IAP setup and tell me why its not working. I have tried everything i can think of. This is the base at which i started. I have tried setting it up just lake Gamesalad Guru did in his video, and like Armelline did in his, and neither worked. When i first started testing on my ipad with my sandbox account, it would prompt me all the time for the password. Now, it never prompts me and the purchase never works. Or the purchase get started and will only finish after i close the game and come back. I am truly frustrated, but i am wondering if this should work and maybe there is an issue with my ipad setup?
I would appreciate any help or suggestions the community has.
@kganczak
did you find a solution?
No solution yet. Although it seems as though it should work, it does not work correctly. I am going to have to build in some controls and troubleshooting to see if I can determine where this is going wrong. Beyond that i am not sure. I am slowly growing increasingly frustrated with lack of support and issues in gamesalad.
@gfb08174
@gfb08174 @kganczak I'm afraid you're going to struggle to find solutions to your problems on the forums. They're problems that will require carefully looking at the logic, asking you a number of questions, and most importantly on device testing to see exactly what point things are going wrong. It's unlikely someone is going to spend 1+ hours working out an IAP issue for someone else - people will find help on the forums if the questions is quick to answer or an interesting problem that's fun to solve. I'm afraid neither are true in both your cases.
@kganczak Your rules posted above will definitely not work, but the suggestion I would have first made you mentioned in your last email you'd already done. My next step would be to set up a bunch of monitoring display texts and then run some tests on device using an ad hoc build. I'm afraid without seeing the changes you made since the screenshots and the results of those tests I'm not sure what I'd recommend next.
@gfb08174 I looked at your project and on an initial glance it looks fine, but again on device testing will be needed to establish exactly what's going wrong and exactly what point it's going wrong. Again, I just don't have time (or, to be honest, the motivation) to be pushing ad hoc builds to trouble shoot an issue that will take non-nominal amounts of time.
This is further compounded by this kind of issue being exactly the kind of thing I will charge people for. I'll sometimes help someone with an issue like this for free, despite the time involved in doing so, but only when I have an abundance of free time myself. Right now I'm afraid I simply don't have that free time. I can make time for paying customers but I have far too much I need to be doing in my free time to be so generous as to do it for free. This is boring stuff, I'm afraid, so you're going to struggle to find someone who will.
I'd recommend you both post your problems in separate threads with clear titles and detailed explanations of what you've tried so far, as well as screen shots of the state of the purchase table, call back attribute and whatever attribute you're changing upon successful purchase, before, during and after a purchase attempt. You'll be much more likely to get responses to individual threads than at the end of an old thread that most people are going to skip over. It's vital you provide as much information as you can, though.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support