pbug90 / w3gjs Goto Github PK

Currently tomes of retraining are not taken into account.

Have to check whether it is possible to take it into account with the current hero skill data structure or whether changing them might be a better idea.

Similarly to #67 , we have some more failures due to players that cannot be found. I have attached a replay with the issue. This time it's a Netease replay
moju_vs_fly.zip

Currently we just assume that the first skill learned after the tome was used represents the hero that used the tome. This can be wrong. We might be able to track the correct hero via selection/subselection events.

hi, am working on upgrading to v2 and am running into an issue with the SelectSubgroupAction and possibly other actions

the itemId is now in the array format of [ 111, 99, 97, 117 ] instead of the previous 4-character string encoded format

example action json

 {
  id: 25,
  itemId: [ 111, 99, 97, 117 ],
  objectId1: 18451,
  objectId2: 18457
}

believe the previous versions handled this data encoding by doing this:

if the above is something you'd prefer we do outside of the parser will happily change to that

thanks!

Does the replay keep track how people leave the game? Can you tell if someone closes completely, or clicks "Quit/Exit", or if they lose connection to the bnet? Are there any errors that can be found when parsing these replays.

Appreciate this, still learning warcraft 3 replays and what data can be gathered.

The parser was used here https://warcraft3.info/replays/50537
For some reason it shows Keeper of the Grove at Level 19. The actual level was 6.
There was no Tome of Retraining used.
Replay link if you need it:
replay.zip

Improve the CICD pipeline and use github actions. Also make sure releasing to NPM is done automatically.

I've been trying to parse files created by WCIII reforged and it's not compatible. Can we collaborate on improving the parser? I've never parsed binary formats before, but I can work through it.

Parsing the header fails really quickly with an offset error, which I assume means the byte counts are off compared to the original file format.

Thoughts?

Not sure what this action does (I suspect it may be related to the new keyboard/oskeytype natives). It appears to always be 21 bytes long (including the action identifier). Example replay here: https://wc3stats.com/games/8632

Edit: can confirm it's for keyboard events. I found that bytes 13-16 is for the oskeytype, and 17-20 is the metakey. For example, when pressing alt+f4, the action block's bytes will end with "0x73 0 0 0 4 0 0 0". I'm still investigating the meaning of the first 12 bytes.

I have a replay with an issue where the player is not in the W3GReplay.players object. The replay fails in processCommandDataBlock since the playerId has not been added. I have seen that players are only added to that object depending on their slotStatus in handleBasicReplayInformation. What does that slotStatus actually mean? If I remove that condition, the replay can be parsed. But it returns a high amount of players. How should we go about this - should we just make the parser more capable to deal with the fact when a player cannot be found? Attached the replay
ced_vs_lyn.zip

Edit: Apparently this (and other replays with the same issue) are customs from the new W3C Flobot.exe

Hi there 👋

I've been seeing this error pop up on a few multiplayer replays as of late:

RangeError [ERR_BUFFER_OUT_OF_BOUNDS]: Attempt to access memory outside buffer bounds
    at boundsError (internal/buffer.js:75:11)
    at Buffer.readUInt8 (internal/buffer.js:243:5)
    at Parser.eval [as compiled] (eval at <anonymous> (eval at otherRunInContext (/jeef/wc3v/node_modules/w3gjs/dist/W3GReplay.umd.js:1:1)), <anonymous>:4:14)
    at Parser.parse (/jeef/wc3v/node_modules/w3gjs/dist/W3GReplay.umd.js:3064:25)
    at W3GReplay.ReplayParser._parseHeader (/jeef/wc3v/node_modules/w3gjs/dist/W3GReplay.umd.js:5075:40)
    at W3GReplay.ReplayParser.parse (/jeef/wc3v/node_modules/w3gjs/dist/W3GReplay.umd.js:5051:18)
    at W3GReplay.parse (/jeef/wc3v/node_modules/w3gjs/dist/W3GReplay.umd.js:5183:36)
    at /jeef/wc3v/wc3v.js:53:29
    at Array.map (<anonymous>)
    at Object.parseReplays (/jeef/wc3v/wc3v.js:41:25) {
  code: 'ERR_BUFFER_OUT_OF_BOUNDS'
}

attached is a mzip file with one wc3 replay inside called bufferissue.w3g

bufferissue.zip

system info:

node version: v12.18.0

Debian GNU/Linux 9 (stretch)

kernel: 4.9.0-11-amd64

on windows 10 using node v12.16.0 it seems to not error but possibly has some issues with player data as I'm not seeing action blocks for 2 of the 4

Thanks so much for all your work on this 👍 Was wondering if there was anything more information or debugging you'd like me to submit for these errors on replays?

Hello again, can you also expose the w3mmd variable in the finalize function? I wanna get some custom data from a custom game. :D

Not exactly sure how w3mmd works tho from what I've parsed I've always gotten this type:

type W3mmdAction = {
actionId: number;
filename: string;
missionKey: string;
key: string;
value: number;
};

