Stand-alone client

[AlexanderDzhoganov]

I've managed to parse the game database thanks to this document by NimVek (Huge thanks for writing that!). The JSON blob is pretty large and contains a lot of info. Here is an example JSON dump.

Also I've started work on a standalone client (standalone.js) as the mobile app makes my device get quite hot after a while and running the app for hours on end is painful.

Depends on https://github.com/rgbkrk/pipboylib/pull/10 Depends on https://github.com/rgbkrk/pipboylib/pull/14

[rgbkrk]

Oooh awesome! Yes, we definitely need a standalone client. The relay was put up as a way to start figuring the protocol out without having to mess with packet captures.

[AlexanderDzhoganov]

I've started a repo for a browser-based client to the socket.io server - https://github.com/AlexanderDzhoganov/pipboyclient

Got real-time world map working - screenshot here

[nelix]

This is very cool, I am stuck at work so I can't play with it yet. Can't wait.

[mattbaker]

I've managed to parse the game database thanks to this document by NimVek (Huge thanks for writing that!). The JSON blob is pretty large and contains a lot of info. Here is an example JSON dump.

Hot damn. Well done.

[rgbkrk]

Looking through both this PR and your really excellent client @AlexanderDzhoganov - it would make a lot of sense to make it be an Electron app. You wouldn't have to use socket.io (direct node-to-browser just fine in Electron) and user's won't be running servers on their machines, just a full native app they can download.

[AlexanderDzhoganov]

I have done some clean-up and moved most of the code to a separate PR in pipboylib. I have removed all of my changes to cli.js for the time being.

[rgbkrk]

Wow I finally looked at that JSON dump. Definitely huge. :smile:

[rgbkrk]

Ok, yeah this is looking really nice. I went through and reimplemented this locally using pipdb and pipdecode and it made me realize where the relay fell short. If I connect, disconnect, connect, I end up putting the state of the last expectedSize out of whack, causing it all to crash.

[rgbkrk]

Awesome. I think this is ready to at the very least be part of the current relay right now.

[rgbkrk]

As in, I'm using this and it's pretty awesome.

[rgbkrk]

[rgbkrk]

Definitely wondering if we should be doing some post processing of the db to turn all the arrays of {value: 8000, text: "Caps Found", showIfZero: true} into "Caps Found": {value: 8000, showIfZero: true}. This would be under the assumption that there are no collisions on the keys there.

Tradeoffs are that we're currently mirroring the actual format vs. something friendly to reach into programmatically in JavaScript (assuming order may change).

[landongn]

@rgbkrk If you implement it as some kind of mapping, I could see that being nice. Flipside though, if this ends up being used by other services expecting parity with the wire protocol, it could cause some divergence. Maybe once there's specific needs?

[rgbkrk]

Yeah, that's definitely the tradeoff. You'd think that if folks expect true parity with the wire protocol that we would just saw the raw bytes at that point. Way more compressed, certainly.

[landongn]

Since the work for implementing eventEmitters is happening, that extra event would be a pretty easy way to grab it rather than the other events.

:bike:

[NimVek]

If you change the order or style of the Tree, you should remember that updates always have an index in the db. So you must always trace back how you changed ist. Better is a type of overlay to the db. Second thing is that under sortedIDS, stimpackObjectID and radawayObjectID are indexes to the db are stored as values.

[rgbkrk]

Now that rgbkrk/pipboylib#14 is merged, think this is ready?

[AlexanderDzhoganov]

Yes, we should probably merge this now.