Handle GameHeart games about spawningtool HOT 14 CLOSED

Oooh I am interested in this too, I have had a few requests to be able to handle GameHeart games.

from spawningtool.

Sounds good. I'll take a look at the exact replay data soon and see if there are cues in there that we can use. If there aren't, I'll reach out to the gameheart developer and see if they are open to throwing in some events that we can use as markers.

from spawningtool.

I took a look at a gameheart replay and compared it to a regular replay. For the most part, things look pretty similar, unfortunately. Most of the detail I managed to find was in the game events, both regular and tracking. Here are possible differences:

1. This gameheart map has "GH" in the map name
2. There's a "ApplyVision" unit born event that occurs when the game "starts" at ~34 s
3. The initial building and workesr aren't created in a unitbornevent at time 0. They're created later
4. There are a bunch of PacketEvents that happen in the interim

I think the best bet (at least for spawningtool) is to look for the Nexus/Command Center/Hatchery event, then start the clock from that frame. If that happens to not be 0, then we're looking at a custom lobby (gameheart or not; I know, for example, Proleague uses an ingame lobby) and we should also remove all of players without any actions from the game.

So a few questions:

1. does the above seem like a reasonable strategy?
2. what are the packetevents about? (fingers crossed that @GraylinKim is watching and will elucidate everything)
3. do you think it makes sense to reach out to the gameheart developer and ask them to drop some hints in for us?

from spawningtool.

Seems reasonable. I'm not 100% sure that removing all players without actions is sufficient -- non-players may be able to take certain actions such as minimap pings? The rest sounds likely to work.

from spawningtool.

That's a good point. Maybe a better heuristic is just to see which players get a Nexus/CC/Hatchery, and then ignore anyone who doesn't.

One more thing I just remembered. There are some games (http://spawningtool.com/1781/) where I didn't get a winner. I haven't investigated this case, but here's my theory: the parsed data thought that the other GH game was a 4v3, so observers ended up getting a win if their player won. My guess for when there is no winner is that both players ended up on the same team. I'll need to look more closely at the game, but we might need a workaround to find the winner as well.

from spawningtool.

what are the packetevents about?

I'm not sure what packet events are about. They are game related messages sent between the game clients. No idea what their purpose would be though.

fingers crossed that @GraylinKim is watching and will elucidate everything

You should be aware that not all game events are inserted into the replay.game_events list. In particular, any event with None for the event_class in the reader.EVENT_DISPATCH won't get inserted into our game event list. As such I believe that thereare almost certainly more game events that you could use here.

I'd poke around the replay with the s2protocol tool to see which events are useful and add event class for them in sc2reader. The dialog events, for instance, might be useful here if the game admin has to click a button to start the game.

There are some games (http://spawningtool.com/1781/) where I didn't get a winner.

This replay (on sc2reader@master) shows all the players on the same team. I would expect that in addition to doing extra work to figure out a winner that you'll need to do extra work to figure out the proper teams.

I would implement this as a GameHeart plugin that steps in and corrects/adds/modifies replay values before passing things back to the user.

from spawningtool.

@GraylinKim , you are a wealth of information. Thanks a ton for hopping in the thread.

I looked through the s2protocol events, and there are definitely events that aren't being registered. They mostly look like

{'_bits': 120,
 '_event': 'NNet.Game.STriggerDialogControlEvent',
 '_eventid': 55,
 '_gameloop': 140,
 '_userid': {'m_userId': 4},
 'm_controlId': 184,
 'm_eventData': {'SelectionChanged': 1},
 'm_eventType': 3}

I wish I could make that useful somehow, but I guess it only confirms that the admins are doing something in the meantime.

Doing it as a plugin seems the best; that way, @dsjoerg can also benefit from the work. Off the top of my head, the things I would want to do are

1. change all frames to be relative to the actual "game start"
2. mark observers as observers
3. realign the teams (if they can be determined)
4. figure out who won (contingent upon 3)
5. remove all events prior to the "game start"

Does that sound about right? I feel like this is absolutely going to cause some strange inconsistencies (e.g. game start + game length != game end), but that should be a well-understood caveat.

Is there anything else that would be missing?

Also, are you accepting plugins as pull requests, or should I gist it?

from spawningtool.

Is there anything else that would be missing?

Players can probably choose their race in-game prior to starting if they have an in-game lobby. Players also might be able to create events (camera movement?) prior to the "start" of the game. I think those events should be removed from the event lists.

Also, are you accepting plugins as pull requests, or should I gist it?

Pull request is fine.

I wish I could make that useful somehow, but I guess it only confirms that the admins are doing something in the meantime.

Unfortunately I don't know how to interpret dialogue events very well. It may very well be something that can't be useful without running the galaxy script. If the dialogs are always created in the same order though, you could probably figure out which controlId maps to which dialog manually. I think watching for dialog events would be the "correct" way to figure this out.

Maybe a better heuristic is just to see which players get a Nexus/CC/Hatchery, and then ignore anyone who doesn't.

This might be the best strategy though. You could use this information to determine when the game starts, who is playing, and what race they are playing. It would likely be simpler than figuring out how to interpret the dialog events.

from spawningtool.

A foolproof way to determine if a replay is a game is a GameHeart game (as opposed to another in-game lobby mod) is to inspect the map dependencies from the SCMap.DocumentInfo xml document. If GameHeart is listed as a dependency the are using it.

<?xml version="1.0" encoding="utf-8"?>
<DocInfo>
    <Icon>
        <Value>UI_Arcade_GameHeart.tga</Value>
    </Icon>
    <Dependencies>
        <Value>bnet:Swarm (Mod)/0.0/999,file:Mods/Swarm.SC2Mod</Value>
        <Value>bnet:Swarm Multi (Mod)/0.0/999,file:Mods/SwarmMulti.SC2Mod</Value>
        <Value>bnet:GameHeart - Dreamhack/1.2/176307</Value>
    </Dependencies>
</DocInfo>

I was just poking around map files at lunch and noticed this. Might be useful but will require that the map for the replay be downloaded. I'll add DocumentInfo information to the sc2reader Map object soon.

from spawningtool.

StoicLoofah/sc2reader@c88e687

Alright, here's take 1 on a plugin. I'm not really sure what process you prefer to do your code reviews in, but this isn't quite up to code review level yet. At the very least, I need to scrub out all of the debugging code.

It's pretty sloppy overall in that it assumes that people aren't trying to abuse the structures in the first place. @dsjoerg , if you see anything that might give you trouble, let me know. @GraylinKim , if you see anything that you think I haven't addressed, that would also be good to know.

from spawningtool.

Github should add a Like button so I can Like this commit.

from spawningtool.

The pull request into gameheart was just accepted into sc2reader, and we should be good to go with the newer version. When the next version of sc2reader is released, I'll bump the version in setup.py and close this ticket then.

from spawningtool.

The GameHeart plugin is also enabled by default now.When you update the code GameHeart should automatically start working.

from spawningtool.

Fixed by bumping sc2reader requirement to v0.6.0 f20cd74

from spawningtool.