Maybe set w3mmd's type to W3mmdAction[]

I'm writing my own 'parser' for this now cuz I can't really find anything public. If someone knows of something please let me know (:

Player auto-attacks multiple heroes, replay is the last thing I see Action 0x16
ObjectID1 61,55,0,0, ObjectID2 223,57,0,0
ObjectID1 31,30,0,0, ObjectID2 237,57,0,0
How to find out what it is by ObjectID1?
find trigger or Unit, Building, Area
How to determine how many heroes killed enemies?
Is it possible to know the triggers of everything that happens?

great tool, thanks for releasing it 👍

have a question about when looking at the targetX and targetY values of an ActionBlock with those properties - it seems the values are large numbers

x: -980223926, y: 1162084274

is there additional conversion needed to align them to the map coordinates? for example Echo Isles seems to be only ~10,000 units wide in the world editor

thanks!

Hi - thanks for your hard work as always

I've started using the latest 1.6.0 release and I have noticed that alphanumeric itemId values might have possibly changed while trying to parse a pre-reforged replay from the last major patch.

I am now getting a value of 19 for the third item in the list pretty consistently when it used to always be marked as 13 (0D in hex)

Following this old guide used to match these values for the much older 1.1.2 release of w3gjs I would previously get a value of 13 for the right click - link to format guide: https://github.com/scopatz/w3g/blob/master/w3g_actions.txt#L961

Old w3gjs (1.1.2) version output: [ 3, 0, 13, 0 ]
New w3gs (1.6.0) version output: [ 3, 0, 19, 0 ]

Do you think these values have changed as a result of the reforged changes? Or is it possible the new values are being decoded incorrectly?

I can provide an older replay if needed or helpful

Thanks!

Floats seem to be single precision IEEE floats, but the actual value used in game appears to be rounded to the third digit after the comma, e.g. the point

( -3153.615966796875 | -4017.91357421875)
is represented ingame as
(-3153.616 | -4017.914).

This can be observed in the World Editor aswell.

Maybe it would make sense to update the parser to use this kind of precision aswell.

Getting a head start on this, works the same in classic and reforged
#40

TypeError: Cannot set property 'playerName' of undefined
at /node/classic-chat-bot-node/node_modules/w3gjs/src/W3GReplay.ts:108:61

The replay: https://tft.w3replayers.com/replays/download.php?id=29177

👋 running into some new buffer out of bounds errors using latest 1.7.1 release

running on win10 with node version v12.16.0

full error message when calling W3GReplay.parse on the attached replay file

RangeError [ERR_BUFFER_OUT_OF_BOUNDS]: Attempt to access memory outside buffer bounds
    at boundsError (internal/buffer.js:74:11)
    at Buffer.readInt8 (internal/buffer.js:414:5)
    at Parser.eval (eval at <anonymous> (eval at otherRunInContext (C:\Users\Jeff\Code\wc3v\node_modules\w3gjs\dist\W3GReplay.umd.js:2338:25)), <anonymous>:172:31)
    at Parser.eval [as compiled] (eval at <anonymous> (eval at otherRunInContext (C:\Users\Jeff\Code\wc3v\node_modules\w3gjs\dist\W3GReplay.umd.js:2338:25)), <anonymous>:174:12)
    at Parser.parse (C:\Users\Jeff\Code\wc3v\node_modules\w3gjs\dist\W3GReplay.umd.js:3064:25)
    at W3GReplay.ReplayParser.parse (C:\Users\Jeff\Code\wc3v\node_modules\w3gjs\dist\W3GReplay.umd.js:5039:89)
    at W3GReplay.parse (C:\Users\Jeff\Code\wc3v\node_modules\w3gjs\dist\W3GReplay.umd.js:5156:36)
    at C:\Users\Jeff\Code\wc3v\wc3v.js:53:29
    at Array.map (<anonymous>)
    at parseReplays (C:\Users\Jeff\Code\wc3v\wc3v.js:41:25) {
  code: 'ERR_BUFFER_OUT_OF_BOUNDS'
}

attached replay file in a zip folder. contains one file twistedmedows.w3g

twistedmedows.zip

Per request a new issue.

Wondering if it's possible to determine player starting position from the replay for a given map?

I haven't found any related documentation on the topic from other replay format docs. My current guess would be that the information is potentially in the given 'random seed' for the map?

Hello, i find many w3g reply analysis repos, but only this can support nwg and w3g both.
Now i want to using other languages to analysis reply file, maybe there is some specifications of formation of reply file?

Since the output is currently very verbose and not a lot of information can be used efficiently, I would like to suggest a well defined object that models all required information in an easy way so that both humans and machines can interpret it easily. This is a work in progress and not yet complete. Feel free to comment.

{
  "players": [
    {
      "name": "",
      "race": "",
      "raceDetected": "",
      "color": "",
      "units": {
        "summary": {
          "hfoo": 5,
          "hbar": 10
        },
        "order": [
          {
            "ms": 1500,
            "id": "hfoo"
          },
          {
            "ms": 2500,
            "id": "hfoo"
          }
        ]
      },
      "teamid": 2,
      "id": 0,
      "buildings": {
        "summary": {
          "hfoo": 5,
          "hbar": 10
        },
        "order": [
          {
            "ms": 1500,
            "id": "hfoo"
          },
          {
            "ms": 2500,
            "id": "hfoo"
          }
        ]
      },
      "upgrades": {
        "summary": {
          "hfoo": 5,
          "hbar": 10
        },
        "order": [
          {
            "ms": 1500,
            "id": "hfoo"
          },
          {
            "ms": 2500,
            "id": "hfoo"
          }
        ]
      },
      "items": {
        "summary": {
          "hfoo": 5,
          "hbar": 10
        },
        "order": [
          {
            "ms": 1500,
            "id": "hfoo"
          },
          {
            "ms": 2500,
            "id": "hfoo"
          }
        ]
      }
    }
  ],
  "gamename": "",
  "matchup": "a well defined, universal matchup string",
  "uuid": "a game uuid that is generated for this particular game",
  "type": "1vs1",
  "creator": "BNet",
  "map": {
    "path": "Maps\\FrozenThrone\\(4)TwistedMeadows.w3x",
    "shortened": "TwistedMeadows",
    "file": "(4)TwistedMeadows.w3x"
  },
  "version": "1.31",
  "settings": {
    "visibility": 0,
    "hideTerrain": true,
    "mapExplored": true,
    "alwaysVisible": true,
    "default": true,
    "teamsTogether": false,
    "randomHero": false,
    "randomRaces": false,
    "referees": false,
    "fixedTeams": true,
    "fullSharedUnitControl": true,
    "speed": 2
  },
  "observers": [
    "observer1",
    "observer2"
  ],
  "chat": [
    {
      "mode": "ALL|ALLY|OBS|REF|PRIVATE",
      "player": "a playername",
      "message": "the chat message"
    }
  ],
  "replayIdentifier": "algorithm tbd"
}

example replay: https://w3replayers.com/replay/28951

First of all, thanks for your time spent in this newly made parser; it indeed looks more modular than others.

In a few days I'll be having more spare time to play with stuff like this and I probably help you by creating some PR. But first I'd like to ask you a few questions:

• Are you parsing any new data compared to the classic parser made by julas? (Here the nodejs version: https://github.com/HydraOrc/w3g).

• Did you manage to find the correct offsets for the winner? There were some weird behaviours detecting the correct winner in custom games.

• Why didn't you use es6 classes? they're cleaner and newer, and since you made it from scratch...

Thank you.

PS: this is crearly not an issue, I just had no other way to get in touch with you.

We have detected in our website - which is using the Julas's modified PHP parser - a bunch of weird behaviours after the release of the last patch. I'm not sure if this is related to any of the hotfixes though.

• The parsers are not detecting game version correctly. You can check it with this very same parser and the following: Replay
  It throws: version: 10030. Where's the .2? And why those 00 between 1 and 3?

There are more strange things going on but I don't have confirmation that they're real. I'll be around.

wondering if it's feasible to implement the parsing of the 0x1A block in the GameDataParser.ts

This block was previously supported in 1.0 and gives contextual information about units shifting in-place within a selected group along with some other minor things.

The blocks existence is enough information to be used but if I'm reading this correctly it seems to be skipped at the moment - https://github.com/PBug90/w3gjs/blob/master/src/parsers/GameDataParser.ts#L63-L65

A Promise-based Async Parsing API that allows the event loop to process pending messages. Since parsing itself is a synchronous operation from start to finish and currently synchronous APIs are heavily utilized, this means that the following operations can be swapped for async ones to allow the event loop to do work during parsing:

• change fs.readFileSync to its async API
• change inflate to its async API
• after parsing one or more GameDataBlocks, allow the event loop to process its queue and continue parsing afterwards

when parsing actions for UnitBuildingAbilityActionTargetPositionTargetObjectId the objectId1 and objectId2 field are incorrect - they are always the value 4294967295 in every action

example output

{
   "id":18,
   "abilityFlags":0,
   "itemId":[
      3,
      0,
      13,
      0
   ],
   "targetX":-291.32562255859375,
   "targetY":1627.026123046875,
   "objectId1":4294967295,
   "objectId2":4294967295
}

example replay file with issue is attached as replay-object-id-issue.zip with file test-ch-movement.w3g

replay-object-id-issue.zip

The chatlog mode when the obs are talking between them is incorrectly parsed, returning 33554432 instead of 0x02 (so obviously, the formatter isn't working either).

Hello, can we make the readFileSync optional? I'd like to pass the complete replay as string. I'm using a node webserver and already have the replay contents. Don't really wanna write it to a file so that it can be parsed.

https://github.com/PBug90/w3gjs/blob/master/src/ReplayParser.ts#L45

Tried to do it myself but for some reason VS code keeps formatting the entire file differently :)