player.attr[]

[cbk1994]

Player attributes are extremely useful, but they tend to fill up too fast. It would be awesome if they were extended to work based on strings instead of numbers. For example, you could do something like

PHP Code:

player.attr.health = "server_hpdisplay.gani,90"; 


I don't know the best way to make attr's work on strings instead of numbers, but I think that would be pretty viable. You could also do it similar to PHP, sort of like...

PHP Code:

player.attr["health"] = "server_hpdisplay.gani,90"; 


...but that doesn't really match the rest of GS2.


Regardless of how it's implemented, support for string-based (or even just more) player.attr[] values would be awesome.

[fowlplay4]

You're using 30 attr's wtf?

but I also agree that your extended attributes suggestion would be cool.

[DustyPorViva]

The problem is, as far as I know, is all attr's need to be sent to all players at all times, clientside and serverside. That's apparently a lot of data.

[cbk1994]

Originally Posted by DustyPorViva

The problem is, as far as I know, is all attr's need to be sent to all players at all times, clientside and serverside. That's apparently a lot of data.

Well, for players in the same level, yes, but only when they change. It's really not a lot of data; a player enters a level, say they have 30 attributes with "1234567890", which is probably about average length.

That ends up looking like this (pardon the max word length of the forums):

12345678901234567890123456789012345678901234567890 12345678901234567890123456789012345678901234567890 12345678901234567890123456789012345678901234567890 12345678901234567890123456789012345678901234567890 12345678901234567890123456789012345678901234567890 12345678901234567890123456789012345678901234567890

..which is approximately 300 bytes (0.29296875 kilobytes). Obviously it'd be slightly more, but it's not a whole lot of data at all, especially since it doesn't have to update all the time.

[coreys]

Attribute setting is probably one of the least laggy things you can do on a server that makes heavy use of them, really. I've never gone over 15 or so attributes, however, perhaps you need to combine similar-use attribute ganis together.

I understand why the current attribute functionality hasn't been expanded, however. Once you familiarize yourself with gani scripting you understand that all player attributes are sent for each player (or, at the least, each player that is shown on screen), expanding the current restrictions could cause some latency issues.

[Admins]

Normally attr[] is for things that really need to be shared - so mainly for visual things. I hoped 30 would be enough the last time when it has been increased from 9 to 30

[Crow]

Originally Posted by Stefan

Normally attr[] is for things that really need to be shared - so mainly for visual things. I hoped 30 would be enough the last time when it has been increased from 9 to 30

That was like...v2.2?

[Tigairius]

Originally Posted by Stefan

Normally attr[] is for things that really need to be shared - so mainly for visual things. I hoped 30 would be enough the last time when it has been increased from 9 to 30

I think the biggest problem with them is probably that people have trouble keeping track of which ones are already being used by other scripts on the server, but for the most part, 30 attrs is more than enough.

[cbk1994]

Originally Posted by Tigairius

I think the biggest problem with them is probably that people have trouble keeping track of which ones are already being used by other scripts on the server, but for the most part, 30 attrs is more than enough.

Yeah, this is mainly why I suggested being able to name attributes; on servers like Era and N-Pulse (had the same problem there when I worked there a while back) which have been patched together by dozens of scripts, most of them too lazy to document stuff, it's extremely hard to find unused attributes (though scriptscan helps a great deal).

[ffcmike]

On Classic I scripted a system to apply and retrieve values to and from designated attribute values, where basically a temporary array consisting of the name, attribute number and default value is looped through when the weapon is created where the necessary data is applied to a static var,
I actually happen to use a player.getAttr("health"); function, aswell as player.setAttr("health", amount);, player.loadDefaultAttr("health");, and player.isDefaultAttr(#) etc.
It can also load designated attributes from other players, and is setup serverside too in order to be synced.

Would be excellent if something like this was built-in but it's not necessary.

[coreys]

Or maybe you guys should learn to use enumerators more often. :P