Post: #1

Some may use it... works for basic 8x8 spells from sb. For custom spells you would have to store gump_id and spell_id. I think its too much information in a tag.:-/

I'll love you for reporting some bugs :-)

Use .spellbar or later .spellbar_setup to set it up.

Post: #2

You know that there is save desktop options in client. This script seems awesome but think about many players if they start using this. It might become massy to server and affets the save time indeed. In theory let say, this is really cool however in practice , i would say this is not good

Post: #3

Family shards might use it... I didn't want to set direct size of spells because some players have smaller icons (I do .. 20x20), using flags/bitmask combination for storing spellid's would save space too but again, players couldn't choose order of the spells.

How did you think the "save desktop"? The dumb system, that all icons are moveable and hardly organized?

Btw. an idea came to mind..in spelldefinion would be good semething like icon="gump id". That would be useful for custom spells/spellbooks.

E: I'll think of a better optimization - but I'm not sure whether it is possible.

Post: #4

I don't think this would impact the server performance in any way
Take the time that Sphere would use to write a 1kb string to the disk then multiply it by 1000 players, maybe 0.1 or 0.2 second increase in the save time? RunUO does not have anything similar like tags, so each item type has its own "binary save format" and every custom item may also be saved in its "own format" and there is no performance issue that can be related to the save diversity
Gumps also does not impact on the network performance, Vorspire from RUO developed a system called Super Gumps that updates itself about 10 to 20 times itself on the client screen with no performance issues (A gump progress bar that is updated really fast to show the spell cast time can be used as example)
I don't know how sphere deal with gumps, but since this spell bar does not need a fast update, there would be no performance issues related to it
Optimization is always welcome, but you will be fighting for performance against memory/disk usage

I would not fear using this system in a live server, unless I had a very limited hardware; I would just test it before it goes live, like anything else

Post: #5

Can you fix image's link please?

Post: #6

Thank You

Post: #7

fix image pls

Post: #8

thank you bro

Post: #9

Thank you brom

Post: #10

thank you bro