EVE General Discussion

There's two sides to that for us.

First is that we need to have most of that info stored on the client, so that we're not hitting the DB every time someone opens a showinfo window. In the past that's meant building a new client when we wanted to change a stat on something, which means going through the full deployment routine (not cheap). With the upgrades to bulk data, we can now make a change to a stat, deploy it to the server, and have the server tell every client that connects to download the latest changes. If you see "loading bulk data" when logging in, that's what this is.

The second thing is making sure stuff is actually correct. We don't as a rule change stuff directly on TQ except in the direst emergencies, because people are people and people will on occasion fat-finger their data input. The way we significantly reduce the incidence of this kind of bug on the live server is by having a clear process for deploying stuff - it gets created on the content creation server or in code, it gets ported through Chaos (internal testing) and Singularity (public testing), and then it gets deployed. Sometimes some things take shortcuts, but there's a minimum standard of "ticking boxes" that's in place to try and catch silly bugs before you see them.

The obvious reaction to this is "if you just edit things on the live server, then you can fix them really easily if you mess up so what's the problem?". The two problems are a) you're still getting buggy values on TQ for a while, and if for example I'm messing around and accidentally add a couple of zeroes to the damage multiplier on Mag Stabs, a lot of people are going to die before I fix it, and b) that's just a straight-up dangerous mindset to approach these things with, because it leads to a very lackadaisical mindset when dealing with the live server that can carry across into much more critical systems and consequently bigger mistakes. Most of us in development generally treat the live server with a reverence bordering on outright fear, and that's a good thing because it means we can't do anything really dumb. (I once offlined a player's starbase on TQ by accident while troubleshooting an issue, because I clicked the wrong button. That was a fun day.)

Also in our case, there's the more prosaic issue that our deployment workflow is very unidirectional - data changes can go from creation server to test server to live server, but not the other way around, so changing things directly on the live server introduces its own entire family of horrendous versioning issues that we just don't want to have to deal with.

There's two sides to that for us.
...
Very informative stuff as to motivation and process related toward tinkering with stats .... yet.

Yes, absolutely, I'll ask. I honestly don't know how easy/hard/appropriate/risky/etc. would it be to implement such a process, but I will try to get an answer for you.