Godot 3 - API 1.2

[Endojo]

This is not really an issue but I had no idea where to put this

I just wanted to let you know that I was glad to find your code for using the GameJolt API.
I made some changes to the code to use the 1.2 API (seems like you are in the same progress which I didn't know when I started programming)

So this "issue" is just for posting the changes: https://pastebin.com/nFxbhf33 - I commented what I changed, so if you're interested you may check it out :)

(without comments it's <180 lines but the new API features like friends are still missing)

Maybe you don't like some changes but I figured that there is no harm in posting them ;)

Thank you for making this!

[rojekabc]

Hi.
When do you plan to merge your branch with master for gamejolt API in version 1.2?
Greetings.

PS: Anyway I append pull request for this changes. It's a little code refactoring with possibility of hide unwanted messages and switch to use HTTPS to protect from man in the middle attack. I append current set of certificates to allow Godot to connect with GameJolt via SSL.

[Endojo]

Probably I do it in the next few days.
Because my changes affect largly only the coding style, I'm totally fine if this pull request gets rejected.
As you probably noticed: I originally used an old version of this plugin, so many changes might be redundant.

[rojekabc]

I think, that the good solution should be clean up this repository and create branch version for oldest version. Than replace everything with new version and use it as current branch. I don't like keeping and maintain old staff if it's not highly needed.

[Endojo]

I agree, it also seems not optimal to me to have two versions of the plugin in different folders, not branches.
But since this is my first involvement in a public github project I'm completely inexperienced in these things 😄

Also I'd like some more drastic changes which in my opinion help in real use cases of this plugin but also change it quite a bit

[rojekabc]

Wow - what sort of changes do you mean? I'm interested in anyway ... :)
I've just detect in version 2 little bug and I've fixed it.
Every time I'm looking into this code I'm thinking about REFACTORING.
I don't like how it looks right now and I may help with this.

[Endojo]

I'm currently refactoring the code and will commit it later.
There are some odd design choices which definetly make the code harder to read. But you can do nothing about it being largely a collection of simple functions

About the sort of change I meant:
Signals for returning the requested data are subobtimal because the response often only makes sense in combination with the request, e.g. if you request different highscore tables with different objects.

So I stripped the signals and implemented a new function so you can use
GameJoltAPI.callback(_your_funcref).fetch_table(...)

Doesn't require much code but because it changes how you use this plugin it's definetly something for another branch.
Also maybe it's possible to create synchronuous code with yield() waiting for the http response. Right now you need several callbacks if you want to know your current score and then request the part of the highscoretable surrounding it. But since it's bad design if the game freezes until it recieves the response of the GameJolt servers I'm not sure how to implement it.

[rojekabc]

yield() not freeze the game. It outs from function, where is placed (without execution of code next of it exactly in this function).
And then returns back, when receive the signal from yield and executes the rest of the code from function in which is placed.

[Endojo]

I was partly aware of that, but am not sure how it behaves in something like the following scenario:
If you have e.g. a label that you use to show the server time but don't want to use a signal / callback the api could look something like

var json = $GameJoltAPI.blocking().fetch_time() if json.success == "true": $Label.text = str(json.timestamp)

Here using a signal wouldn't hurt but I with more subsequent calls an API as above would be great.
But if you do that in e.g. func _process(delta), and the function yields until the response is recieved, would that work as expected?

[rojekabc]

If you create for label something like this:
_process(delta): send_request() yield("response_signal") text = update from response
Than godot will back to this function after after receive signal expected in the yield.
The problem is, that most thinking, that yield is something like wait for the threads and IT'S NOT.

For example. More common mistake, which is done is something like this:
'
func hello():
print('Hello start ')
yield('signal_x')
print('Hello end')

func caller():
print('Caller start')
hello()
print('Caller end')
'
And people thinking, that when there's a yield from caller, than it'll wait inside hello. In the fact yield make return from hello and go on. So the output will be
'
Caller start
Hello start
Caller end
Hello end <- This will come only when signal will be rise up. If not - it'll be never
'

[Endojo]

Which means that I can't use yield in this context because the plugin would return to the users code immediately - so the user has to wait himself for the request to finish.
So the simplest code possible would be

$GameJoltAPI.fetch_time()
var json = yield($GameJoltAPI, 'request_finished')
do something with it...

which has a little problem: I just implemented a queue to avoid errors if busy, which in my opinion is more important than the ability to yield.
yield - ing is no more possible because as far as i know you can't create new signals on the fly and some fixed signal like 'request_finished' might not be signalling the request you're actually waiting for.

[rojekabc]

The problem of do this will be, that if someone calls this:

• yeild will exit from fetch_time (and mark as waiting for signal)
• than function, which calling API will do the rest of it's work
• when the signal back only the part from fetch_time function after yield will be done

So - User will not get a response in this case (it'll be straight null). I not recommend do the yield inside API.
I may propose rather to build this API with callback function, which will be called, when response is received inside API plugin. Then user may attach its own dedicated callback for any of call as option. And This will be called in case of response.
And yes - building sub-sequential calling of API in this case will put a little troubles, because the path should be done in this case one callback functionality by next one.

[Endojo]

So it seems like the only way is to create a seperate callback function for each step if you need many subsequential calls.
I already implemented user callbacks and a queue but don't know how to make those changes public 😀

[rojekabc]

As I see well you're only the owner of your fork of ackens repository (similar as me right now).
So - you may push your changes into your branch/master and pull request about merging changes with master on ackens.
But it looks, that ackens not responses. So - Your changes will be exposed only in your fork. Anyway - I'll look on them and think, that I may cherry-pick something of that into my fork.
This is a power of git :) If the owner of repository will not work any more we may contribute in the fork....

I have done already some changes inside my fork (totally rebuild) and I'm thinking about next changes.

Do you know how to use git? (Are you using command line or some IDE?)

PS: I'm just thinking about this. Because I'll hit quite similar problem as you. For me, the conclusion right now is to do something like this:

• Remove all signals from this plugin
• Store received response information/error in the gamejolt plugin
• Emit signal gamejolt_request_complited
• Create function to read data stored in the gamejolt plugin
  So. I'll do something like this (as a caller):

'
GameJoltAPI.fetch_time()
yield(GameJoltAPI, "gamejolt_request_complited")
GameJoltAPI.get_response()
'

Then, if you're thinking about some sequential calling you may do something similar to this (in one function! - because of the yield):

'
GameJoltAPI.call_1()
yield(GameJoltAPI, "gamejolt_request_complited")
GameJoltAPI.get_response()
...
GameJoltAPI.call_2()
yield(GameJoltAPI, "gamejolt_request_complited")
GameJoltAPI.get_response()

'

[Endojo]

After some struggeling I did that: #6 (comment)

[rojekabc]

Quite nice work. In some places we're moving in very similar way.
My current state is this one:
https://github.com/rojekabc/-godot-gj-api/tree/feature/refactoring