Mewtwo planning.

[Yawning Angel]

So, assuming that this project continues for 5.x, now is a good time
to get started on planning out how the code base will evolve,
especially since baring minor script additions (and tweaks to the
Souldrinker model), the I don't see much additonal work required for
the 4.x series of WoW releases.

Open questions in no particular order:
* Do we still care about closed form models? We only have one, and
I'm not sure how often it's used.
* What classes/specs will we target? We currently support Druid
(Feral Cat/Bear) and Warrior (Protection).
* Do we stick to Java + Janino for the core? The alternative if I'm
writing it would be C or C++.
* Are there any major new features that require backend side support?
(I was thinking about a better movement model).
* Since maintaining 2 codebases is getting annoying I'm probably
going to unify the Cat/Bear code when I start work on this, but we'll
see.
* Should the reporting format change? More detailed reporting? Graphs?
* Do we want a new UI? (It would be ideal if someone else writes
this, depends on what the core is written in as well).
* Is generating stat values useful at all? (I'm really tempted to
pull this functionality, or hide it for most users somehow.)

Regards,

Yawning

[Alaron]

Was meaning to respond to this, but never got around to it.

Closed Form Models = I assume you're referring to the formulation
model? I'd say deprecate it unless someone really wants to use it.
AFAIK, the principal benefit of the formulation model was speed, but
everyone's rocking decent CPU's now for simulations.

Specs: Ferals and Guardians, obv. Prots aren't too far off bears, so
we'll see if that remains true. Cats may end up looking very similar
to rogues, so that'd be a next target if we really wanted to expand.

Core: Ask someone who actually programs enough to know the difference.
If you do decide to refactor, I'd contribute what little I could.

New features: Probably going to depend on new abilities and talents
and how they actually work. I'd like some support for multidotting
(every few months, I go back and look at the current script to see how
I could bolt that on, and get hopelessly confused.)

Reporting: Definitely could be made more newb-friendly, but I love
having all the information. What's most needed is a good (visual) way
to measure changes between profiles.

New UI: Nah, though some things could be cleaned up (checkboxes -
dropdown boxes, etc). Again, no clue what I'm doing, but follow
directions well and could help finish out a UI build if someone else
started.

Stat Values: Just bury the data in the output, if it becomes important
again, it can be brought back. :)

You're probably set over at TIB, but happy to contribute space/
resources at TFD for anything you might need.

Ala

[Alaron]

Actually, if we're throwing out pie-in-the-sky ideas, how about WoL
integration? Load yourself in, c/p a details page URL from WoL into
Mew, Mew grabs the fight duration, runs the sim, and shows you a comp
of expected vs. actual damage, uptimes, etc. (obviously, only works if
MoP has a tank/spank encounter, or something close to it, that we can
sim well.) It'd be a good way to get people away from raw DPS numbers
and focusing more on optimizing their play.

[tangedyn]

This is my vision for Mew 2

The problem with Mew at the moment is that it is much easier for
people to go to AMR or Rawr instead, and end up getting terrible
advice. Some of them know it, but still go back to them because they
are so much easier to use. My vision for Mew2 is to remove the need
for people to go back to AMR or Rawr, by making Mew more accessible to
everyone.

1. The UI for Mew2 has to be browser based HTML5/CSS/Javascript.
There's no way around this. Anything that requires user to have
another VM such as Silverlight or JRE+plugin preinstalled is out of
the question. Users want to be able to click a link and immediately
see Mew2.

2. We need a reforge/gem/enchant optimizing engine that does not use
an Stat Values or EP evaluator, but an actual performance evaluator
either to closed-form formulation evaluator or to a simulation
evaluator. The other tools are giving terrible advice because of their
reliance of Stat Values and the limitation of that.

3. This means we will need to have the Genetic Optimizer and the
evaluators ported to Javascript. For a start, we should just port the
Formulations to Javascript.

4. The existing Mew core will instead form the accelerator backend of
Mew2 ("Mewcelerator"). This is how the Mewcelerator works:

- Runs as an optional native application on the users machine
- Allows the Mew UI to use the Simulation Engine (which will probably
not be available to the Javascript engine)
- Allows the Mew UI to run the GO (with Formulation backend) through
the Mewcelerator
- Mewcelerator runs an embedded HTML server (i.e. Jetty)
- When the Mew UI Page is loaded it will detect for the Mewcelerator,
then enables the engines available only through the Mewcelerator and
uses the Mewcelerator for GO computations.
- Mew UI uses JSONP (or CORS) to communicate with the Mewcelerator
- Mew UI should be able to send the Evaluator Javascript to the
Mewcelerator which will then compile the Javascript (i.e. using Rhino)
and and run the GO on it

