Cannot build module with a reference to an int

[FlutterTal]

Godot version: 3.1
OS/device version: Windows 10 64bits
Issue description: I need to use a reference to an int for my module, but it apparently doesn't work.
I got this when I typed scons platform=windows bits=64 vsproj=yes

C:\Users\FlutterTal\Desktop\godot-3.1\core/method_bind_ext.gen.inc(2066): error C2039: 'convert' : is not a member of 'PtrToArg<P3>' with [ P3=int & ] C:\Users\FlutterTal\Desktop\godot-3.1\core/method_bind_ext.gen.inc(2066): note: see declaration of 'PtrToArg<P3>' with [ P3=int & ] scons: *** [modules\ggpo\ggpo.windows.tools.64.obj] Error 2 scons: building terminated because of errors.
And I got a bunch of them while it's still the same error.

[aaronfranke]

Have you tried using int64_t? See here.

[FlutterTal]

I already tried with int32_t, and that still doesn't work

[FlutterTal]

If anyone want to see the module so they can be able to help me:
https://github.com/FlutterTal/godot_ggpo

[lawnjelly]

Am just guessing here, but I think the functions that can be bound support a limited set of arguments (the kind of things that work in gdscript), maybe integers by reference are not supported .. see the list aaronfranke posted.

If you want to return an integer, you could return it by value. If you want to return a bunch of integers, you could maybe return an array of integers in a variant?

[FlutterTal]

Well, I tried using an array instead, but it in fact got even worse. And as of the limited set of arguments, I used #include "core/core/method_bind_ext.gen.inc" to fix it.

[bruvzg]

You can use anything on the c++ side, but as soon as it is exposed to gdscript you are pretty limited.

AFAIK by reference or by pointer arguments are not supported by gdscript in any way or form, with exception to some internal classes and Ref<Object>.

Probably you will need to:

• wrap GGPOPtr to the Object class and use Ref<GGPOPtrWrapper>
• use Dictionary or another wrapper class to return multiple values to gdscript.
• use gdscript signals instead of function pointer (pre-defined c-callback functions, emitting signal in the GGPOPtr wrapper)
• use some wrapper for uint64_t* (there is no direct equivalent in gdscript)
• use pool arrays to wrap buffers like unsigned char* buffer

Here'r some mock-ups:

class GGPOSessionWrapper: public Object {
	GDCLASS(GGPOSessionWrapper, Object);

private:
	GGPOSession* ggpoptr = NULL;

public:
	bool begin_game(const char* game) {
		emit_signal("begin_game", String(game));
	}

	/*.......*/

	void _bind_methods() {
		ADD_SIGNAL(MethodInfo("begin_game", PropertyInfo(Variant::STRING, "game")));
		/*.......*/
	}
};

/*......................*/

int GGPO::start_session(Ref<GGPOSessionWrapper> &sessionRef, const String &game, int numPlayers, int localPort) {
	callLogv("start_session - %s %i %i", game.utf8().get_data(), numPlayers, localPort);
	GGPOSessionCallbacks cb;

	cb.advance_frame = &sessionRef->advanceFrame;
	cb.load_game_state = &sessionRef->loadGameState;
	cb.begin_game = &sessionRef->beginGame;
	cb.save_game_state = &sessionRef->saveGameState;
	cb.load_game_state = &sessionRef->loadGameState;
	cb.log_game_state = &sessionRef->logGameState;
	cb.free_buffer = &sessionRef->freeBuffer;
	cb.on_event = &sessionRef->onEvent;

	GGPOSession* ggpo;
	auto result = ggpo_start_session(&ggpo, &cb, game.utf8().get_data(), numPlayers, sizeof(uint64_t), localPort);
	sessionRef->set_ggpoptr(ggpo);
	return result;
}

/*......................*/

Dictionary GGPO::get_network_stats(Ref<GGPOSessionWrapper> &sessionRef, int pHandle) {
	callLogv("get_network_stats - %i", pHandle);
	GGPONetworkStats stats;

	Dictionary d;

	d["result"] = ggpo_get_network_stats(sessionRef->get_ggpoptr(), pHandle, &stats);
	d["sendQueueLen"] = stats.network.send_queue_len;
	d["recvQueueLen"] = stats.network.recv_queue_len;
	d["ping"] = stats.network.ping;
	d["kbpsSent"] = stats.network.kbps_sent;
	d["localFramesBehind"] = stats.timesync.local_frames_behind;
	d["remoteFramesBehind"] = stats.timesync.remote_frames_behind;

	return d;
}

[FlutterTal]

Well, good news and bad news. Bad news is that I still have a bunch of errors on my module. Good news is that those errors is no longer about the engine, but only about the module. I just edited my repo, so you can see what is happening

[akien-mga]

Well, good news and bad news. Bad news is that I still have a bunch of errors on my module. Good news is that those errors is no longer about the engine, but only about the module. I just edited my repo, so you can see what is happening

It seems you got things working as there are recent commits to your module?

As for this issue, what's left is to define whether we want to extend the binding system to support references to pod types or not (I guess not, but I'll ask on IRC).

Most likely what's needed is to document the design limitations of the binding system (possibly in https://docs.godotengine.org/en/stable/development/cpp/object_class.html#registering-an-object).