Is there a way to ignore the non existent variables in a script ? For example having a script with some functions that changes the variables in other scripts, without requiering those variables to be declared ?!?

script functions

class_name fc

static func print_text(text):
	print(text)

static func heathSet(value):
	heath = value;

script player

var heath = 150;

func _ready() -> void:
	fc.heathSet (200);
	pass

i cant really explain it. Something that looks like this ? #include math.h the libraries in visual studio ?

In any programming context you have to know how to move between different scripts, but in Godot what you really have to do is know how to move between nodes. I would advise against just programming your game without setting up nodes as you go.

For a player script, I'd suggest having a set_health function there. For sending data between nodes I hope this video I made can help.

thanks, I think iam aware of something simillar, ive made a hitBox that shares information between the player and the enemy. but setting the script in AutoLoad wouldnt make those variables global ? i would still have to do it for all the scripts. I was just looking for an easy way to copy/paste code, to minimize the confusion...lol The importante thing in the functions script would be the animationPlay function.

The problem here is that there's quite a few ways to help you get what you're after but your game structure makes a difference. I think the simplest way to handle this issue, and issues for anyone with a player character, is by having a reference to the player in a Globals script. This way any enemy doing damage or w/e can get access to the player easily without searching through the tree.

If you can connect the function to a signal that can be even better but again, structure makes a difference. For example, if your enemies are all children of the player in the tree, it might just be easiest for you to get_parent() then call the player functions that way.

@jonSS said: but setting the script in AutoLoad wouldnt make those variables global ? i would still have to do it for all the scripts.

If you have a var player in the globals script, it doesn't mean the other scripts that want to access it also need to be autoloaded. I'm pretty sure my video will clear some things up, ya just gotta get through the first three parts. I was scolded for not covering signals in it which also might help you a bit so there's a link to signal examples in that vid description.

I've read the original question about ten times and I still cannot understand what you're actually trying to do. You want to change the value of variables that don't exist? That doesn't make much sense.

@xyz said: You want to change the value of variables that don't exist? That doesn't make much sense.

Iam trying to short code by not having to create the same functions in player.tscn and enemy.tscn files ( enemy and player variables exist, but they dont share them in my game, execpt when they collide, they share about 3 or 4 vars in( player AreaNode hitBox signal ) )

@Erich_L said: I'm pretty sure my video will clear some things up, ya just gotta get through the first three parts. I was scolded for not covering signals in it which also might help you a bit so there's a link to signal examples in that vid description.

Ive watched it to end, the final part was a bit confusing for me. But the solution i was looking for might required for the script to have a diferent extension (maybe) one that its only readable and not .gd. So it would only detect errors, once the function its set on .gd script.

There is a solution for the script functions to work in other scripts. for example

instead of:

class_name fc

static func heathSet(value):
    health= value;

having:

    class_name fc
    
    static func heathSet(playerVar, value):
        playerVar= value;

.....

    extends KinematicBody
    class_name Player1
    
    var health= 150;
    
    func _ready() -> void:
    	fc.heathSet (health, 200); #-player 200 health
    	pass

but this requires having more vars in the functions, and some functions would be impossibly long. Iam not saying this is a solution...

static func objectMove(objectMoveVar, moveSpeed, objectJumpVar, jumpForce, objectGravityVar, gravityValue, objectAccelarationVar, accelarationValue, objectBulletsVar, bulletsValue, objectMagicVar, magicValue):
#do something...
pass

Umm... if you want to share functionality between script classes without duplicating the code, simply make a base class that handles shared functionality and then inherit from it. Then you can proceed to add specific type of functionality to each inherited class.

So you can have a base class Entity that contains all shared variables and functions that handle health, and then inherit from it for each specific entity like Player or Enemy.

class_name Entity
extends KinematicBody

var health
func set_health(h):
	health=h
class_name Player
extends Entity
#already has health stuff by the magic of class inheritance
class_name Enemy
extends Entity
#already has health stuff by the magic of class inheritance

@xyz said: Umm... if you want to share functionality between script classes without duplicating the code, simply make a base class that handles shared functionality and then inherit from it. Then you can proceed to add specific type of functionality to each inherited class.

So you can have a base class Entity that contains all shared variables and functions that handle health, and then inherit from it for each specific entity like Player or Enemy.

class_name Entity
extends KinematicBody

var health
func set_health(h):
	health=h
class_name Player
extends Entity
#already has health stuff by the magic of class inheritance
class_name Enemy
extends Entity
#already has health stuff by the magic of class inheritance

Ha ok... that is it the 'extends '

but wont that make changing the enemy var health, - also change the player health ?

@jonSS said: Ha ok... that is it the 'extends '

Lol, yes. See how beautiful and powerful it is :D

@jonSS said: but wont that make changing the enemy var health, - also change the player health ?

No. Just the code is shared. Each class instance has its own data, although identically defined and structured. It's exactly what you want. You can easily try it out:

