Instant Games Plugin - Needed implementations

I know that there is an appropriate place for posting suggestions and requests, but the request in question is here: construct3.ideas.aha.io/ideas/C3-I-486

That was tagged as 'Need more detail' months ago and get buried down by other requests. Now I think all details was given already in the comments, aso the Idea has 31 votes by now. I think this is enough to consider.

So there are at least two very important things to implement:

ChooseAsync - We can already use it with exec javascript, but we need the event that triggers when the context changes successfully or when the dialog is closed.

UpdateAsync - We already have the leaderboard updates, but would be great to have custom updates, with the possibilities to add images, etc.

For who have interest in theses features, please upvote the idea. Also who have more request for this plugin, please post here so we could group all requests into one.

There has been a disussion about this plugin in the plugin forum.

I agree with you 100% that this plugin lack some basic features.

Aside from the two functions you mention I also would like to see:

canSubscribeBotAsync( ) And subscribeBotAsync( )

switchGameAsync( )

getSupportedAPIs( )

construct.net/en/make-games/addons/140/facebook-instant-games-extended

canSubscribeBotAsync( ) And subscribeBotAsync( )

Not added to the plugin yet, but i'm looking into this for the next update.

Hi macube. I have looked into your plugin! Seems promising.

As discussed in the plugin forum you need to change the ID after chooseAsync. Otherwise nothing will work. And your plugin does not do this. Look into the thread where me and ashley discuss this.

Also, with your plugin you need to paste the base64 pic. Which is basically the same as using just javascript.. i think people want to use an image in the layout, just like with the official plugin share function.

But I appreciate the effort with your plugin and looking forward to updates :)

The ID-change not work? Really?

I'm call the function from ashley. Hm..

Hey Ashley, could you take a look? Sorry to bother you, I think you missed this topic.

It's difficult to interpret a suggestion that just says to expose a JavaScript API. It's not a good user experience and goes against Construct's design to just let users call JavaScript APIs directly, it's always wrapped in higher-level conditions, actions and expressions. If the suggestion doesn't specify how that is done then it's not clear how to go about it, especially when these are complex APIs which cover a wide range of features, some which probably need to be supported, and some which probably aren't feasible to support in Construct (e.g. bots). So it's still not at all clear to me which parts are necessary and how it would actually look and work in events, hence 'need more detail'.

Can you put that on the suggestion platform? That's the kind of helpful detail that helps explain what the suggestion is aimed at.

Can you put that on the suggestion platform? That's the kind of helpful detail that helps explain what the suggestion is aimed at.

Updated: construct3.ideas.aha.io/ideas/C3-I-486

Hope this helps

You added more things than the original suggestion covered - please try to avoid that, it confuses the purpose of the suggestion and makes it harder to track, any different ideas to the original post should be posted separately. That suggestion will be treated as referring to the original description only.

FYI I can't see any reason to support getSupportedAPIs(), since you can't do anything with them from events. If there are features which are only sometimes supported, we'd add separate conditions to cover them, but AFAIK there are no such features yet.

Ok, sorry for that.

Here is a new idea then with the two other functions, which are basically the two easiest I believe. Hope the description is fine.

construct3.ideas.aha.io/ideas/C3-I-669

You added more things than the original suggestion covered - please try to avoid that, it confuses the purpose of the suggestion and makes it harder to track, any different ideas to the original post should be posted separately. That suggestion will be treated as referring to the original description only.

FYI I can't see any reason to support getSupportedAPIs(), since you can't do anything with them from events. If there are features which are only sometimes supported, we'd add separate conditions to cover them, but AFAIK there are no such features yet.

Well, so you can just consider what the original suggestion requests. ChooseAsync (with its callbacks) and UpdateAsync.