5. While we will concentrate on the specs that we are familiar with,
we should ensure that Mew2 is designed to make it easy for developers
to add support for other classes and specs, i.e. writing their own
Formulation javascripts.

[Arielle]

The one thing that I really wish was much easier to do is gear
swapping on a piece-by-piece basis. That is probably one of the
biggest barriers for use by the "masses" as it were. Other products
(Rawr, AMR) offer the ability to switch slots on the fly without
requiring stat calculations by hand on the part of the user. This
would fall under the "UI Improvements" that Tangedyn mentions above.

The danger of expanding the specs available is lack of maintenance
(the problem AMR and Rawr both have). We obviously aren't going to be
responsbile for maintaining every spec in the game. That's silly.
However if we are going to allow for open additions, people need to be
committed to it and not just a one time thing.

Other than that, Tangedyn pretty much covered everything else I was
thinking about.

[Yellowfive]

Hey all -- this is Yellowfive from Ask Mr. Robot, I'm the main
developer of the WoW stuff over there. I know that many of you
haven't been huge fans of AMR, but I don't think that it really needs
to be that way -- I think that some interesting things could be done
if you all go forward with Mew 2.

As you guys have mentioned, users want "easy". But it's a pain in the
ass to make a nice and easy UI. If you all are interested, I think
that a collaboration with AMR could get the best of both worlds: it
would not be difficult to use AMR as a front-end to Mew 2. The AMR
interface would provide an easy way for players to load characters,
choose items, gems, enchants, reforges, blah blah etc. Then all of
the optimization, item list ranking, etc. could be handled by the Mew
2 engine.

This would save you all the huge chunk of work needed to make a full-
featured UI, and have the added benefit of leveraging some of the more
advanced AMR features like saving profiles to user accounts, etc. And
all of the gear suggestions/optimizations would be driven by your high-
quality theorycraft tool.

This collaboration would eliminate the main complaint that you guys
have with AMR (you don't like how we do optimizations via stat
weights), and it would get rid of the main reason a lot of users don't
use tools like Mew: not easy enough.

Anyway, thought I'd throw it out there as an option if anyone is
interested. Feel free to contact me any time if you want to kick
around some ideas.

[Yawning Angel]

@Everyone who posted ideas: I'll take things into consideration, been
busy with other things recently (World of Lightsabercraft) in
particular so I haven't been devoting many cycles to Mew.

On Wed, Jan 11, 2012 at 5:21 PM, Yellowfive <prc...@gmail.com> wrote:
> [snip]

> Anyway, thought I'd throw it out there as an option if anyone is
> interested.  Feel free to contact me any time if you want to kick
> around some ideas.

While I am not ruling out anything at this point, it is unlikely that
we will introduce large external dependencies on things that we do not
have source code to. With that said, baring any rather unlikely
circumstances (mostly involving astronomical amounts of money and the
development team), Mew will continue to be available under a open
source license (It is possible that we may move to something with a
strong copyleft requirement in the future), and we welcome feature
requests, bug fixes and code contributions from third parties.

Regards,

Yawning

[Yellowfive]

Thanks for the reply Yawning -- been spending quite a bit of time in
SWTOR myself ;)

I definitely would not suggest building a dependency on AMR into Mew,
or a dependency on Mew into AMR. It seems that a better approach
would be to communicate and design both projects such that the
optimization/simulation/formulation engine and the UI are completely
self-contained, and can be slotted in and out with ease via a co-
designed public API. We have a lot of experience in this area that we
would be happy to contribute.

This would allow the projects to develop independently -- any number
of UIs could be created for Mew, if people wished; AMR could be one
such UI. Likewise, any number of optimizers could be developed for
AMR, if people wished; Mew could be one such optimizer. That's a
little simplified... but you get the idea.

Hopefully this follow-up makes it a little clearer -- different
licensing policies would not be an issue with such a design, as each
part would be independent. It would also mitigate risk for all
parties involved by adopting a decoupled approach, while opening up a
lot of opportunity to engage different development groups with
different expertise.