ID:1477773
 
(See the best response by Makeii.)
I have been a bit sick and not gotten much sleep, and I cant place what actually happens when you do something like this.

mob
truck
var
mob/player/driver
mob
player
var
mob/truck/driving
proc
Get_In_Truck(var/mob/truck/t)
src.driving = t
t.driver = src


The truck's driver is now the src, which har a driving var that is the truck, who's driver is now the src, who is driving the truck. Does this repeat infinitly? I also wonder how this would look in a savefile, or if it would save and load right at all.

I have to make references to the truck in the client's directional commands, like for example to see if its able to turn east, or is it hitting a tree. thats why all mob types need a driving var so I can do client procs with src.mob.driving and know stuff like is it a big truck that will crush trees and ride right over them, or is it a little truck that explodes from the impact.

If the player jumps out and some other player sees the truck and jumps in, he should be able to use the truck with no problems. I dont know why I cant get the hang of this right now. I know I have coded way harder things than this. I just cant help wondering what happens though, with the truck and driver refering each other in a var like that.
Best response
It's okay to do this. But you need to be careful how you compute code if you have two objects that are referring each other. It can result in an infinite loop if your code happens to have a proc that calls the other proc, which calls the first proc again. This results in a call stack overflow.

If you are worried about the savefile behaving in a similar manner, define variables with the /tmp identifier. This will force savefiles to ignore the variable when saving.

var/tmp/temp_variable = null
var/tmp/object/temp_object = null
Like Makeii said:

This is called a circular reference. They are totally fine to use, but you need to make some special considerations. If you don't want to save the truck when you save the player, you are definitely going to want to mark it temp.

The most important consideration of circular references, though, is that it breaks automatic garbage collection by creating a bound reference that is dependent on another reference. If both objects aren't referenced by anything but each other, they will never delete themselves, so you want to clean up circular references when they are no longer needed manually.