ohio813 / phpsc2replay

Automatically exported from code.google.com/p/phpsc2replay
0 stars 0 forks source link

Does not work for v 1.2.0 replays #39

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Update SC2 to 1.2.0
2. Play Game
3. Upload Replay!
;-)

Works perfectly for all of my files up until 1.2.0, then crashes and scrolls 
errors. Thanks for all the hard work. (I know 1.2.0 is not supported yet, but I 
figured I'd add the issue)

Original issue reported on code.google.com by tehels...@gmail.com on 12 Jan 2011 at 5:57

GoogleCodeExporter commented 9 years ago
I attached a 1.2.0 file in order to reproduce the error easily.

Basically, here are the displayued errors:
Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 1 
in /opt/lampp/htdocs/ooaemkee/SC2Replay/mpqfile.php on line 103

Warning: unpack() [function.unpack]: Type V: not enough input, need 4, have 0 
in /opt/lampp/htdocs/ooaemkee/SC2Replay/mpqfile.php on line 103

Thanks for the good work!

Original comment by waib...@gmail.com on 12 Jan 2011 at 11:58

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by lauri.vi...@gmail.com on 12 Jan 2011 at 5:16

GoogleCodeExporter commented 9 years ago
Seems like the replay.attributes.events file has a 5 byte header now, instead 
of the old 4 byte one. With the below patch, it at least seems to parse the new 
replays without a huge list of errors. Haven't checked further.

Original comment by zsol.z...@gmail.com on 12 Jan 2011 at 10:05

Attachments:

GoogleCodeExporter commented 9 years ago
Also changing the 'player joined' event code lets the game events parse. 
Unfortunately a lot of event codes are messed up...
Attaching revised patch anyway. hope this helps

Original comment by zsol.z...@gmail.com on 12 Jan 2011 at 10:31

Attachments:

GoogleCodeExporter commented 9 years ago
Those changes stop the errors, but break parsing of older replays. I am 
starting to work on some changes parse replays differently based on their 
version number.

Has anyone looked at this yet or have any ideas?

Original comment by tehels...@gmail.com on 13 Jan 2011 at 1:11

GoogleCodeExporter commented 9 years ago
OK, here is a temporary solution.

I have created multiple replay classes and the correct one gets used based on 
the build in the MPQ file. parseReplay() will now return a replay class of the 
correct type. I'm sure theres a better way to do this using polymorphism or 
something, but it works for what I needed.

SC2Replay.php is unnecessary as far as I know, but I'm leaving it in in case I 
want to figure out a better solution.

The numbers at the end of the file are the SC build the class is for. 16939 
works for several builds up until that build.

Original comment by tehels...@gmail.com on 13 Jan 2011 at 1:48

Attachments:

GoogleCodeExporter commented 9 years ago
I have checked in a different approach based on inheritance in my development 
branch here: http://code.google.com/p/phpsc2replay/source/browse/?r=zsol
let me know what you think

Original comment by zsol.z...@gmail.com on 13 Jan 2011 at 8:38

GoogleCodeExporter commented 9 years ago
Hi,

I want to test it out but last commit was done 10 hours ago and definitely 
looks like the one you gave on comment 4.

Am I doing something wrong to get the new change you have done recently?

Original comment by waib...@gmail.com on 13 Jan 2011 at 8:51

GoogleCodeExporter commented 9 years ago
OK I got it, Sorry :(

Here is the place: 
http://code.google.com/p/phpsc2replay/source/detail?r=388cab54aafeb42bf119baa676
d4fe09debfae6a

I'll test it right now!

Original comment by waib...@gmail.com on 13 Jan 2011 at 9:07

GoogleCodeExporter commented 9 years ago
It's working fine for me :)

It's seems the only problem we have is the ability code in SC2ReplayUtils class.
I can't get "desc" or "name" vvalue anymore.

Actually, I got it for "Marine trains" and "Medivac trains"....
Am I the only one ?

Original comment by waib...@gmail.com on 13 Jan 2011 at 9:36

GoogleCodeExporter commented 9 years ago
good work guys keep it up. seems to be broken for teams/races etc. but I 
haven't investigated

Original comment by forelma...@gmail.com on 13 Jan 2011 at 4:56

GoogleCodeExporter commented 9 years ago
still have a few things to iron out here, expect some updates on sunday...

Original comment by zsol.z...@gmail.com on 14 Jan 2011 at 8:39

GoogleCodeExporter commented 9 years ago
Hi, very good news!
Thanks for keeping us updated :)

Original comment by waib...@gmail.com on 14 Jan 2011 at 8:42

GoogleCodeExporter commented 9 years ago
I tried the latest version and I was having some issues with paths. Some of the 
includes were not finding the files (I keep my classes in a 'classes' directory.

After I fixed the paths, I was still having issues with older and 1.2.0 
replays. Basically none of the correct info was showing up. Almost everything 
was empty and what wasn't was incorrect.

I reverted to my custom version for now. I may have set something up 
incorrectly though. Are you having issues like this? Any suggestions?

Original comment by tehels...@gmail.com on 16 Jan 2011 at 6:35

GoogleCodeExporter commented 9 years ago
I've tried current modifications from repository. It didn't work. I get "not 
MPQ archive error", so I switch back to older version. My current hack which 
works for 1.2 replays is following: replace all "unpack" -> "@unpack" (probably 
this update should be added to the next version). The only info which is not 
parsed: APM and Winner detection.

Original comment by amvn...@mail.ru on 16 Jan 2011 at 7:07

GoogleCodeExporter commented 9 years ago
Hi guys, how's it going? Are there any simple fixes i could apply (assuming we 
don't use apm, actions or whatever, just basic things like map, duration, 
races, and player names)?

Original comment by YellEl...@gmail.com on 16 Jan 2011 at 10:29

GoogleCodeExporter commented 9 years ago
You can use current trunk for now. It still has some issues with some abilities 
not parsing correctly, which I'm still chasing..
Essentially, you need these changes: 
http://code.google.com/p/phpsc2replay/source/detail?r=19c8d4aaf02e24390fc81c6423
9ce7f718ab33cd

Original comment by zsol.z...@gmail.com on 16 Jan 2011 at 10:46

GoogleCodeExporter commented 9 years ago
Would it be possible to stop parsing with unsupported retail versions? This 
way, we see a sensible error instead of the warnings issued by unpack?

Original comment by kacper.h...@gmail.com on 18 Jan 2011 at 11:58

GoogleCodeExporter commented 9 years ago
I don't think that there is a way to know if a specific future version
does brake the parsing. So you have to either stop all future versions
from working, even if they would work just fine or you'd have to
program in an error message as soon as you find a non working version.

Either way you'd have to update your files for every new sc2 version
before you could use it. => bad idea

The only other way would be to check the integrity of the file
structure before or while parsing. That would be a shitload of new
code and slower parsing. => not feasiable

slightly off topic: did anyone of you check any replays of the public
test version of 1.2.0? something like that might be a good source for
future structure changes.

Original comment by timo.g...@gmail.com on 18 Jan 2011 at 12:52

GoogleCodeExporter commented 9 years ago
Sorry, zsol, is it ok for now that race info can not be parsed?

Original comment by YellEl...@gmail.com on 18 Jan 2011 at 1:49

GoogleCodeExporter commented 9 years ago
#20: No, it's not OK. Can you attach a replay that breaks when parsing the race 
info, pls?
#18: We'd like to support parsing older versions. It would be a shame if all 
that effort would be wasted; and besides - nobody would want to wipe their 
replay database just because a new version came out.
#19: Checking the PTR would have been a good idea, unfortunately I personally 
did not have the time to do that. You are more than welcome to help out in the 
future ;-)

