Please Review 2.5's "Server Rules" Table

Grinkles

Developer
Staff member
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:
  1. A number of these rules were set not because they were sensible or desired, but because past clients had no options or alternatives.
  2. 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).
Changing server rules can bring about fundamental changes that would give many new conveniences to the player, and in many cases, such changes require nothing more than altering a single value in the database.

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:
  1. Changes to server rules work.
  2. Server rules aren't necessarily "set in stone" as far as the staff are concerned.
  3. Changing one word or one integer value in the rule table can have a large, positive impact on everyone.
Therefore, I'm asking that the staff (e.g. The Big S and/or @Rymy) do a complete review of the server rule table to consider making changes that would make players' lives easier, make the game more enjoyable, and modernize SoD in order to improve its appeal among newcomers.

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.
What are your thoughts on such changes, fellow players? o_O
 

AngryCow

Dalayan Elder
My thoughts on each:
  • HealOnLevel
    • This one is maybe abusable on adepts, but overall probably wouldn't hurt.
  • SoDClientUseSoDHPManaEnd
    • Matching fomelo would be nice, but this one is probably the most likely to cause bugs and weird number calcs IMO
  • RespawnFromHover and RespawnFromHoverTimer
    • This is probably the best on the list, I know many suffer zoning issues and this would re-leave a lot of it.
  • UnmemSpellsOnDeath
    • This s a big help to classes like ENC and BST, as long as it isn't abusable somehow I think this would be really nice.
  • GrantHoTTOnCreate
    • This one might be nice in the interim, ideally though we should hope to get the extra AA systems added into shards in general.
  • TellQueueSize
    • as long as this doesn't cause some sort of server lag, this would be excellent also. looking at you Haenir >_>
  • Find
    • This one I'm against, I've always liked that there is a sense of unknown about shards, that everything isn't found, that every path isn't trodden. I like making people go out and learn about the world on their own in their own way personally. To me it's part of the games charm.
  • AlwaysSendTargetsBuffs
    • This could be an issue if it shows NPC buffs, but beyond that it seems handy.
  • EnableVoiceMacros
    • Cute, but definitely not as life changing as the others. I think most people disable sound anyways though...
  • EnableMailSystem
    • This one feels outmoded. I also like having people log in to say hi, instead of going away for a month and just reading mail in game later.
 

iBluNT

Dalayan Elder
Pretty great suggestions all around. Favorites being the hover on death feature and also unmem spells. Would be great for wizards since they always manage to get rezzed before they load their harvests.
One thing I was curious about was the autofollow feature. On other servers / clients I've used a /stick command which lets you set follow distance, follow angle (always in front of follow target, always behind, etc.).
I wasn't sure if this feature was even functional in our current client, but I know our implemented /follow feature has a variety of quirks to it that really make it frustrating to use sometimes.
 

Grinkles

Developer
Staff member
  • HealOnLevel
    • This one is maybe abusable on adepts, but overall probably wouldn't hurt.
I can't think of any realistic situation in which this could possibly be exploited to any practical effect against Adepts. :confused:

Pretty great suggestions all around. Favorites being the hover on death feature and also unmem spells. Would be great for wizards since they always manage to get rezzed before they load their harvests.
One thing I was curious about was the autofollow feature. On other servers / clients I've used a /stick command which lets you set follow distance, follow angle (always in front of follow target, always behind, etc.).
I wasn't sure if this feature was even functional in our current client, but I know our implemented /follow feature has a variety of quirks to it that really make it frustrating to use sometimes.

Others are welcome to correct me, but I believe /stick at least originated as a MacroQuest 2 command (which would explain its efficiency). Maybe some servers found a way to adapt the MQ2 code to the game client itself, though I've never seen anything like that before. It would be wonderful to have it here.

Regarding autofollow's awfulness, I'm fairly sure that a common culprit is clientside FPS desync between boxes. In other words, if you set EQ to run at 30 FPS when active but minimum FPS in the background (a feature we didn't have in 2.0), one boxed character moves at 30 FPS while the other stutters along at, say, 5 FPS, which I guess leads to all sorts of location packet hiccups that autofollow can't deal with. In the past, I've had luck with setting active and background FPS to identical values for 2boxing in order to improve autofollow, but then you end up completely losing the benefit of being able to run the background box at minimum FPS. It seems you can't have the best of both worlds. :(
 

iBluNT

Dalayan Elder
Makes sense - I always thought it was client side and not just an MQ2 macro. Main place I used it was on EZ Server briefly.
 

Ovisha

Dalayan Adventurer
Even with fps synced for autofollow characters still pretty frequently like to take sharp turns, often off the sides of aqueducts.
 

huey

Dalayan Elder
Even with fps synced for autofollow characters still pretty frequently like to take sharp turns, often off the sides of aqueducts.

This. and it seems like if I strafe at all with the lead char. (say, around a one of the glue-traps, a.k.a. trees), the follower arcs off maybe every time.
 

Ovisha

Dalayan Adventurer
If theres any obstable between the following character and the followed character they don't react to directional changes from the leader I think is part of the problem too
 

Grinkles

Developer
Staff member
Grinkles, let's cuddle.
Never ask a shapeshifter to cuddle. Did you already forget what you woke up to last time you tried that line?!

 

Rymy

Developer
Staff member
The "Server Rules" don't do anything magical behind the scenes. They're just variables used in eqemu code to do things in server code. These are essentially just ways to control added features.
I tested some of them and they are decent feature requests.
UnmemSpellsOnDeath - This can be changed by just commenting out 1 line of code.
SoDClientUseSoDHPManaEnd - This is programatically a sidegrade so I didn't look into this.
TellQueueSize - This looks like a good feature to implement, seems pretty reasonable.
RespawnFromHover - This looks like it would take a bit of work to implement but a good feature too.

Didn't look into the rest really but none of them are "free" features.
 

Grinkles

Developer
Staff member
Thanks for looking at some of these, @Rymy. You're better equipped than I am to judge which ones are viable and which ones aren't. I look forward to seeing a couple of these things come to fruition in the future. :)
 

Ezie3205

Dalayan Elder
First choice would be getting tells or seeing messages I missed while zoning. That alone would be worth it. Personally I would like to float on death. It would be really helpful when taking new recruits to difficult or intricate fights because even if they die they at least get to see how to full fight runs. Third choice might be keeping spells mem'd on death but that is more QoL than anything else.
 

Valorfel

Dalayan Beginner
Bumping this thread, whatever came of these? Tell queue obviously never got added, but I noticed a few other quality of life elements we have now.
 

Grinkles

Developer
Staff member
Unfortunately, Shards of Dalaya's build is far more Frankensteiny than I realized when I wrote this. While some things mentioned here have been achieved in one way or another (e.g., characters get full HP/mana/endurance on level up, the Find feature works, and memmed spells are retained after death), the remaining items in this list would either require an impractical amount of backend maintenance or are effectively incompatible with the current client.

Sorry to disappoint, but I think we can all agree that SoD is still in a much better place now than three years ago! :)
 
Top Bottom