Levels are instances of TServerLevel objects.

Level files are parsed/processed and loaded into memory as TServerLevel objects.

player.level refers to the TServerLevel object the player is currently in.

D: So why is .name added to it?
Does it make a difference for levels?

Well, player.level is an object which represents the level, so player.level.name gets the name attribute of the level object. The name attribute is already a string, so it does not result in the object being coerced (the example I posted above shows why relying on object-to-string coercion is a really bad idea).

Perhaps a good example would be the 'player' object. Within your script you're using player.account, 'player' being an object which can have variables written to and functions invoked on it, '.account' being a string/text value. If you can recognise that it is correct to use player.account instead of just 'player', you should also recognise it as correct to use level.name instead of just 'level'.

So ".level" isn't suppose to be a string for level, or it needs to convert it to a string while if I just add ".level.name" it saves it stress from doing it itself?


My problem is that if I don't use .account it will not work.. for whatever I might be trying to do, yet on level it does.. which is why I don't understand...

It is like some people saying why not keep some scripts GS1 for some parts if those parts still work and don't necessarily need to be fixed. I think that is a good metaphor?

In crude terms, yes. You should not expect that coercing an object to a string actually does what you think, so don't rely on it just because it "sometimes works".

Well, with all that stated, I'll definitely try to remember to correct these and future level.name checks. :]

Thank you both, much appreciated.

Bumping this as I'm also running into this problem clientside.