Original comment by zsol.z...@gmail.com on 18 Jan 2011 at 4:35

GoogleCodeExporter commented 9 years ago
if your browser sucks and crashes you can suppress the errors with @ and then 
it works...

Original comment by forelma...@gmail.com on 18 Jan 2011 at 5:26

GoogleCodeExporter commented 9 years ago
I see it was already  mentioned. unlike the guy above it seems to me RACE and 
TEAM are also broken

Original comment by forelma...@gmail.com on 18 Jan 2011 at 5:27

GoogleCodeExporter commented 9 years ago
Zsol, thanks for your help! Replays are attached.

Original comment by YellEl...@gmail.com on 18 Jan 2011 at 9:09

Attachments:

GoogleCodeExporter commented 9 years ago
Small thing: There are 3 bytes at the start of sc2replayutils.php in the trunk 
build before the <?php tag. This will lead to output being send so that php 
header() is not possible anymore.

This might be some relict from UTF encoding or something like that.

Original comment by timo.g...@gmail.com on 18 Jan 2011 at 11:32

GoogleCodeExporter commented 9 years ago
#25: Yes that is basically saying "the contents of this file is UTF-8". It's 
now removed.
#24: Thanks, I'll start working on it this evening.
#23: Can you attach sample replays, please?
#22: I created a separate issue to track this (I will probably implement some 
kind of explicit error checking and not rely on @): 
http://code.google.com/p/phpsc2replay/issues/detail?id=42

