Fixes #85, where "numeric_properties" were being discarded if using integers. Like I wrote there:
Normally, in GDScript, ints are silently cast to floats when assigning to a float variable, so it should probably just convert from an int to a float in this case too.
This implements that, converting from ints to floats when a dictionary takes floating-point values.
Also, when I was updating test_suite/tests/socket_multi_test.gd to confirm this fix, I noticed that when deserializing "numeric_properties" coming back from Nakama, the values were left as strings! So, this also updates deserialize() to convert dictionary values to floats if they are marked as floats in the schema - it was already doing this for ints and bools.
And since deserialize() was converting values back to bools and ints, I figured it probably made sense for serialize() to convert to them too, given that (1) it's doing the same in other places and (2) GDScript also silently converts to int and bool on assignment, which is the same justification that I gave for converting to floats above.
Fixes #85, where "numeric_properties" were being discarded if using integers. Like I wrote there:
This implements that, converting from ints to floats when a dictionary takes floating-point values.
Also, when I was updating
test_suite/tests/socket_multi_test.gd
to confirm this fix, I noticed that when deserializing "numeric_properties" coming back from Nakama, the values were left as strings! So, this also updatesdeserialize()
to convert dictionary values to floats if they are marked as floats in the schema - it was already doing this for ints and bools.And since
deserialize()
was converting values back to bools and ints, I figured it probably made sense forserialize()
to convert to them too, given that (1) it's doing the same in other places and (2) GDScript also silently converts to int and bool on assignment, which is the same justification that I gave for converting to floats above.This should improve type consistency overall.