Forgottenserver: Storage values that support strings, ; seperators inside xml files?

[rottylunia]

hello,

why is it no longer possible to for example register multiple ids with ; and - as seperator in files like actions.xml?
u could do for example aid="5000-5100" script="bla.lua" and it would register all aids with these numbers in the past
or aid="1924;4281;4284;4291" script="bla.lua" and it would register all those numbers before (nvm about this, as pointed out you can use fromid and toid now)

and why storage numbers cant be stored as both numbers and letters anymore?
for example it could be nice in some situations
1 example, u have a player command that lets them set their own discription when a player looks at them, this could be saved in storage values before
or another example, when a monster gets killed, it could count +1 on the storagevalue with the same name as the monster, then player can look at this monster and see how many total monsters of it has killed. but in my last example u could for example convert all monsters to some number instead but its more works

and its also good for organizing stuff i think, for example now u have to do something like this to organize;
have all quest storages at maybe 4000->4500
have all npc storages at maybe 5000->5500
or i think most ots just take random numbers and hope its works, but if we could do strings again we could for example do
quest1->quest500
npc1->npc500

im just wondering why these things were dropped, because before it was alot easier to register multiple ids in xml files, and using letters inside storagevalues was a nice way of saving some custom stuffs, i understand u can save through different ways but it was nice to have

[ghost]

<action fromid="x" toid="y" script="xxx.lua" />

[DSpeichert]

Please use proper title next time.

[ranisalt]

and why storage numbers cant be stored as both numbers and letters anymore?

Numbers are more efficient than letters in a lot of aspects. Just use a map from text to number where you need it

local storage = {
    ["storage"] = 12345
}
...
player:setStorageValue(storage["storage"], 1)

[vankk]

In a global server should be better storage on letters than numbers.

[rottylunia]

yes @ranisalt thats kinda what i meant with u can convert monster names to numbers instead, but it wont work with first example, where players use a command to save a string inside a storage

and i dont rly buy that it's deleted for performance, i have made changes in database in my own server to support strings and i dont see anything changing, MAYBE if you have server with hundreds of players it will affect performance a very tiny bit, but here we have also pull requests that will improve performance by a lot more and yet we dont see these things added

[andersonfaaria]

it's stupid to talk about performance when you lose functionality.
It's the same as disabling A* pathfind for monsters for performance.

"ok, now the creatures don't chase you"
"yeah, but tfs is running fine"

[kornholi]

Supporting string keys in player storage is a legitimate feature request. If you want to argue that it's too slow, implement it and show some benchmarks to support your claim.

[ranisalt]

I didn't specify _performance_ efficient, because it is _space_ efficient for memory and database storage, and the performance hit is irrelevant considering everything else that hurts it. There is no loss of functionality since you can map storage names to storage IDs, as I exemplified.

Personally, I am indifferent to that being implemented back. I wasn't here when it was removed and I completely agree that it is a fine feature to have.

That said, one willing to implement that would need to work on these functions and figure out how to handle reserved storage keys.

Alternatively, use std::hash to convert strings to integers in a collision-avoiding way and hope nothing breaks.

Can we move the suggestion to a better structured issue?

[andersonfaaria]

No loss of functionality? Let me ask you something, if I map someone's name in a table through a spell, will I be able to reach this table in creaturescripts?

Also, why they removed global storages from database? Events are way harder to control when you store an environment variable that will simply disappear upon server reset.

[ninjalulz]

@rottylunia @andersonfaaria The functionalities that you are referring to has actually never been a part of the C++ codebase.

@andersonfaaria You will be able to access a table from a creature script if you declare it as global (Simply don't define local before the identifier).

Regarding your concern about _global storages_

• Create a database table
• Load them in onStartup
• Save them in onShutdown

[andersonfaaria]

So, this changed in recent versions of TFS right? In the past each folder had a different environment and even with global tables (literally if you created a global table in lib) each environment would have a different version of the same clean table, which mean no connection between scripts.

About the global storages, I know how to do it and personally I don't need it, but it's easier for everyone that relies on this repository if you guys didn't break the compatibility when changing versions, otherwise we can just throw away those useless compat libs.
Why removing the global storage from db to start? 99% of the events from 0.4 uses this

[ninjalulz]

Well, what you see today is actually based on the 0.2 branch, and not the 0.3/0.4 where these things existed.

[rottylunia]

actually tfs 0.2 had global storages, but its true that 0.2 just used storagevalues as numbers as we do right now

[Kamenuvol]

2 maps of storage: and should be enough. DB can support both in same table.
or
Pass all storage things to Lua.

[DSpeichert]

If you want to request string-based global storage, create a new issue just for that. This issue tries to capture two different things, one of which (why is it no longer possible to for example register multiple ids with ; and - as seperator in files like actions.xml) is already possible and the other one never existed in TFS 1.0. Note that TFS 0.3/0.4 was a completely different source code base. TFS 1.0 matured from 0.2 and has never removed features that didn't exist.