Vertical scaling up of VM

Eoin

Well-known member
<dons a Persuasion Fedora and drinks a +5 potion of neck beard growth> M'lady surely it is the database. The Asheron's Call backend completely rewritten in .NET calls out how demanding it is on the database. So all they need to do is upgrade the 5400 rpm drive the DB is on to be spread across multiple SSDs.<tips hat>
 

GrizzlyOso

Well-known member
Without details about how the software was programmed (i.e. architecture, implementation details) or how the backend looks like it’s all just guessing. It's just futile.
Yup ! Not only are all things possible all things are equally likely. We just can’t possibly know anything. It’s just as likely a screw is loose as a pathing problem. It’s just as likely solar radiation as it is a broken fan.

We. Just. Can’t. Know . Anything !
 

LurkingVeteran

Well-known member
There was a valiant effort recently by one of the original DDO devs that returned, but it didn't really make a lasting impact. I suspect the problem is that the underlying scripting engine that runs DDO Script (or whatever they call their internal scripting language) is so old and arcane that they do not really have any good tools for profiling where the bottlenecks are (the scripts, the engine itself, the network/database?). Hence we end up with educated guesses and fixes that, while they certainly improve things on some metrics, fail to resolve whatever is the major cause of lag in DDO.

If I were to guess, the fact that putting points in the reaper tree GUIs somehow caused noticable freezes/lag tells me that something may be seriously strange with their scripting engine. Even if they did not previously cache the accumulated bonuses (I think they do now), just adding up a few numbers each time shouldn't normally take a noticeable amount of CPU cycles. The DDO scripting engine seems to run about as quickly as the ones on old Texas instruments calculators from 1990, and I'm barely even joking about this. I realize it's much more complex, but in pure lines of code per second it seems orders of magnitude slower than expected. I'm not saying it has an easy fix though.

I also think all their outdoor zones + increased movement speed (horses) is really challening for the poor aggro mechanics. Maybe if they didn't make monsters just mechanically chase everyone like brainless organisms, at least the AI/pathing part wouldn't be an issue.
 
Last edited:

Br4d

Well-known member
Snapshotting should probably help performance? constant recomputation seems bad

I was referring to the player's tendency to exploit the snapshotting as much as possible with gear swaps and other interventions changing numbers on the fly during the rotation. I know I get laggier solo when I am doing that kind of stuff solo. I'm guessing the effect is much worse in a full 6.
 

Kessaran

Well-known member
I want to point out that according to enad7 (the parent company that owns Daybreak, which owns SSG) stated that at the end of 2023 SSG only had 60 employees. Assuming higher-end rates of pay they barely pay out around ~8m a year for SSG employees, out of the 54m that SSG brought in. The fact they claim that anything correlating to player retention/satisfaction is fiscally irresponsible is horse **** and they know it. At some point the people at SSG need to start worrying about how to bring in more money, and not working towards player retention/satisfaction is the exact opposite of that.
 

I dont Like gimps

Well-known member
I was referring to the player's tendency to exploit the snapshotting as much as possible with gear swaps and other interventions changing numbers on the fly during the rotation. I know I get laggier solo when I am doing that kind of stuff solo. I'm guessing the effect is much worse in a full 6.
trust me People are doing way worse things than Snapshotting that causes lags
In fact some people intentionally create lag to create other stuff that causes even moar lag
 

Bjond

Well-known member
After 18 years snapshotting is a feature -- not an "exploit" -- regardless how vehemently you disagree with it.
The biggest "bug" in DDO is the lack of reliable documentation. If they would just put a pin in it and nail it down a little, maybe we wouldn't have to spend so much time testing how the game *really* works in order to maximize a build; ie. it would be nice if they stated snapping was OK and intended or not -- because some things snap and some don't and some they changed to not snap and .. it's confusing!

Most games are far FAR simpler than DDO when it comes to builds. DDO is nuttier than a squirrel full of barrels.

SSG's other problem is their dislike for emergent play. They'll make some changes, players will adapt, then they'll gasp "omg, they figured out how to leverage the rules!" and change them. Old EQ1 had some really nasty GM/dev behavior, but one thing they did that I admired was coming out and saying "We do not like the way y'all are using this skill (FD); it was not intended or desired, but it's become part of the game and we want the player base to be able to reap the rewards of their own creativity. So, we're leaving it in."

I've pretty much stopped posting builds to avoid drawing a nerf. My builds are hardly OP, but they are different and I like them and don't want to rebuild.
 

Fanaval

Member
So many odd assumptions being made here on how to fix things. Some stuff that's been pointed out over the years:
The servers are still 32-bit and they will be swapped to 64-bit at some point (I believe LOTRO going to 64 bit servers first is the plan still- https://massivelyop.com/2023/12/21/...h-more-umbar-zones-and-new-legendary-servers/ ).

The game was written at a time when CPUs were increasing in speeds at a very fast rate but we weren't rapidly increasing in cores (2 or 4 cores were around, but nothing like the core game we've got these days). So it's quite likely the code wasn't written to scale up and utilize the direction server hardware went in. You can't throw certain resources at code if the code isn't multithreaded in a way to use it. We as players don't know, but it's not a very difficulty to imagine the age of the code limits choices for SSG on the hardware front.
This is key info. Thanks. I checked and 32 bit can support 4 GB RAM for each segment. So we have to hope for an update of the servers to 64 bit. Like LOTRO.
 

LurkingVeteran

Well-known member
This is key info. Thanks. I checked and 32 bit can support 4 GB RAM for each segment. So we have to hope for an update of the servers to 64 bit. Like LOTRO.
I don't see it written anywhere that 64bit servers would improve performance. Most likely this just to stay up to date and potentially support larger maps. You typically make sure your game resources fit in server memory. Even back then, server architectures were threaded or forked to support many concurrent users, so I do not think that is the problem either.
 

Br4d

Well-known member
After 18 years snapshotting is a feature -- not an "exploit" -- regardless how vehemently you disagree with it.

The feature is disorienting to the game play experience in several ways.

1. It creates numbers that are not real from the intended output.

The devs must shake in their boots every time a 7 digit result emerges from the complex layers they've set up to produce 5 figure damage at the outside.

This has a cascading effect on the game play, particularly for the people who find the break because most of their time will then be spent on similar pathways to find more.

What is the exemplar such ability in the game right now? Chains.

2. It creates lag as the numbers jigger and re-jigger on every swap before being snapshotted into the total.

If I can see this solo then it has to be much worse in groups.

3. The cottage industry in ridiculous results takes a fairly straight-forward process directly into the absurd, creating a vested player interest in the process which largely invalidates whatever meta is in play.
 
Top