chronoboost commandevents unlabeled

[StoicLoofah]

I got a report that Stats's Warp Gate was too early in this replay by about 10 seconds

https://lotv.spawningtool.com/45980/

I looked at the replay and code, and it appears that spawningtool couldn't find the chronoboost events with this logic (that has worked int he past)

https://github.com/StoicLoofah/spawningtool/blob/63ead0cf9ed126068e18d906307b1ff303a77a57/spawningtool/parser.py#L476-L478

I thought it might be a data issue, so I went through and exported new balance data to capture events

https://github.com/ggtracker/sc2reader/blob/upstream/sc2reader/data/HOWTO.md

but I noticed that only "Wings of Liberty" was an export option, and the abilities file that I could generate was only 186 lines long (whereas the last one was 408 lines long) https://github.com/ggtracker/sc2reader/blob/329e044fecda0b6c090bdc16568314b8ae752bbc/sc2reader/data/LotV/70154_abilities.csv

and it was indeed missing chronoboost.

I guess my first ask is whether someone else can try the export process in the doc above to see if you can get more results than I can.

If not, then I'm open to ideas about what went wrong and how we fix this

[Talv]

This is caused by SC2Editor's license verification system. It's relatively new thing, but incredibly annoying, and equally stupid. It affects all capabilities of SC2Editor - it's not possible to open/create sc2maps which are based on HotS/LotV dependencies etc.

To authenticate you've to login to the battle.net through the SC2Editor (Battle.net App / SC2 client have no relevance here). Easiest way to do so, is to navigate to File -> Manage published - this window will allow you to sign in. Enter your credentials, and be sure to pick correct region (US works fine) - sometimes leaving this field empty glitches SC2Editor even further.

After logging in successfully you should be able to access previously hidden menu actions to export HotS/LotV data. If however it will still not appear, then you'll need to force it by opening up a new editor module (sub-window), for instance Overview manager and close previously active one - on default settings it would be Terrain module).

Newly opened window should have the same set of actions under primary File menu action. All balance exporting options are expected to show up.

Restarting application is an option too - authentication info should be stored offline for about ~30 days. But there have been a lot of problems regarding that as of recent, so I'd not relay on it.

Dropping in required files:
sc2-balance-lotv-76114.zip
sc2reader-data-patch.diff.zip

Also, yes - ability ID of Chrono has changed: 709,ChronoBoostEnergyCost vs 716,ChronoBoostEnergyCost. But there's a lot more - every balance patch pretty much always puts things out of order.

[StoicLoofah]

Oh, looks like a good fix. It worked at least for a new replay. The original replay in question, however, doesn't appear to work, though that presumably is because its version is 72282. Maybe I should look this up myself, but is there any way of dumping balance data from further back as well?

I'll open a PR for this right now

[Talv]

Maybe I should look this up myself, but is there any way of dumping balance data from further back as well?

To my knowledge this isn't possible. At least not through SC2Editor. Even with access to past builds of SC2 I haven't been able to export balance data. I was asked to authenticate as usual, but server denied the access due to miss-matching version.

So long there isn't another way to dump balance data for old versions I'd recommend using 76144 data for any replay equal or newer than 71663 - it's when Blizzard released BU (https://liquipedia.net/starcraft2/Patch_4.8.2). Which most likely shifted some ability IDs.

It should fix the issue with replay linked in first post. At least in regards to Chrono Boost - ability_link matches the one from 76144 build.

{"_eventid": 27, "m_unitGroup": null, "_event": "NNet.Game.SCmdEvent", "m_abil": {"m_abilLink": 716, "m_abilCmdIndex": 0, "m_abilCmdData": null}, "_gameloop": 1429, "_bits": 264, "m_data": {"TargetUnit": {"m_snapshotControlPlayerId": 1, "m_snapshotPoint": {"y": 112640, "x": 493568, "z": 49136}, "m_snapshotUpkeepPlayerId": 1, "m_timer": 0, "m_targetUnitFlags": 111, "m_snapshotUnitLink": 81, "m_tag": 50855937}}, "_userid": {"m_userId": 0}, "m_cmdFlags": 256, "m_sequence": 204, "m_otherUnit": null}

[StoicLoofah]

Good analysis! Probably a good idea, but I'm going to be lazy and leave the data as is. It is probably less correct, but at least it's out-of-date in a consistent manner with old updates.