Original comment by zsol.z...@gmail.com on 19 Jan 2011 at 7:27

GoogleCodeExporter commented 9 years ago
Is it possible that these replays were recorded on the korean servers?
It seems that the data format is the same, and it might be that the race is 
there, correctly, in korean.

#23: I would like to see that replay where race and team are broken.

Original comment by zsol.z...@gmail.com on 19 Jan 2011 at 8:11

GoogleCodeExporter commented 9 years ago
I have an error parsing this replay. The error message says "Undefined offset: 
2017 in sc2replay.php on line 326"

Original comment by tehels...@gmail.com on 19 Jan 2011 at 8:20

Attachments:

GoogleCodeExporter commented 9 years ago
It happens to me for all replays after the patch 
http://wc.forelmashi.com/sc/reps/

I just assume it's the parser breaking since I didn't touch any of that code 
but if it's only happening to me perhaps it's something I've done

Original comment by forelma...@gmail.com on 19 Jan 2011 at 4:47

GoogleCodeExporter commented 9 years ago
#25: Unfortunately if I remove those first three bytes (the Unicode BOM), php 
can't parse sc2replayutils.php correctly. I have backed out that change. A 
workaround for the issue you mentioned could be turning on output buffering, or 
using a correctly built php binary. (this is a bug in php)
#24: After a lot of investigation, I have found out that these replays parse 
correctly. The issue is on your side. Try setting the encoding to UTF-8 and 
you'll see what I mean. BTW, these replays were recorded in Russia, most 
probably ;-) [clue - WhiteRa's race is Протосс, which is exactly how you 
spell Protoss with Cyrillic letters]
#29: You are definitely not using the latest trunk code, because with that, 
your replays parse just fine for me.
#28: Still looking at your replay, sit tight

Original comment by zsol.z...@gmail.com on 19 Jan 2011 at 7:46

GoogleCodeExporter commented 9 years ago
#25: forget what I just said, I realized that it was something else that caused 
php not to parse sc2replayutils. the BOM is now removed

Original comment by zsol.z...@gmail.com on 19 Jan 2011 at 7:55

GoogleCodeExporter commented 9 years ago
#28: fixed in the latest trunk. Please confirm

Everyone, please check out the latest trunk here: 
http://code.google.com/p/phpsc2replay/source/browse/

It is also installed at 
http://blissenobiarella.dyndns.info/~zsol/phpsc2replay-main/ so you can check 
your replay on the upload_file.php page and if it's fine there, you should be 
good.
I'm hunting down incorrect ability codes, so if you have some time, please run 
through as many replays as you can on the above upload_file.php with 
"attributes test" ticked on. That should give you a huge red box if there's any 
incorrect attributes. If you see that, please file a bug or report here. It 
would be good if you could find out what the attribute means, but I would 
greatly appreciate you just reporting it anyway! Thanks.

Original comment by zsol.z...@gmail.com on 19 Jan 2011 at 8:11

GoogleCodeExporter commented 9 years ago
Awesome #29 is fixed for me.

Now I have
Notice: Undefined offset: 71696 in /vdefault/sc2replayutils.php on line 1009
Notice: Undefined index: in /vdefault/sc2replayutils.php on line 1009
Notice: Undefined offset: 75521 in /vdefault/sc2replayutils.php on line 1009
...

For this replay when the events are being printed.

Original comment by tehels...@gmail.com on 20 Jan 2011 at 6:27

Attachments:

GoogleCodeExporter commented 9 years ago
Nevermind, I had not updated to the latest version and my last issue # was 
wrong (it was 28).

Everything is working great as far as I know! Thanks!

Original comment by tehels...@gmail.com on 20 Jan 2011 at 6:35

GoogleCodeExporter commented 9 years ago
hey guys i just want to thank you for patching this up!
i have a bachelors in EE/CS and i will soon slowly learn how everything is 
coded up (and hopefully help in the future -- if its ok), i've just been lazy 
but you guys are doing some really big things here ;-)

Original comment by actionge...@gmail.com on 21 Jan 2011 at 5:04

GoogleCodeExporter commented 9 years ago
Thank you guys for all work you've done! You are totally great!

