VB6 -> Godot. Unsure why Local Variables to Functions are not returning their new data

Godot Version

Question

Hi all, bit stuck, my trials and tests are not working either (Google works, but I’m missing someting, perhaps a fundamental fact).

Short story version, coming from VB6 environment and I am having trouble with returning multiple ‘local’ variables in Godot.
In VB, we pass references through by default to a funciton, they are manipulated within, and the references are updated.
For a pseudo code VB example:
Local x,y,z are manipulated in a function, and the result printed.

Start_Program()
Dim x, y, z
x=1: y=2: z=3
Call My_Function(x,y,z)
Print(x,y,z)
End
Exit Function

My_Function(A,B,C)
A=A+1
B=B+2
C=C+3
Exit Function

Result:
2 4 6

In Godot, I can get this to work IF I place the variables at the top of the Node, as expected. But return[A,B,C] doesn’t seem to work for internal, locally made variables.

Is there something I need to be doing/adding to send/return locally made variables in Godot?

Thank you for help!

Most built-in types (int, float, String,…) are passed as values. Only a few (Object, Array, Dictionary,…) are passed as references. More information here GDScript reference — Godot Engine (stable) documentation in English

1 Like

Thank you, looks like I’ll need to use arrays.
Pity Godot doesn’t use immediate references, I think we are spoiled with VB and that. Cheers!

Having worked with it for several years at the start of my career, VB6 is rather an outlier in that behavior. Most other languages are more like GDScript and C# where most of the fundamental types are passed by value. So I wanted to offer:

  • A caveat that relying on “side-effect” behaviors like this - as well as effecting a behavior like this in a language that wants to lean into different sort of behaviors - can lead to some habits that can cause issues later. (If only doing programming on your own as a hobbyist, it’s not a big deal yet)
  • A different approach in lieu of arrays that you can also use that passes by reference and works really well semantically if these multiple parameters are related to each other and passed/manipulated as a group often: objects with named properties. :point_down:

So with objects, you can just make lightweight ones that have named properties for the different parameters:

extends Object
class_name my_parameters

var x
var y
var z

And then when you pass an instance of this to a function…

func _ready(): // just using this as an example of a place to execute it
    var params = my_parameters.new()
    params.x = 5
    params.y = 6
    params.z = 7
    add_and_print_params(params)
    print("after call: x is %s, y is %s, and z is %s" % [params.x, params.y, params.z])

func add_and_print_params(params : my_parameters):
    params.x += 2
    params.y += 4
    params.z += 6
    print("in call: x is %s, y is %s, and z is %s" % [params.x, params.y, params.z])

Output:

in call: x is 7, y is 10, and z is 13
after call: x is 7, y is 10, and z is 13

…by having property names you have clearer semantics (context/meaning upon reading) versus indexing into an array with [0], [1], [2], etc. And the type-hinting in the function argument with : my_parameters can be helpful for property name hinting/autocompletion.

Thanks for that, I’ll examine closely.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.