Note: This is about server mechanics, not the "rules" found in SoD's EULA!
If you'd rather skim, just stick to the GREEN TEXT below.
All EQ servers run on a table of settings called “server rules” (outlined here and here), which determine the major mechanics of a server. For instance, the MaxLevel rule in SoD presumably has an integer value of 65, capping everyone at that level. The CorpseDecayTimeMS rule in SoD is set to 10800000, causing player corpses to remain after death for 3 hours (10,800,000 milliseconds). And the ItemATKCap rule in SoD is set to 150, as seen on this Fomelo profile.
The majority of these rules are most likely in line with the staff’s vision of the server, but I have two hunches about some of them:
- A number of these rules were set not because they were sensible or desired, but because past clients had no options or alternatives.
- A number of these rules were inherited by sheer accident during the client upgrade (i.e. default settings for new rules that didn’t exist in 2.0).
So, what would a server rule change look like?
Consider the UnmemSpellsOnDeath rule, which evidently is what wipes a character’s spellbar upon death. As far as I can tell, this rule didn’t even exist in the 2.0 client; back then, dying wiped spells no matter what because it was just part of the game design—a "fact of life." More modern clients seem to have an option here though, and changing UnmemSpellsOnDeath from TRUE to FALSE would take some of the hassle out of dying without unbalancing anything (since Death Fatigue prevents casting spells anyway once you respawn after death).
How do we know that changes to the server rule table are possible? Well, according to patch notes from January of last year, someone (I'm thinking @Slaariel) made it so players begin with max Sense Heading skill. And it just so happens that the 2.5 client has access to a rule called SenseHeadingStartValue (which 2.0 didn't have!). The dev in question almost certainly changed the value from 0 to 200 in the rule table, and in the blink of an eye, made everyone's life easier.
The Sense Heading change proves three things:
- Changes to server rules work.
- Server rules aren't necessarily "set in stone" as far as the staff are concerned.
- Changing one word or one integer value in the rule table can have a large, positive impact on everyone.
I don't have any way of knowing exactly what SoD's server rule settings look like, and it's entirely possible that some of these rules could unleash bugs. Regardless, here's a cursory list of some rules that might benefit from being reconsidered by the staff:
- HealOnLevel
- This is FALSE in Shards of Dalaya.
- Setting this to TRUE would add a new element of fun to grinding out levels for lowbies, instantly replenishing their HP and mana upon leveling up. It would have no impact on game balance, as Level 65 players would receive no benefit from this change.
- SoDClientUseSoDHPManaEnd
- I don't know whether this is TRUE or FALSE in Shards of Dalaya.
- This setting supposedly toggles between older HP/mana/endurance formulas and their newer counterparts from the Seeds of Destruction expansion (hence "SoD" in the rule name). It is remotely possible that inverting this rule setting could finally revert players to the original, intended numbers still seen on Fomelo.
- RespawnFromHover and RespawnFromHoverTimer
- The former is FALSE in Shards of Dalaya, leaving the latter inactive regardless of its setting.
- Setting this to TRUE would supposedly enable characters to use the "respawn window" upon death rather than instantly zoning to their bindpoint. This would be a colossal improvement from the player's standpoint, offering a convenient way of waiting out a rez and watching combat unfold after death all while avoiding having to put up with our server's awful load times.
- UnmemSpellsOnDeath
- This is TRUE in Shards of Dalaya.
- Changing this to FALSE would allow players to retain their spellbar upon death, adding a minor convenience to the aftermath of dying. Death Fatigue and respawning with an empty mana bar would still be in effect to keep the death process balanced.
- GrantHoTTOnCreate
- This is FALSE in Shards of Dalaya.
- Changing this would grant all characters the "Health of Target's Target" Leadership AA, which could be a game changer for players by allowing them to keep closer tabs on their tank's HP or (for healers) the enemy's HP.
- TellQueueSize
- I don't know what integer value this is set to in SoD, if anything.
- Tinkering with this setting might enable tell queueing, a feature that even crusty, purist P99 has enjoyed for many years. In the modern gaming world, missing messages just because you're at a loading point is laughable, not to mention inconvenient for the player who has to keep resending the message until it finally goes through.
- Find
- This is FALSE in Shards of Dalaya.
- Changing this to TRUE could make city navigation much easier. However, this likely would require a ton of followup to determine which NPCs are findable, what their descriptions should be (Leather Merchant, Banker, ENC Guildmaster, etc.). Still worth mentioning....
- AlwaysSendTargetsBuffs
- This is FALSE in Shards of Dalaya.
- Changing this to TRUE might finally allow pet classes to see their pets' buffs in the expanded pet window rather than having to rely on /pet report health. It might also allow players to make use of an expanded target window that shows the target's buffs beneath the HP bar (though this might require updating the default UI's target window).
- EnableVoiceMacros
- This is FALSE in Shards of Dalaya.
- Changing this to TRUE would allow players to use Live's modern "sound emotes," meaning you can send the sounds of laughter, a sigh, or a cry for help to any nearby player who has sound on.
- EnableMailSystem
- This is FALSE in Shards of Dalaya.
- Changing this to TRUE would give players access to the in-game mail system, allowing them to send messages to one another even when the recipient is offline. This is perhaps outmoded thanks to Discord, but I could see many players getting use out of it.