Original comment by YellEl...@gmail.com on 21 Jan 2011 at 8:27

GoogleCodeExporter commented 9 years ago
Hey... so I'm trying to implement this on my website and its not working 
completely.

On localhost, it works 100% fine.  When I upload it to my website (hosted on 
godaddy.com), a lot of stuff stops working. Race, color, team, average apm, 
realm, the apm graphs, and the build order ALL fail to show up.

I am able to get the players and the map, and the duration.  Can anyone think 
of some possibilities as to why it works perfectly on localhost, then works 
maybe 20% on my server?  Is it some server setting thats clashing with the PHP?

Original comment by asra...@gmail.com on 22 Jan 2011 at 6:11

GoogleCodeExporter commented 9 years ago
UNKNOWN ATTRIBUTES:
Array ( [0] => 013E01 [1] => 013E01 [2] => 013E01 ) 

Original comment by elgib...@gmail.com on 22 Jan 2011 at 6:12

Attachments:

GoogleCodeExporter commented 9 years ago
#37 - The host running the script has to have the right support installed and I 
doubt a generic shared hosting service like GoDaddy would have all the 
requirements. In any case, put the following line at the top of your scripts 
and then execute them. it will help you troubleshoot the problem:
"error_reporting(E_ALL ^ E_NOTICE);"

Original comment by elgib...@gmail.com on 22 Jan 2011 at 6:19

GoogleCodeExporter commented 9 years ago
39 - I wondered if this might be the issue :( 

I'll put that at the top of each script and report back.  So far, with it at 
the top of upload_file.php, it reports nothing...

Do you have any idea, or could you suggest, what I need to do with my generic 
hosting to GET the requirements?  Using XAMPP on localhost it works fine

Original comment by asra...@gmail.com on 22 Jan 2011 at 6:28

GoogleCodeExporter commented 9 years ago
UNKNOWN ATTRIBUTES:
Array ( [0] => 030222 [1] => 030222 [2] => 030222 [3] => 030222 [4] => 030222 
[5] => 030222 [6] => 030222 [7] => 030222 [8] => 030222 [9] => 030222 [10] => 
030222 [11] => 030222 [12] => 
That's a snippet, the entire block went past the length of the page.

Original comment by elgib...@gmail.com on 22 Jan 2011 at 6:29

Attachments:

GoogleCodeExporter commented 9 years ago
#38, #41: These are 1.1.3 replays. Although that probably means it is broken in 
1.2.0 as well. Anyway, thanks; I will fix these in my next commit. 
Might be better to keep these in a separate issue, if there are more.

Original comment by zsol.z...@gmail.com on 22 Jan 2011 at 10:57

GoogleCodeExporter commented 9 years ago
Just released 1.40, which fixes all of the above.
Closing this issue. Thanks for all your help!

Original comment by zsol.z...@gmail.com on 22 Jan 2011 at 10:02

GoogleCodeExporter commented 9 years ago
In reply to #37 - 

I have the exact opposite issue. Doesn't parse correctly on localhost but works 
fine on my server. Localhost is Windows 32bit, server is Ubuntu 64. I wonder if 
the issue is the architecture? The parsing used to work fine on the Windows 
until one of these recent releases so I know it's not a setup/permissions issue.

Original comment by david.w....@gmail.com on 24 Jan 2011 at 5:10

GoogleCodeExporter commented 9 years ago
Hi, thanks all afaik it's all working for me. fwiw works locally for me on 
windows 7 64bit pro and also on my host hostgator

Original comment by forelma...@gmail.com on 24 Jan 2011 at 8:03

GoogleCodeExporter commented 9 years ago
Hmmm, weird! Tested this replay from SEA server 2 times at my site and at 
http://blissenobiarella.dyndns.info/~zsol/phpsc2replay-main/ and in both cases 
got 1 race undetected.

Original comment by YellEl...@gmail.com on 24 Jan 2011 at 8:12

Attachments:

GoogleCodeExporter commented 9 years ago
This replay does not get the races correctly for me in 1.4.0.

Thanks!

Original comment by tehels...@gmail.com on 25 Jan 2011 at 12:20

Attachments:

GoogleCodeExporter commented 9 years ago
Thanks for reporting guys, 
http://code.google.com/p/phpsc2replay/issues/detail?id=44 is created for the 
above two.

Original comment by zsol.z...@gmail.com on 25 Jan 2011 at 6:30