Netname & Colormap?

[Cobalt]

Found a strange thing that must be the engine code taking over, but Im not sure.

Try making a backpacks .netname equal its owners .netname

easy enough through items.qc right?

Next, drop a backpack somehow using a tossbackpack function, or do a suicide that ought to drop a backpack. Have its touch code print the netname, and you should see the correct netname appear. Now, make it so the touch prints the netname as long as its touching world or onground, then after you drop the backpack, exit the game, and find a way to see the printed string...usually best with a ded server. The netname is a null string correct?

Is this because the colormap ties in the strings somehow? I tried not assigning the backpack the owners colormap, still same? Strange.....

[Spike]

stale pointers.
you can change a string either by changing the field, or you can change the string by changing the memory that the field actually refers to.
when it comes to netnames, the .netname field is set when the player first connects, and remains static. if the player changes their name during that time, the buffer that the netname refers to is changed without needing to touch the entities at all. when the player disconnects, that field is either cleared (null string) or left alone, but any other references to that memory location will see it suddenly become empty.

if you want player names to persist for whatever reason, use strzone, track the references yourself, and be sure to free the memory when its no longer needed.

.colormap refers to the player slot. if there is no player currently in that slot, you get some default setting, typically white (colours 0 0), and will pick up the wrong colour if some other player joins later.

the behaviour is the same in both cases, but the two systems are not directly related. both are a result of not bothering to track things for much longer than they are needed.

[Cobalt]

item.netname = strzone (self.netname); ..... did it, thanks.