class_name Entity
extends KinematicBody
var health
func set_health(h):
  health=h
class_name Player
extends Entity
func _ready():
	set_health(100)
class_name Enemy
extends Entity
func _ready():
	set_health(200)

@xyz said:

@jonSS said: but wont that make changing the enemy var health, - also change the player health ?

No. Just the code is shared. Each class instance has its own data, although identically defined and structured. It's exactly what you want. You can easily try it out: 

class_name Entity
extends KinematicBody
var health
func set_health(h):
  health=h
class_name Player
extends Entity
func _ready():
	set_health(100)
class_name Enemy
extends Entity
func _ready():
	set_health(200)

thanks, that will make it easier

Note that you can now attach the same enemy.gd (for example) script file to multiple enemies and each will have their own health data. But structure of that data, and code that manipulates it are defined in one place only, namely in the base class. So no code is duplicated whatsoever, be it functions or variable declarations.

This is called class inheritance and it is one of the key features of object oriented programming.

You can also inherit further. The Enemy class can have some variables and functions that are common to all enemies. You can then create classes for specific enemies that inherit from the Enemy class:

class_name Enemy
extends Entity
# already has health stuff

var weapon_type
func set_weapon_type(weapon):
	weapon_type = weapon
class_name StrongEnemy
extends Enemy
#already has health and weapon stuff
class_name Miniboss
extends Enemy
#already has health and weapon stuff

@xyz said: Note that you can now attach the same enemy.gd (for example) script file to multiple enemies and each will have their own health data. But structure of that data, and code that manipulates it are defined in one place only, namely in the base class. So no code is duplicated whatsoever, be it functions or variable declarations.

This is called class inheritance and it is one of the key features of object oriented programming.

You can also inherit further. The Enemy class can have some variables and functions that are common to all enemies. You can then create classes for specific enemies that inherit from the Enemy class:

class_name Enemy
extends Entity
# already has health stuff

var weapon_type
func set_weapon_type(weapon):
	weapon_type = weapon
class_name StrongEnemy
extends Enemy
#already has health and weapon stuff
class_name Miniboss
extends Enemy
#already has health and weapon stuff

Iam aware of inheritances, at least the visual part. The one that has a button called "inherit"...lol parent() child() etc...

But in this case, the question is what is really happening on the background ? Wont godot virtually create new variables in memory ? something like duplicate the parent vars for all the childern and give it a diferent name and address in memory ?

@jonSS said: But in this case, the question is what is really happening on the background ? Wont godot virtually create new variables in memory ? something like duplicate the parent vars for all the childern and give it a diferent name and address in memory ?

Inheritance doesn't deal with actual data but rather with structure of data. Data is created only when you attach a script to a node and run the game. In other words a child class doesn't inherit any data, it only inherits definition of what data it should have. It's exactly what you asked for in the first place, a way to prevent code duplication.

@xyz said: Note that you can now attach the same enemy.gd (for example) script file to multiple enemies and each will have their own health data. But structure of that data, and code that manipulates it are defined in one place only, namely in the base class. So no code is duplicated whatsoever, be it functions or variable declarations.

This is called class inheritance and it is one of the key features of object oriented programming.

You can also inherit further. The Enemy class can have some variables and functions that are common to all enemies. You can then create classes for specific enemies that inherit from the Enemy class:

class_name Enemy
extends Entity
# already has health stuff

var weapon_type
func set_weapon_type(weapon):
	weapon_type = weapon
class_name StrongEnemy
extends Enemy
#already has health and weapon stuff
class_name Miniboss
extends Enemy
#already has health and weapon stuff

Ive just checked and it seems like it doesnt work. The error is between using static func and normal functions

static functions 'cant access member variables' and 'non-static functions can only be called from an instance'

the only way would be to make all the variables static ( constants ) in class_name Entity the functions in class Entity have to be static for the player and enemy script be able to access them.


class_name Entity
    extends KinematicBody
    
    cons var health
    static func set_health(h):
     # health=h

No. You should not use static functions at all for this. Player and Enemy should use all functions and variable defined in Entity as if they're their own. That's the whole point of inheritance. Entity "becomes a part" of Player and of Enemy.

class_name Entity
extends KinematicBody

func test():
	print("I'm an Entity too")
class_name Enemy
extends Entity

func _ready():
	test() # right way to call test
	Entity.test() # wrong way

@xyz said: No. You should not use static functions at all for this. Player and Enemy should use all functions and variable defined in Entity as if they're their own. That's the whole point of inheritance. Entity "becomes a part" of Player and of Enemy.

class_name Entity
extends KinematicBody

func test():
	print("I'm an Entity too")
class name Enemy
extends Entity

func _ready():
	test() # right way to call test
	Entity.test() # wrong way

Great !!! i dont have to use the ( Entity. ) to call the function. its working now

You can think of it this way; when you write extends Entity it behind the scenes automatically gets replaced with content of entity.gd. Almost like #include in C that you mentioned earlier (not quite, but that's for another topic)