misa

I'm still having the same problem, it's been months and I can't get the marketplace to open. I've sat with my switch open for about two hours just letting it refresh, closing out the game, uninstalling it, nothing seems to work. It doesn't work for me on pocket edition either, and my internet isn't the problem

@Torabi There are always hazards, but in this case, the benifits outweigh the hazards. Grum has already stated in no uncertain terms that they will never look at MCPatcher for inspiration. I'd say that safely precludes them coming back to it to compare their work to it after the fact. It also displayed his ignorance on the subject as Mojang has in fact successfully looked to MCPatcher for inspiration in the past (Before he was even a part of Mojang).

Them taking time to work on their own solution without influence (ultimately leading to the better chance of reaching the best solution) would still require adoption of the premise that Mojang is competent enough to do so. I personally don't have that much faith in them. Though to be fair, I also don't think they're completely impressionable or incompetent that they'd fail to benefit from even looking at MCPatcher. I do think it can be pretty easily demonstrated through simple observation of their recent actions on texture packs and the rendering engine, that their implementations of existing features in MCPatcher are woefully inadequate (in the areas of optimization, performance, user-friendliness, and versatility) by comparison. However it can't be blamed on any one person—and therein lies some of the problem. They lack a proper division of labor structure that the vast majority of successful development teams adopt. All of them seem to come from a similar background in programming and are doing too many jobs at once that aren't normally best-suited to programmers (Notch was sort of a rare exception and even he had some problems). Their lack of a more specialized organization has led to many seemingly-forgotten, half-implemented features; a steady decrease in game performance; and a decrease the implementation of accessible content over time.

By contrast, MCPatcher's developers have been dedicated to specializing in solving a single issue for longer than the current Mojang team has even been employed. It works with and around the development of the main design team—improving upon some of their faults while avoiding encroaching too much into territory beyond the scope of its intended design. It has had multiple authors and expert consultants responsible for its development. It has also undergone many format revisions and re-writes to adapt to major changes in the game which have always ultimately optimized its own performance, user-friendliness, and versatility.

Now, I'm not arguing that MCPatcher should be accepted or implemented without any thought or analysis. I'm simply arguing that based on its merits, it shouldn't be outright rejected and ignored without any valid justification as Grum has done. Even if they had taken a practical approach with MCPatcher, I would not see it as a concession to history so much as consultation of those who (at this point) have demonstrated the greater likelihood of currently being the genuine experts on the subject. By closing the doors without much thought or justification they are insulating their development process and decreasing the chances of a good self-correcting system of development.

@Torabi Anything has a chance to be harmful if handled incorrectly. However, it'd be counter-productive to take an approach that is less likely to produce positive results. Limiting one's exposure to other options and viewpoints often does more harm than good. Major advances are rarely non-derivative from pre-existing sets of work. (Science, anyone?) They may still be a completely different approach in the end, but the pre-existing bodies of work may also show them what's been tried with positive results and may give them ideas for what approaches to and not to pursue when coming up with a new and better solution.

Sure you can get lucky by keeping your line of work in a bubble and ignoring all external viewpoints, but a 'bigger-picture' approach with inductive reasoning shows that it's not probable enough to be a practical approach. Pragmatically-speaking you should adopt what works best and be open to immediately dropping it once a better solution is found. Saying you should avoid working-approaches because it might taint how you approach an issue can easily imply that the developer is too impressionable and close-minded to think outside of the box and/or is incapable of learning from the success and mistakes of others. (Or to be fair, against all odds, they're some kind of übermensch. 😛)

The grammar you used leads me to believe that you're fully aware that this is a probabilistic argument. I also applaud you for honestly avoiding absolutes (So rare in arguments on Internet communities. 🙂). I just believe that for the sake of the most ideal solution, you may be arguing for the side with a lower chance of success.

@Grum Why on Earth not? It's been the standard for the formatting of high resolution texture packs since long before Minecraft even had basic support for low resolution texture packs. By ignoring it completely, you're only really doing a great disservice to the countless texture pack artists who have poured (literally) years of effort into their texture packs.

Also if I'm not mistaken, Mojang appropriated MrMessiah's Better Light mod (SSAO/Smooth Lighting) over two years ago because of the exposure it gained through MCPatcher's distribution. I've been a part of this community since before the concept of a texture pack even existed, and had it not been for MCPatcher, they likely wouldn't have reached the categorical status they currently have. To ignore the impact MCPatcher's had on the community and early development of the game is to embrace or profess ignorance of the subject.