Project direction

[Farof]

The initial commit was an almost straightforward port of the original library and departed a bit from it now.

Should the main heroprotocol.js stay as close as possible to the python original in terms of usage and functionalities or expand on it? The parsing part should certainly by made as fast as possible, so that means trimming and optimization on what I currently did.

The current replay.js abstraction is not documented and more a proof of concept and way to keep track of what useful data is known as opposed to the full obscure reference at this point. Though I think it would be great to have people working on their own abstraction and API to access information, I believe there is a place for one in this project, for the moment and until/if a popular one emerges at least.

Any ideas on what a nice and practical abstraction could look like?

Still in the spirit that here is as good a place as any until something better emerges, I think this project needs tools. I already made a bulk replay extraction one. I'd like to make ones that extract all possible values for a particular property (think internal name for mounts, skins, talents, etc…), an automated reference builder and probably a query tool.

See #4 for discussion on the reference.

Or maybe I should immediately make something like "stormreplay", "stormreplay-docs" and "stormreplay-tools" separate projects and link them here? Wouldn't it fragment contribution too much? Maybe not just now but later if the project picks up?

I would like to add code quality and unit testing but I have no real experience with it so any experienced contribution welcomed.

Did I miss anything in this discussion of the project direction?

[jnovack]

Consider how https://github.com/nfarina/homebridge and https://github.com/KhaosT/HAP-NodeJS are separate and distinct.

HAP-NodeJS is Apple's HomeKit Accessory Protocol AND THATS IT. That's what I envision this library as. A straight single port, that gets updated every time they push out a protocol update.

Then, homebridge is the application/backend that uses the protocol. Then, on top of that, a third party front-end interfaces with homebridge, the back-end application.

[jnovack]

If this library (or the foundation/protocol/stormreplay library, whatever we are calling it) is going to be an automated build, it should be ONLY exactly what Blizzard/heroprotocol is. No documentation, nothing.

In this manner, we can build the javascript heroprotocol (again, I prefer heroprotocol, not heroprotocoljs) and put it right on npm from the automatic build script.

We write our own heroprotocol.js entry point (ReplayDecoder) into the application (one that doesn't require command line arguments, returns data how we want it (JSON?, emit?) ) and do automated pushes to NPM after vigorous tests. The build script would be responsible for adding keeping this clean.

The heroprotocol library would be the parser and nothing else.

[ajbdev]

Agreed with @jnovack

The library in this case would be the essential building blocks of other ones - I've got a whole bunch of ideas floating around that I'll share here incase it inspires someone else:

• A more advanced game score GUI that auto displays after games as soon as the game is finished using NW.js. Just leave the app up displaying on a second monitor and it could process it as soon as the replay becomes available. Could compare metrics across games to show where your game improved.
• Tease out data points and regularly publish them somewhere (there's a couple I'm specifically interested in, such as "number of messages" and winrate, which should be easy to get at)
• Have an alternate upload site hotslogs where the data itself is released under a creative commons license and anyone is free to analyze it.

As @jnovack mentioned, it would be very desired to leave the output of the data structures as native to javascript and normalized as possible.

[Farof]

I feel like making heroprotocol.js a faithful port and it being optimized and practical are two different things, am I wrong? This port is the most contact I've ever had with Python, but the original heroprotocol.py seems to just be a quick output tool, with "quick" as in "quick to use and get usable data to look at", not "practical and performant for massive parsing and extraction".

My inclination is to remove some overhead from heroprotocol.js like the the EventLogger and CLI, rework the ReplayDecoder, and make this file a pure library and API used by everything else to access the raw data efficiently.

Besides that, adding a heroprotocol-cli.js that mimics the original heroprotocol.py on the root directory, and higher order tools and abstractions in bin/ and lib/ until they deserve dedicated projects or someone creates something better elsewhere?

---

I'm worried about fragmenting the codebase between different projects this early but it's something I look forward to if this project gains in popularity or it becomes clear it's needed at some point.

I think I'm going to look at port automation of remaining and future protocols soon because it seems needed to efficiently keep track of data structure changes between builds/patches.

I don't think going beyond basic abstraction by providing analysis tools has a place on this repository though, but @ajbdev if you want to start something it would be great to figure out what is required out of this library and it's current limitations.

[jnovack]

My interpretation is the same as yours on heroprotocol.py, it's just a helper script and a quick and dirty implimentation OF the protocol (just happens to be in the same repo)

The "faithful port" (to me) was each of the protocol files, that's where the meat and potatoes are. The entry point into the protocol files (heroprotocol.py) I do NOT consider part of the "protocol" and thus in order to make it streamlined that's the only piece we would write.

We know what the data looks like, rather than write it to disk (heroprotocol.py), we return it or emit it up to the calling application.

Or if you want to be "more" faithful, keep heroprotocol.py and we write the real NodeJS entrypoint as index.js. This way, the repo is a faithful port, but our abstraction library (index.js) is what is being used when we npm install heroprotocol as a dependency.