Why not use the community rather than breaking things?

Good post. It's weird that a post like this is after the fact. Like these coding changes to the body types is some sort of magical secret. I understand the concept of under promise and over deliver. I understand that talking about something and then not doing it causes problems.

But what also causes problems is their being problems and waiting for an uproar to address it.

EQ needs a video channel to go with the patches. The videos need to be recorded after test and posted before or with the patch. It needs to be, simply put, your post I just quoted. You don't need to include actual code or proprietary data, but you can white board code examples of how complexed the coding and the databases are.

You don't need to reveal all the secrets and the long game, but having a developer speak like you posted here can go a long way. Simply and humbly explaining that what seems like a minor change is a massive back end coding update to correct 20 year old shortsightedness with a game plan for a long term investment is problem enough.

People will understand that you break a mob when you change how 20,000 models are handled by the engine. Just tell them. They will still be frustrated that a mob is wreaking havoc, but at least they will understand the complexity of the problem and be hopeful that the problem is worth their hassle.

Still though, on the specializations, that shouldn't have been implemented until there was an easy way for players to correct it. Even if each character takes us only 10 minutes to correct, we all have numerous characters affected, and there will likely be hundreds if not thousands of player hours impacted by it. I'd be curious to hear if there is some sort of explanation for such a decision or that was just an acceptable design decision.

This sounds like a lot of work and something that would take time away from them fixing anything that breaks with the patch and doing other needed work.

Is it though? I mean, Niente just did it. All I suggested was to be proactive instead of reactive.

Read an excellent book on software development, many years ago. Many studies have been done, all prove the same.

Mistakes are much more costly than being correct. Don't work fast, don't work hard, work smart.

If your code change takes an hour to write, you better have spent an hour in your office thinking about what any possible downsides or side-effects of your actions will have before you write a single character of code. Then spent two hours alpha testing after coding before you release to a user-group that has diverse enough use-cases to beta test (test server is the closest they have to that).

It is. It's a lot of work. A TON. The videos you suggest are a whole lot more work. Making video lessons for noobs is a full time professional pursuit for some hundreds of producers at Khan Academy, CuriosityStream, SkillShare, et al.

Thanks for the chuckle, this thread needed a bit of lightening up.

Rolls right off the tongue, easy to remember.

I would argue that it does take a decent amount of work to break down what is changing into something that can be publicly released and understandable by most people and that takes away time from them working on and fixing issues related to the patch.

Was there a reason to change the fundamental functions of Pickpocket? Telling everyone in the area that the rogue stole coin or the exact item that was stolen is massively against how the skill has worked for 2 decades. There was already a notification if you critically failed which was the risk/reward for a little cash in a group. Now it's moved using the skill to completely useless if anyone is around outside of the few required events/quests. Why would someone nearby know that a master thief stole something from a mob?

The change to not stealing equipable gear is also annoying. It used to be nice to occasionally steal a fine steel 2hander that the mob wasn't using for whatever reason. With this change why was there also the need to make all rares and raid bosses unpickable? The occasional item that could be stolen that wasn't equipable but was tradeable? It seems like the notification of what the rogue stole would act as the social dissuasion that appears to be the function of the change.

At the very least the notification message should go away.

Waiting a full month to fix the problems from this patch seems like a VERY bad idea. Bring the servers down as soon as fixes are made and patch them in. Lot of very irritated players at the moment.

Broadcasting to the whole world "Hey! The thief is stealing something!" DOES sort of break the whole immersive, role-playing experience, doesn't it?

It's forums like this that make me happy that in my job we don't have a forum for our end users to use. I'd probably stopped being a programmer a long time ago if they were able to abuse me for everything I do lol.

Keep your head up, and know that us programmers out here know where you're coming from, and we understand the frustration. I know there have been situations in the past where I put my heart and soul in to fixing something with long nights and weekends working in an office where most times it was just me there, and then when the feature was released to our customer base, not a peep of "way to go!" or anything. Just a "hmmm why does this look different" or something else.

The thing is, those people you work with, you co-workers, boss, and their boss knows what you do and the effort you put in to your work. They appreciate you, and believe it or not, the non-vocal majority of your customer base appreciates what yall do as well.

Your information is greatly appreciate Niente. I think Zleski hit this on the head. For such a huge change impacting effectively your entire NPC DB over 23+years of stuff, a week bake time isn't enough. Especially given the multitude of bugs related to it that WERE reported and WERE fixed. To me that would be enough reason to say "Hey - let's roll out the working stuff from test but hold back this change while we keep tweaking it".

Not all functions can be completely tested in a week. Changes which overhaul an entire system I think fall into that category. If the devs break. brick, crash, whatever the test servers daily in an effort to improve live, I say great! Just wait to deploy live until at least a majority of the bugs are gone.

I get once you load code from a "clean" test environment into production weird things can happen you may never see in a "clean" env, but those should be the exceptions IMO.

Next time make sure your linq query pulls from the right database. “Select * from nonbuggy_db” instead of “Select * from buggy_db” /s

Thank you for all of your hardwork Niente. It is like you are painstakingly restoring a piece of art.

Don't get me wrong, I didn't trash you or the other devs. I don't expect perfection. I'm just making the simple suggestion that in order to better use your limited time, you:

1) Crowdsource feedback and ideas about ramifications ("We are going to do X because of Y. What are your thoughts on this and what balance or mechanical problems do you foresee?")

2) The time to read through the inevitable posting of things you already know, through sniping or other garbage, would be minor compared to time saved for every facet of a situation you didn't think of

3) So this lets you approach the problem with more focus and fewer side effects, meaning less time spent fixing things later

Its a resource management issue. While I'm not saying the people here are a million monkeys bashing randomly at a keyboard in the pursuit of Shakespeare, many of the players that know this game *very* well, in some cases better than the devs, and without the insight into the code and back end that you guys have, and might just give you some information that would be beneficial.

A good example was the pick changes made a few months ago. Anyone that has played in PoP knew exactly the problem that was going to occur. If you had posted, "Hey, we're trying to fix the issue with picks you have been complaining about, this is what we plan to do, give us some feedback so we can tweak it" you could have had people point those issues out, and the basic issues about picking into different zones as your group/raid mates, LDs, death and rez, specific events, etc. And patched in the fix without any of those problems, and not wasted your time and aggravated players in the process.

A little more planning and checking with the masses and a little less dictating solutions from the ivory tower.

Id say pickpocketing mid fight without anyone noticing is worse so far as role playing experience goes.

Snipped down to the relevant. As a developer that has had to work on many 20+ year old legacy systems, both in the past and presently, I totally understand what you're dealing with when it comes to EQ's design and code. I commend the willingness and effort of the team to try to modernize the platform and I would never expect every release to be bug free.

Has the team been given the opportunity to start implementing automated testing practices? I've found that it's been immensely helpful when stakeholders understand the long-term value with the upfront cost of investing the time in proper automated testing.

What is careless is that EQ patches go from Test to Live like clockwork, not matter how severe the known problems are with a patch.

Who can just say "No" this patch is not going live? That person is failing or does not exist. That process has been failing for years.

Their concept of the purpose of the "Test" server is totally different than what we think it is. A normal software developer will ask, "Will it compile?". That's essentially how they use Test; Proof it will run, not necessarily proof it's correct.