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,

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

On Nov 25 2011, 6:47 pm, Yawning Angel <yawning...@gmail.com> wrote:

On Jan 9, 9:31 pm, Alaron <chase...@gmail.com> wrote:

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

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.

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.

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.