Comments (5)
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.
from heroprotocoljs.
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.
from heroprotocoljs.
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.
from heroprotocoljs.
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.
from heroprotocoljs.
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.
from heroprotocoljs.
Related Issues (20)
- Code commenting HOT 1
- Prettying up and modernizing the code HOT 4
- Tests HOT 1
- Write initial replay.game.events reference HOT 1
- Grunt HOT 1
- extract.js - add options to only extract certain files HOT 2
- extract.js - add option to skip existing files HOT 2
- extract.js - keep directory structure when extracting directories recursively
- Write initial replay.attributes.events reference
- Query tool HOT 6
- Spread operator not supported in Node v4 HOT 2
- extract.js - pretty mode should sort properties alphabetically HOT 3
- TypeError: decoder.CorruptedError is not a function HOT 2
- One less abstraction layer... HOT 2
- _gameLoop in tracker and game events is null HOT 2
- Post-Install Download of Original Repo HOT 2
- Cannot Parse m_timeUTC and m_timeLocalOffset HOT 3
- Not working HOT 5
- Matching BNet account HOT 4
- Replays from newer patch uses older protocol HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from heroprotocoljs.