I put up a github project for WarKit although it still needs a ton of documentation, a release jar, and the WarExport database file (which is not open source.) I also need to make some runnable examples to show how useful it actually is -- little code snippets don't really do it justice. And I probably need to fix the classpath so it doesn't collide with other packages (I'm don't typically share my code so this is kind of a learning experience.)

Apparatus is able to import all of the simc profiles from the WoD branch successfully. It can even coerce the invalid bonus ids to proper ids. The only itemization component missing from WarKit at the moment are the new WoD random suffix items (http://wod.wowhead.com/item=116182&bonus=525) but more and more people are crafting stuff on Beta so I should have it figured out soon. Spells are still being an asshole but I'm making progress. I currently focused on gear-based spells so I can make trinket implementations a breeze.

I'm going to be working on "Catus Lite" this weekend, basically making yet-another Feral simulator from scratch using WarKit and my existing knowledge from Catus1 and Catus2old and Catus2new experiments. I'll put this up on github too. I also plan on making a post with my thoughts about simulator design and other things I learned while iterating on Catus. The goal is to get something working in a few days and then compare with Simc. This project won't have any interface or user-friendly config. It will be very similar to my first Catus stuff: http://fluiddruid.net/forum/viewtopic.php?f=3&t=911 (Oct 23, 2012!) dat interface

Got multi-document interface working in Apparatus:

I debugged the Windows version tonight. I added a compact player bar, which greatly reduces the amount of interface junk required to customize your stuff:

CatusLite is almost ready to produce some results. I'll probably have some sim data and a github project available this weekend but I'm pretty shitty with keeping any deadlines.

To speed up CatusLite development, I abandoned my original desire of basing it directly on the spell data (like simc.) Instead, I've resorted to adding a module to WarExport that extracts all of the necessary Feral related coefficients and hides all of the spell cruft.

I moved WarKit over to the new WoW API: http://dev.battle.net. Not much interesting yet beyond being able to request more account information securely. WarBase and WarKit are coming along well, but I still haven't released the database file so it's relatively unusable.

I added in-game stats to Apparatus (only a few showing so far). It works for any class/spec/level.
I got WarKit to support all of the strange items like this dude: http://www.wowhead.com/item=116522
(you get a choice between Agility or Strength and a random suffix)
There's also items like this: http://us.battle.net/wow/en/item/106720 which have like 200+ different suffixes.

Overall, I think I made a mistake trying to be "truer" to the underlying game data. I think the original Catus approach was actually better: implementing everything myself and then making sure its functionally equivalent in-game. I thought that having a good grasp of the spell data would make it so I could implement other specs w/o much effort. Instead, I'm wasting time dealing with crap that isn't even related to theorycrafting.

Assuming I can keep the CatusLite codebase lean (original Catus was 50K+ LOC, CatusLite is only 5K so-far but no GUI), I feel the best approach for the grandiose Catus2 that I originally envisioned, revolves around making it so spec-specific simulators are quick to develop.

Apparatus 1.0 is pretty much done feature-wise but there's still a bunch of UI polish to go. I'm currently working on the stat weights stuff and playing with the dynamic Catus integration. For example, if you have both Apparatus and Catus open, you can use Catus for simulation settings and Apparatus for gear selection and get live simulator feedback inside Apparatus.

I'm trying to release Apparatus ASAP because it is useful for all classes, not just Feral. I don't think there is any other gear configuration tool that lets you explore what options are available for your gear. Wowhead probably has the best tool, and for the life of me, I can't figure it out. Just setting up a simple gear set takes forever. Whereas Apparatus works great as a Simc front-end. And it works great as a gear audit tool. And I've started adding some integration stuff like from a character name "Edgy", you can go directly to my Warcraft logs page in one-click.

I was shooting for a Catus release last weekend but that failed miserably. WarKit has been consuming most of my free time lately, but is coming along really nicely.

Java 8 has a new JS runtime called Nashorn and I've been experimenting with it as the foundation for the Catus APL.

The obvious benefit would be: I don't have to implement a parser and the script writer would have full access to the Javascript language.

The WoD APL is much much simpler than the MoP APL. So much simpler that I'm tempted to just abandon the priority list idea and try something different. I fantasized a bit about this during early Catus 1 development: http://fluiddruid.net/forum/viewtopic.p ... =25#p11297

Even without doing something crazy, porting the Simc APL to JS would be relatively easy: each action/spell would become a function, conditionals would just be functions, different action lists could just be direct function calls, etc.
/rake,if=blah ==> Rake.if(function() { return blah; })

Crazier things might be trying to do an evented approach, where the simulator calls into Javascript with different updates, and the JS tries to figure out what to do. This would be similar to writing an in-game Lua addon.

An even less structured idea would be just calling into JS with "nextAbility()" and have JS have full reign at deciding what ability to use. Instead of returning a single ability directly from that function, spells could get scheduled together, like: Schedule(Rake); Schedule(Shred); or whatever. If the script also responded to events, this feedback could invalidate the current schedule, and reschedule something else.

Another advantage of using JS is that the script can easily contain state information. Storing global information, or even information per target, is as simple as creating var x = 1. Additionally, a script can easy query any value from the simulator w/o me implementing anything beyond tagging the variable as public. Overall, the Java<>JS bridge is pretty awesome but I'm not sure how best to utilize it.

Edit: Originally, the Catus APL was written directly in Java, not as a priority list, but a long chain of if-statements and state information. This structure made the simulator significantly faster because I could avoid recalculating code that is shared between different conditionals (8min fight @ 100K iteration in less than a minute.) These same optimizations could be applied to the latest APL, but I never got around to it. For example, calculating expected Rake damage might be called like 40+ times per evaluation and the look-ahead logic (which walked forward in time, pretended your buffs faded, and then computed more Rake damages) made this even worse.

---------------

Edit: I am unstickying this thread. I will restore it and update it to 6.0 when I have some stuff to share!

I got pretty burned out trying to get everything ready before 6.0. Rewriting everything was a mistake as well as trying to support more specs. Additionally, the existing Catus application has a lot of polish, making all my intermediate work feel like crap in comparison.

The simulator is the easy part, it's the interface that takes forever. Catus 1 was making pair-wise trinket charts in February (via code) but the trinket simulator interface wasn't added until October.

I still intend on releasing Apparatus and Catus, I just don't know when. Maybe around Xmas or something.

So one of the big projects I would like to implement for Warcraft Logs is the ability to view all logs in your native language. For example, a Russian user should be able to just view logs that were originally recorded in English as Russian instead. This paves the way for localization of the entire Warcraft Logs Web site.

In order to do this, I need to be able to build/maintain a database of all ability names, all NPC names, and the names of all encounters (i.e., the names you see in ENCOUNTER_START and ENCOUNTER_END events).

I am curious if you have this code available on github and/or could point me at information about the format of the files. Since Warcraft Logs also uses Java, I would love to just fold in existing code if you have it. If this is something WarKit or some other component can do, I could use it in my back end directly.

I can learn a lot from just code inspection, so if you have that code available and could just let me know where on github it is, I could just study it myself.