SC2Mapster

SC2 automatically records replays which often provide critical insight on bugs and weird behaviors with Take Command for interactivity, but generally changes the game since other players are ejected. We could prevent those changes if the Take Command action were detected and even permit debug mode for better troubleshooting. Does anyone know of a way to detect Take Command (either in Triggers or Galaxyscript)?

Unable to load wizard file 'base.sc2data\Wizards\UnitCreation.BlizWiz' (Core: file not found) (Core: file not found): base.sc2data\Wizards\UnitCreation.BlizWiz

Same warnings here; the Unit Creation / Unit Modification wizards appear to be patch 3.3 dependencies, but not distributed with the patch (at least some of the time).

USER: [ 8a4 1] CActorDoodad[PathingandSightBlocker2x2Doodad] Model produces empty (zero) bounds. Consider using DefaultToModelAABBBounds to fix.

This appears to be a misconfigured patch 3.3 bug/warning message; I get the same warning for CActorDoodad[Decal] (unmodified Wings of Libery Actor/Model). The SC2 standard Decal Actor uses DefaultToModelAABBBounds by default, but disabling it resolves the warning (opposite what the text recommends). This is potentially a non-issue either way; the Axially Aligned Bounding Box is likely just used for object collisions.

I'd suggest disabling/unchecking the "Default to Model Bounds" under Actor > (Basic) Actor: Doodad Flags in the data editor for the PathingandSightBlocker2x2Doodad Actor. Alternatively, in xml:

<CActorDoodad id="PathingandSightBlocker2x2Doodad">
  <DoodadFlags index="DefaultToModelAABBBounds" value="0"/>
</CActorDoodad>

Uploads to Americas region appear to be working normally again; thanks!

@TyaArcade: Go

We've experienced substantial performance hits as well; I didn't imagine it was due to map size (256x256), but will test.

Quote from kelsonTD: Go

I've verified that our map uploads only fail on the "Americas" region; upload was successful in EU, KT, and SEA. That seems to reinforce the theory that this is a problem with Blizzard's infrastructure instead of the maps themselves.

It appears Blizzard is working the problem; map uploads in the Americas don't always fail anymore, but instead hang indefinitely (30+ min so far).

edit: For clarity, uploads to EU, KT, and SEA still work without any problems.

edit: error text "There was a temporary error with your request. Please try again in a few minutes." (for 48+ hours)

Quote from sandround: Go

Has anyone been able to publish their maps since 3.0? I've tried since yesterday, it just stops and won't publish any maps.

The only maps that can be published, creating a brand new maps seems to work. Or loading up an old map that hadn't been saved, that will publish. Then once I save it again, it won't publish anymore.

edit: actually, some of the older maps also won't publish. one did publish though until I saved it again...

Nevermind! Seems I can still publish to the korea region, I'll just move my maps there.

I've verified that our map uploads only fail on the "Americas" region; upload was successful in EU, KT, and SEA. That seems to reinforce the theory that this is a problem with Blizzard's infrastructure instead of the maps themselves.

Extending on my previous post, we're seeing a substantial number of our past map versions (and modified recent versions) causing apparent crashes in Blizzard Arcade upload infrastructure (unACKed TCP messages at 77% or 88% upload followed 5s later by RST packets). Not clear what is causing the crashes right now; our assumption is an issue in their MPQ extractor or something to that effect.

I've observed the editor randomly inserting a unicode FEFF (\xEF\xBB\xBF) at the start of LocalizedData/ObjectStrings.txt. It doesn't appear to cause any errors, but thought it might deserve additional investigation.

rewritten in later post

Units/Commands "float" over low terrain

Pitfall: Units and commands on terrain height <= 8 "float" above the ground. Shadows are disconnected and move actions don't match cursor location.

Solution: Increase terrain height

Manually increasing terrain height across an entire map is impractical, but it can be directly increased in t3Terrain.xml (change heightMap offset). This creates problems with any objects or doodads which remain at the previous level (ie, underground). I wrote a quick python script to update all objects by a fixed amount; it seems to have worked fine on test maps and an active arcade map, but please feel free to message me if you experience any issues with it.

edit: Just to be explicit, the script is intended to update the "Objects" file.