The basic concept of NamedVariables has been getting added to make it easier to implement and test for Perks, Now that it appears that the cause of the crash has been fixed and I'm preparing to switch back to Perks, I thought I'd take a few minutes to explain some things here about NameVariables, what they can or will be able to be used for as well as some more complex ideas about them.
* They allow a single interface to test/set values.
* Names are much easier thing for developers to use, and names that make sense could be exposed to players as desired as well.
* New NamedVariables can often be added/defined without needed a server restart (such as reading a .def file that defines it)
* Specific patterns of named variables are used to help organize them and make them understandable to anyone working with them.
* The name of a NamedVariable can be changed as long as all references have been changed. This is to help have the variables make sense, sometimes renaming improves everything. The server could add a way for allowing for renaming in the future.
* When NamedVariables are defined certain properties such as ReadOnly can be set
* Where they are stored is defined when they are created, in general attached to a Player, Guild, Map, Mobs, Spawns or the entire Server (so it defines who it affects, Map for example applies to all players on the map or the map itself)
* The can be set to allow True/False, a number up to 2B, or a Date/Time (such as when your P2P expires)
* Number values can optionally be set to Temporary, so not save with the player so lost when they log out or others lost when the server restarts (or other special cases, like resetting a map to default values).
* Special cases of NamedVariables can access already existing data (such as checking for a Perk and getting the PerkLevel for it).
* If not set or used, always defaults to 0 or false.
* They only use up RAM if they are actually used, some don't even use any extra memory. That means we can define a large number of possible variables with very little overhead
* A known limitation is currently they should only be used for things check on occasion, not every round of combat or every step (need to avoid potential performance issues)
* They will be easily accessible to WebAccess unless the definition for that variable explicitly says access there is blocked
* GuildMenus will be able to adjust ranks for certain specific functions so control of what rank is needed is under the Guilds control (such as what rank is needed to remove an item from GuildStorage)
Where will NamedVariables be usable?
* Of course many places in the server code itself will be able to access or modify them, except they need to avoid high usage areas such as things that happen per round of combat or per step.
* When Conditions are added for .def files, then many .def's will gain the ability to test/set them. This includes Maps, Mobs, Spawns, and Quests just to name a few possible places
* Maps will be able to place limits or requirements based on to allow or prevent actions on a map (Someone must have pressed Button A or you can't used Door B, you must have completed Quest C to enter room D)
* They are the basis of allowing a Quest to track what you have or have not done easily. Once a Quest is finished it can even delete NamedVariables it no longer needs.
* PlayerMenus & NPC's can use permanent or temporary ones to easily track what you have been clicking on the UI. Example, when you use #menu or #guild we can track which one was displayed in a temporary variable and then add a Back button to MessageBoards to go back to there without adding a dedicated value to all players & possible mobs. Remember, they only use up memory if you've used them, mobs won't ever trigger that. Using Temporary means it doesn't even have to save what you were doing.
* Items will be able to set/clear NamedVariables when an item is Worn/Used.Removed to add more features in the future with less coding needed then the current method
What are some other possible uses?
* The Mobs/Spawns type NamedVariables will allow more variations in mob AI like having ones that can be used to Tune how AI think, without using up a lof of space for stuff rarely used. The RarelyUsed is why some ideas haven't been good, this allows working around that.
* Items could use Conditions to decide if you can Wear or Use an item. If coded to check conditions some very complex features can automatically be added, like only usable by male or female Dwarfs and Attack is at least 67 and have completed the DwarvenAxeThrowing Quest without custom coding in the server, just adding more to the items .def file
Why added now?
* Simplifies checking is a Perk is a a player or a Perk of a specific Tier/level is on them easily, without having to constantly add more code as things change
* Allows the Perks .def file to define easily the Preqs & Restrictions/conflicts easily without having to remember numbers
* Preparing for future enhancements to be added after Perks like enhancing Menus, Maps, & laying the foundation for features needed for Quests, Invasions, Instances.
This is just a quick dump just scratching the surface ... I encourage players to bounce around other ideas for what else we can extend the NamedVariables and the future Conditions into!
No replies to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users