Unable to use the "seek" runner about clarity-examples HOT 8 CLOSED

Hey, it might be a bug, but it smells like corrupt replay data, especially because the tick example crashes as well. Can you provide your replay file in a dropbox or sent to [email protected]? Can you post the exception you get from the tick example?

from clarity-examples.

Thanks for a fast reply, @spheenik !

I've uploaded the replay here.

The last tick it prints info about is 7284:

15:57:05.373 [main] INFO java.lang.Package - tick 7284, synthetic true, had 0 messages

And then the exception is thrown:

---START---

Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
at skadistats.clarity.event.Event.raise(Event.java:25)
at skadistats.clarity.processor.runner.AbstractFileRunner.initAndRunWith(AbstractFileRunner.java:23)
at skadistats.clarity.processor.runner.SimpleRunner.runWith(SimpleRunner.java:36)
at skadistats.clarity.Main.run(Main.java:45)
at skadistats.clarity.Main.main(Main.java:62)
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
at skadistats.clarity.event.Event.raise(Event.java:25)
at skadistats.clarity.processor.reader.InputSourceProcessor.processSource(InputSourceProcessor.java:170)
at skadistats.clarity.event.AbstractInvocationPoint.invoke(AbstractInvocationPoint.java:72)
at skadistats.clarity.event.Event.raise(Event.java:23)
... 4 more
Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
at skadistats.clarity.wire.Packet.parse(Packet.java:36)
at skadistats.clarity.processor.reader.InputSourceProcessor.processEmbedded(InputSourceProcessor.java:246)
at skadistats.clarity.event.AbstractInvocationPoint.invoke(AbstractInvocationPoint.java:72)
at skadistats.clarity.event.Event.raise(Event.java:23)
... 7 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at skadistats.clarity.wire.Packet.parse(Packet.java:34)
... 10 more
Caused by: com.google.protobuf.InvalidProtocolBufferException: Message missing required fields: type
at com.google.protobuf.UninitializedMessageException.asInvalidProtocolBufferException(UninitializedMessageException.java:81)
at com.google.protobuf.AbstractParser.checkMessageInitialized(AbstractParser.java:71)
at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:124)
at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:129)
at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:49)
at skadistats.clarity.wire.common.proto.DotaUserMessages$CDOTAUserMsg_ParticleManager.parseFrom(DotaUserMessages.java:44915)
... 14 more

---END OF EXCEPTION---

from clarity-examples.

I fixed the bug with the seek example, by reverting a recent commit that did not work correctly.
I am still not sure what the problem is with the tick-example, it looks like corrupt data, the real client plays the file without problems though. Still investigating...

from clarity-examples.

@invokr: Fails to read a CDOTAUserMsg_ParticleManager at tick 7284, but dota client plays back the file without problems. Can you check if you can read it?

from clarity-examples.

"[libprotobuf ERROR google/protobuf/message_lite.cc:123] Can't parse message of type "CDOTAUserMsg_ParticleManager" because it is missing required fields: type"

Which repeats a 1217 times throughout the replay. The rest of it parses fine though.
Valve probably screwed up something regarding their protobufs.

from clarity-examples.

or maybe the field is not required anymore?

from clarity-examples.

I just tried setting it to optional, and now the replay parses.

The protobuf docs say: "A well-formed message may or may not contain an optional element. When a message is parsed, if it does not contain an optional element, the corresponding field in the parsed object is set to the default value for that field."

So, one could say, it makes no sense to define a default for a required element, since you have to supply it anyway. It makes much more sense to define a default for something optional. Which is what Valve corrected, I assume, but it did not show up in GameTracking' dumps yet.

from clarity-examples.

fixed in clarity-protobuf-4.1

from clarity-examples.