[Feature/Improvement] change "str _unit" to netId

[blackfisch]

Requested Change

Currently, when units are involved something like str _unit or str player is added to the listbox. Instead, netId _unit should be used instead (object can be retrieved again via objectFromNetId "netId_here" and would be way better than call compile _str everytime

-> this is more just a reminder for myself than anything else so I don't forget :D Will do the PR when #611 and #612 are merged (to not fuck up everything)

[Azeh]

Can do missionNamespace getVariable _str instead of call compile _str.

[blackfisch]

not really. Doesn't even matter, its not intended to use the string representation of an object to store it and compile it back... That's what netId's are for :)

see here -> variable is not set:

[Azeh]

You were talking about listboxes and units.
Something like

private _unit = lbData [idc, lbCurSel idc];
missionNamespace getVariable _unit;

works the same way as

private _unit = lbData [idc, lbCurSel idc];
call compile _unit;

[blackfisch]

The problem is with the contents. Like here most of the time in the framework the data set is something like str _unit -> that cannot be resolved to an object with missionNamespace getVariable (as shown in the screenshot above) but has to be done with call compile _str which is memory intensive and clutters the memory -> netId is the solution to this "problem"

[Azeh]

something like str _unit -> that cannot be resolved to an object with missionNamespace getVariable
It can.

[blackfisch]

I tried it (see screenshot) and it didn't work. You can prove me otherwise of course, just add me some working code for proof

still. netId is the way to go. It is not intended use to str and object to refer to it.

[Azeh]

[blackfisch]

This only works with named units as @DomT602 pointed out on the discord. This does not work with vehicles and such. Thats it :D
Problem is, this "method" is also used in vehicles lists (keychain etc) -> that would not work and cause problems. thats why I say netId :D