But to say the UO team needs to take into consideration how the program changes they make even effect UOassist is crazy talk! We as players payed tugsoft THEY need to make it work with UO not the other way around!
its bad enough they have two clients to worry about now lets make them have to worry about all the third part programs like automap,cartographer etc
Storm,
They do need to consider what environment the users are using their application in. Everyone at Mythic should be aware that most Classic Client users use UOAssist; everyone at Mythic must know that most users use the Classic Client, as their boss Jeff admitted this in his last interview.
And what they did was completely unnecessary, at two levels.
Firstly...
What are the benefits of the new patching mechanism to Classic Client users? Well... if you havee a lot of patches to install, it is faster than the old process. But you only have a lot of patches to install if you are reinstalling UO from scratch or haven't played for a long time; and until yesterday, the vast majority of us were not reinstalling UO from scratch very often - things have changed, and in the last 24 hours lots of people have had to do that lots of times.
So why was this an urgent priority for the developers? Surely not for the majority of our benefit. It was an administrative benefit for the development team, reducing the diversity of the codebase, just like the Account Management migration was an administrative benefit for EA. And just like Account Migration, it was poorly scoped, poorly designed, poorly implemented and caused a lot of unnecessary problems to a significant proportion of the paying user community.
Secondly...
If you were going to implement this, then it is childsplay to implement it in a way that would have been backwards compatible.
If the developers had bothered to flowchart what the existing processes did, and simply recreated those steps using their new technology, i.e. used the program names UO.exe and UOPatch.exe and Client.exe to do exactly what they did before "functionally" but using the new patcher architecture, they would have broken nothing.
Why change the process flowchart as well as the codebase itself? That's inconsiderate development, and an unnecessary risk.
In the old way; UO.exe called UOPatch.exe and waited for it to complete, then called Client.exe and closed itself.
In the new way, UOPatch.exe has been changed to call UO.exe; UO.exe copies itself to UO.bin and starts UO.bin as a process, which performs the patching process, then when it finishes it starts Client.exe.
There was no need to do that. The functions are clearly isolated; UO.bin is doing the patching and should just have been called UOPatch.exe.
One thing you learn about programmers is they fall into two categories.
One group likes "greenfield" development and does things new ways all the time. These types of programmers are excellent for brand new developments, but are lousy when you put them on maintenance of existing projects; it isn't what they want to do and it isn't what they do well.
The other group likes "brownfield" development and enjoys digging around in ex-employees' old code to find out how it works so their code dovetails into the existing application. They are less leading edge (or bleeding edge judging by how the other group are performing at Mythic) and their results can be less visibly spectacular but generally in the long run they improve more and cause less distress.
In my day job I am yet again picking up the pieces of a group of "greenfield" developers writing a replacement for an existing application and being too arrogant to read the old source code "because it is old technology" to discover all the nuances of what the old application did.
I remember some of the older UO developers discussing digging around in old source code and sounding like they enjoyed it. I hear a lot less of that from this Mythic group. They remind me of a team of "greenfield" developers and I've nothing but bad experiences of that attitude applied to old legacy applications, just as UO is.
We'll see how Bleak chooses to fix the mess that he has caused here. I hope he takes the criticism on board, learns from it and implements something that is at a process-level backwards compatible and at a functional level includes his clever new patcher mechanism. Because what he's done so far is throwing the baby out with the bathwater.