Skript: proposal the local_permanent event variable {*_NAME}

[Anarchick]

Hi,

You know normal permanent variable {NAME} ( or {NAME::*} ) and local variable {_NAME} ( or {_NAME::*} )

I propose a new type of variable which start with {*_ and is a mix of them : A permanent variable which can be only accessed with the current event and not in other events.

Why ? : Cause sometimes you have to make a permanent variable like a counter of a called-event-itteration cause you can't with a local variable BUT this permanent variable can be modified by other events and it's can be a problem if you want to share a script to other people and their use the same name of permanent variable.

Exemple of this new variable type :

on sneak toggle:
    player is sneaking
    add 1 to {count}
    add 1 to {*_count}

on jump: #I know it's not a Skript event ...
    broadcast "%{count}%" #return the number of sneaking of a player
    broadcast "%{*_count}%" #return <none>cause it's an other event

[ShaneBeee]

I see what your idea is here, but what Im curious is... how exactly would this save to the variable file?
If you have two different events both using {*_count} how would the variable file differentiate the two?

[Nicofisi]

IMHO manually prefixing the variable names with the script name is easy enough, but I'm always open to a good discussion :)

[TheBentoBox]

Yeah, I could see why this would be useful for QoL but I agree with Nico that I'm not sure if it's worth the effort when you could just do {%script%::...} for all of the variables. I'd like to see more discussion.

[Anarchick]

This in not a simple {%script%::...} cause it's accessible everywhere when {*_...} can only be modified in his own event , it's also a protected variable system. In java you make some part of youre code Public/Private/Protected cause you don't want someone to break your code ;) (PS: what is QoL ?)

[Pikachu920]

It means quality of life. Wouldn't you still have an issue of dealing with conflicts if the server it was installed on used the same persisting local variable name in another trigger of the same event?

[ShaneBeee]

Not to mention, how would you delete a variable if its only available for the event it was created in?
ex: Lets say you have 3 different events with {*_count} ... how would you delete 1 of the three?

[TheBentoBox]

I agree with Pika's point (it reduces the chance of conflicts but doesn't remove it) but as for @ShaneBeee's point I imagine the idea would be that you could only delete it while within that trigger just like with normal local variables (if you have {_count} in a sneak event you can't delete it in some other random event).

[ShaneBeee]

The problem I would see with that, is what if you wanted to delete your variable on load.... lets say you have a stat variable of some kind that wants to reset every day or every restart etc, how would you delete those outside of the event?
I guess in that case you probably wouldn't want to use that style of variable.
In my opinion, as Nico said, its already easy enough to write variables. Not to mention there are already 3 main styles of variables, normal, local and list, and I find newbies to the community find this very confusing at first .... throwing another in the mix will just screw up newbies even more ;)

[bensku]

I feel like this would add unnecessary complexity to the language. Adding new syntaxes is fine, because you usually know what they do by just reading them. This, on the other hand...

[Anarchick]

So I think that it's an aborted idea. If no one agree we should close this post

[TheBentoBox]

Yeah, I don't think there's enough support for it here. Closing.

[Nicofisi]

@Anarchick do share more of your other ideas later though, if you have any :)