EPThttp://www.tempfiles.net/download/201007/111586/Lost-Temple-(6).html
Sc2gears 14.3.3: Replay version 2.1 support - Page 12
| Forum Index > SC2 General |
|
Yellow-Snow
United States55 Posts
http://www.tempfiles.net/download/201007/111586/Lost-Temple-(6).html | ||
|
DtE
France36 Posts
Considering that they might change it once again for the release, I hope Blizzard's not wasting your time  | ||
|
NukeTheBunnys
United States1004 Posts
If you need/want any help with the code I would be happy to work on it, looks like a cool project | ||
|
Dakota_Fanning
Hungary2359 Posts
On July 15 2010 02:57 DtE wrote: How many do you need ? I could probably email you a pack of my (worthless) replays if you need. Custom games (normal maps though, custom maps like TD are broken ATM) and ladder games, mainly 1v1 and 2v2. Considering that they might change it once again for the release, I hope Blizzard's not wasting your time The more the better. It doesn't matter whether it was a gg or not. Any replay is good for sample. | ||
|
CynanMachae
Canada1459 Posts
On July 08 2010 02:05 korona wrote: Suggestion: Race-specific match-up statistics for random players. Random players have to master 9 different match-ups. They often have weaknesses in some of the match-ups. For example I did not correctly recognize what my weak match-ups were before manually checking my MU statistics. Yea, I'd really like something like that too. Some way for random players to sort the distinct matchups, not only RvX but the three for each. | ||
|
nanii
France30 Posts
I have one question: Have u planed to release sc2gears 1.40 before the game release? | ||
|
Dakota_Fanning
Hungary2359 Posts
On July 20 2010 20:46 nanii wrote: Hi Dakota, thank you for the great job you've already done. I have one question: Have u planed to release sc2gears 1.40 before the game release? Yes I do. But there is one last part I haven't figured out in the new replay format: how the coordinates are coded in the move screen actions. Once I got it I release the new version. If anyone else knows how to get the x-y coordinates of the move screen actions, tell me so I can release it sooner. | ||
|
nanii
France30 Posts
| ||
|
Ascylon
Finland12 Posts
http://pastebin.com/1duwCDxf Hopefully it helps. | ||
|
Dakota_Fanning
Hungary2359 Posts
On July 21 2010 01:12 Ascylon wrote: Here's the code I use, but since the parser is just for data and camera movements are not important to me, I haven't researched what the x-coordinates or y-coordinates exactly mean. They seem to increment/decrement pretty logically in any case. I've also included a test replay event file I used for figuring this out so you can see for yourself: http://pastebin.com/1duwCDxf Hopefully it helps. Thanks, that helps a lot. 1 question, maybe you already know the answer. What are the top right coordinates on different maps? I mean on Blistering Sands they are x: aa00 y: 6c00 which has a size of 176x152 (playable size: 138x110). I can probably figure it out, but if you already know the answer, that can save me some time. | ||
|
Ascylon
Finland12 Posts
| ||
|
Dakota_Fanning
Hungary2359 Posts
I can translate them into decimal map coordinates. But sometimes the decoded value requires a +128 shift (requires to add 128) and I can't tell when based on the coded format. But it's coded in it somehow. If anyone feels like giving it a try, please do. In the spoiler below I copied the coded coordinates of the x axis. The first one is x=244 and are decreasing as I moved the screen from right to left. The last coordinate is x=12. So the x coordinates in this example are in the range of 244..12. + Show Spoiler + 6800 // x=244 646a // x=242 60ba 5e11 5a7b 57b7 53fb 5144 4da1 4aeb 4721 4477 40e2 3d3f 3a7b 36be 3408 3065 2dae 29f2 272e 238b 20ba 1d25 1a61 1697 13ee 1058 0cb5 09d7 0642 038b ffe9 fd25 f968 f6a4 f30f f04b ec9b e9e5 e642 e371 dfe9 dc46 d98f d6cc d329 cf93 ccd0 c92d c64f c2ba c003 bc39 b98f b5fa b257 afa1 abf1 a93a a58a a2d4 9f17 9c6d 98be 9607 9257 8ec2 8c0b 885b 858b 81e8 7f31 7b67 78be 751b 7264 6ea8 6bfe 6868 64c6 6202 5e5f 5b9c 57ec 551b 5193 4edc 4b2c 485b 44c6 4202 3e5f 3b81 37ec 3528 316b 2dd6 2b12 276f 24ac 2109 1e52 1ab0 17df 143c 1186 0dd6 0af8 076f 04b9 0116 fe38 faa3 f6f3 f43c f07f edc9 ea26 e73b e3b3 e0fc dd59 da95 d6d9 d422 d07f cda1 ca0c c748 c3a5 c0d5 bd3f ba7b b6b1 b31c b072 acc3 aa0c a642 a38b 9ff6 9d32 // x=14 998f // x=12.5 9800 // x=12 In the spoiler below I copied the coded coordinates of the y axis. The first one is y=252 and are decreasing as I moved the screen from top to bottom. The last coordinate is y=4. So the y coordinates in this example are in the range of 252..4. + Show Spoiler + 7800 // y=252 764f // x=251 72c7 6f58 6cd6 695b 65b8 6302 5f52 5c81 58d1 560d 5251 4f8d 4bdd 48ff 4621 424a 3f86 3bd7 3906 352f 325e 2f9a 2bdd 282d 2528 2271 1ec2 1be4 1834 1556 118c 0ed5 0c12 082d 054f 0193 fec2 fb05 f841 f53c f199 eeae eb0b e848 e463 e1a0 dde3 db05 d85b d477 d1a6 cde9 cb0b c741 c471 c1ad bde3 bb12 b721 b46a b199 addc ab0b a70d a456 a0a7 9dbc 9a0c 9721 9450 90a0 8ddc 8a12 8727 8456 809a 7dd6 7a19 7721 737e 7093 6ce3 6a12 6700 6350 608c 5cb5 59f2 56ec 533d 5079 4cbc 49eb 4700 4343 407f 3ca8 39e5 360d 333d 2f8d 2cbc 29d1 2607 2343 1f79 1cb5 18f9 1600 133d 0f73 0caf 08f2 0614 0271 ffae fbd7 f920 f635 f26b ef9a ebea e90c e535 e257 dfa1 dbf1 d920 d52f d26b cea1 cbd0 c90c c528 c264 bea7 bbc9 b81a b522 b25e aeae abf7 a82d a54f a185 9ec2 9b05 9827 953c 9172 8eae 8b0b // y=5 8848 // y=4.5 8800 // y=4 Hint (if you don't know how to start) + Show Spoiler + The listed coordinates are in hexadecimal base. Add 0x8000 to the value and shift right by 1. You might or might not need to add 128 to the result to get the proper coordinate. If anyone figures it out, please share. | ||
|
dvide
United Kingdom287 Posts
http://forums.battle.net/thread.html?topicId=25968747423&sid=5000 The recent patch seems to have completely broken the ability of SC2 to determine the location of a players camera outside of a specific region of the map. The following appear to be effected by this- The F-Look commands that bind a point to a key, the lock camera common when viewing replays, and the Galaxy functions that determine the point or yaw of any players camera. Moreover, it appears to only effect boundaries outside of a 64x64 square on varying corners of the map. Spent a minute making a map to demonstrate. It correctly tracks the player camera, but only in within a certain bounds. As a result, the ability of the replay to track camera movement, as well as the function needed for mapmakers to do the same, do not work. http://rapidshare.com/files/405801891/wtf.SC2Map Its a problem thats greatly effecting mappers, as well as breaking other core functions of the game. | ||
|
Dakota_Fanning
Hungary2359 Posts
On July 23 2010 22:18 dvide wrote: Are you sure it even makes sense? Might it be related to the first person camera bug that was introduced in phase 2? http://forums.battle.net/thread.html?topicId=25968747423&sid=5000 Oh Jeez... did I spent my last week finding something that isn't even there? Can someone confirm this as if I recall it well Blizzard fixed something related to camera movement in one of the beta phase 2 patches. | ||
|
Flipperbw
6 Posts
I've converted all hexes to decimal, and am trying to figure out how you get x=244 from xHex=6800 (xDec=26624). What is the conversion? It's not a static number... I'm also just not sure what you mean by the 128 addition or the 0x8000 addition. Additionally, I've found that the Decimal values differ in each step by a number close to 900 or 700. This is what the graph looks like of the values (logically straight, but with slight bumps. and the jumps are as it switches to 65535.) + Show Spoiler + ![[image loading]](http://imgur.com/0CO0k.png) | ||
|
Flipperbw
6 Posts
1) Convert all hexes to decimal. 2) When decimals "wrap" up to 65535, convert to the negative equivalent, as if they continued down (i.e. subtract 65535). 3) Divide all wrapped decimals by 512. 4) Add 192 to the result. 5) You get the coordinates (which are not pretty numbers, but I think are exact). I know this sounds like a chain email from 1997 where you'd get your age in chocolate or something, but it seems to work. See the spoiler for the coordinates of the x hexes you posted in the post above. 244-->12. + Show Spoiler + 244 242.2070313 240.3632813 239.0332031 237.2402344 235.8574219 233.9902344 232.6328125 230.8144531 229.4589844 227.5644531 226.2324219 224.4414063 222.6230469 221.2402344 219.3710938 218.015625 216.1972656 214.8398438 212.9726563 211.5898438 209.7714844 208.3632813 206.5722656 205.1894531 203.2949219 201.9648438 200.171875 198.3535156 196.9199219 195.1289063 193.7714844 191.9570313 190.5742188 188.7050781 187.3222656 185.53125 184.1484375 182.3046875 180.9492188 179.1308594 177.7226563 175.9570313 174.1386719 172.78125 171.4003906 169.5820313 167.7890625 166.4082031 164.5898438 163.15625 161.3652344 160.0078125 158.1132813 156.78125 154.9902344 153.171875 151.8164063 149.9726563 148.6152344 146.7714844 145.4160156 143.546875 142.2148438 140.3730469 139.015625 137.171875 135.3808594 134.0234375 132.1796875 130.7734375 128.9550781 127.5976563 125.703125 124.3730469 122.5546875 121.1972656 119.3300781 117.9980469 116.2050781 114.3886719 113.0058594 111.1875 109.8066406 107.9628906 106.5546875 104.7890625 103.4316406 101.5878906 100.1796875 98.38867188 97.00585938 95.1875 93.75390625 91.96289063 90.58007813 88.7109375 86.91992188 85.53710938 83.71875 82.33789063 80.51953125 79.16210938 77.34570313 75.9375 74.11914063 72.76367188 70.91992188 69.48632813 67.71875 66.36328125 64.54492188 63.11328125 61.32226563 59.47851563 58.12109375 56.25195313 54.89648438 53.078125 51.61914063 49.85351563 48.49609375 46.67773438 45.29492188 43.42773438 42.0703125 40.25195313 38.81835938 37.02734375 35.64453125 33.82617188 32.41992188 30.62695313 29.24414063 27.34960938 25.55859375 24.2265625 22.38476563 21.02734375 19.1328125 17.77539063 15.984375 14.6015625 12.78320313 12.00390625 | ||
|
Dakota_Fanning
Hungary2359 Posts
This wasn't a problem before. The problem is: a hexadecimal value can be assigned to 2 different map coordinates. For example: 0x6800 can mean x=244 and x=116 (difference is 128) What I don't know is how to choose which of the 2 possible value is coded (which one to decode to). | ||
|
jacen
Austria3644 Posts
On July 27 2010 02:35 Dakota_Fanning wrote: What I don't know is how to choose which of the 2 possible value is coded (which one to decode to). i would suggest trial and error replays with zerg, sending overlords to specific map coordinates should give you a good idea how to decode them, right? even if they don't start at the top right with 0;0, you might still be able to figure that out, right? | ||
|
Dakota_Fanning
Hungary2359 Posts
On July 27 2010 03:47 jacen wrote: i would suggest trial and error replays with zerg, sending overlords to specific map coordinates should give you a good idea how to decode them, right? even if they don't start at the top right with 0;0, you might still be able to figure that out, right? Trial and error does not work. Taking my previous example: If you move the screen to x=244, you will see 0x6800 coded value in the replay. If you move your screen to x=116, you will also see a 0x6800 coded value in the replay. So when I try to parse and interpret the replay, I see a 0x6800 coded value, and I can't choose whether it was x=244 or x=116. | ||
|
meCa
Canada58 Posts
Great. Could it be possible to have the APM peak like in BWChart? Which is a little arrow that points at the highest peak your APM went to during the match. | ||
| ||
