Joshua-Leibold
commented
1 year ago File with an obstacle course illustrating worker-only paths for testing: WorkerOnlyPathObstacleCourse.zip Note: this file uses the live game's vespene geyser footprint, not the suggested adjustment
XML Changes:
Worker Inner Radius Changes:
<CUnit id="Drone">
<InnerRadius value="0.3125"/>
</CUnit>
<CUnit id="Probe">
<InnerRadius value="0.3125"/>
</CUnit>
<CUnit id="SCV">
<InnerRadius value="0.3125"/>
</CUnit>THE FOLLOWING DOES NOT WORK SINCE YOU CAN'T STOP GAS STEALING WITH IT
Geyser Footprint Standardization:
<CFootprint id="FootprintGeyserRounded">
<Shape>
<Radius value="1.6772"/>
<Offsets value="-0.75,-1.5;0.75,-1.5;-0.75,1.5;0.75,1.5;-1.5,-0.75;-1.5,0.75;1.5,-0.75;1.5,0.75"/>
<Borders value="0,4,2;1,0,2;2,3,2;3,7,2;4,5,2;5,2,2;6,1,2;7,6,2"/>
</Shape>
</CFootprint>
Mapmakers have tried and failed for a long time to invent polished ways of providing players a “worker only” path. Although there are many potential uses like unique scout paths, the separation of scout time from rush distance, pseudo-island bases accessible by ground for workers without requiring manually dropping, emergency escape routes behind bases etc., demand for this mechanic is most required due to the 12 pool. 12 pool restricts maps greatly by forcing natural bases to have exactly one opening of a certain length to make sure players can wall off in time particularly in PvZ and ZvZ. Trying to add even a smaller second opening is very difficult.
NeoHumanity is a perfect example of this problem. The map intentionally tried to get around this to allow more diversification of third base options but like all maps had to choose between blocking the second opening with a rock which would prevent taking the expansion early due to high HP/armor and preventing drones from pathing there uncontested by a reaper, or blocking it with a mineral wall which would allow early expansion but at the cost of making the map turtle-y as the opponent would never be able to open that path up themselves. We all saw how that went.
Past attempts to create worker-only paths have failed because while workers can path through some units that other units cannot while mineral walking, such as eggs which used to be the preferred method, Starcraft 2’s pathfinding engine will cause non-worker units to believe they also can pass through units like eggs even when they cannot, causing non-worker units to path incorrectly directly into the eggs and get stuck. This already messy and impractical solution of using eggs was made virtually impossible after a recent patch that reduced the radius of worker eggs so as to reduce the issue of eggs blocking zerg structures, as the newly reduced radius allows fast and small units to squeeze through what should be an airtight choke due to the way collision is handled in-engine. There is also the issue of eggs not having the "Phase" or "Colossus" collision flags set so adepts can shade through these "worker-only" paths and much less relevantly colossus can kite over them.
One possible solution is to simply duplicate the zerg egg unit and apply special properties for mapmakers to these new eggs like increased radius, perhaps even a real 1x1 structure footprint, with flags enabled for stopping things like shading through them.
With the help of the balance council, it may be possible to introduce worker-only paths in a way that allows keeping Zerg eggs the same as they are now. Reducing workers’ collision INNER radius (doesn't affect how units interact with eachother) from 0.375 -> 0.3125 would be a precision change that allows the construction of vertical and horizontal worker-only pathways since this is a small enough value that workers can fit within "half-blocks" of pathing (currently the smallest gap a small unit like a probe or zergling can fit through is a full block).
Worker only paths would look something like this: https://twitter.com/i/status/1697687002571796737
There are four types of ground pathing blockers:
Structures Cliffs Unit-Structures Painted Pathing
Blizzard was kind enough to make the footprint of player-placed structures end at full-blocks horizontally and vertically, meaning there is no case where adjacent player-placed structures can result in a half-block between them. Structure pathing would be unaffected.
Cliffs also end at full blocks horizontally and horizontally, meaning the inner radius change does not affect walling behaviour against them. Cliffs would be unaffected.
"Unit-Structures" is quite a small category when discussing inner radius - it basically just counts mineral fields, vespene geysers, rocks, and Xel'naga towers. There is only one known relevant adjustment to walling in this category: vespene geysers. Vespene geysers that have no Refinery placed on top of them use a different, smaller footprint than one that has a Refinery. This means walling against a pre-built geyser would be slightly different than walling against a assimilator. See here: https://i.gyazo.com/33dbc22a43c804b5e6b5d384f06dfe8d.mp4
One could resolve this problem entirely by simply making both pre-built and regular geyser use the same footprint size. This is what it would look like: https://i.gyazo.com/97e4ed2fe4855008240ec05aeb28cb27.mp4 It's doubtful anyone would even notice this change happenedOne could resolve this problem entirely by replacing the pathing portion of the pre-built geyser's footprint. See future below comments for details. It's doubtful anyone would even notice this change happened
Painted pathing is, of the four categories, the most tricky for this change. Painted pathing is the manual pathing that mapmakers place that don't automatically get placed by cliffs, structures, or units. This is the kind of pathing that we place underneath decorations on the map. In the editor it looks like this: https://i.gyazo.com/8d3878da54c0edf5de7bc816b6276a7d.jpg
The issue with this category is not fixable by the council themselves, but may be small enough to ignore/ be corrected by mapmakers themselves. The issue is that the build grid operates at the full-block scale, and any amount of path-blocking within that full square, however small, will cause the entire block to be unbuildable. This can create unintuitive scenarios where even though the build grid shows a 3x3 structure footprint placed flush with a "red square" on the build grid, workers could still slip in between vertical and horizontal walling (no change to existing diagonal relationship with build grid). Here is an example: https://i.gyazo.com/c872a2c0f656d9dac93c634f2ad4146d.mp4
While it is not particularly common for walls to intersect vertically or horizontally with painted pathing, it does happen. Fortunately, the bases where such minute differences in worker pathing would actually matter like the main or natural tend to already rely heavily on cliff-pathing instead of painted pathing which minimizes accidents. Furthermore, this category of pathing is directly adjustable by mapmakers unlike the other categories which are hard-baked into melee mode. This means the testing and QA process is capable of fixing unexpected pathing by simply converting a decoration-edge to a full block instead of half-block edge, particularly at key locations we already carefully scrutinize over such as the natural walloff. For example, this is all it would take for a mapmaker to fix a natural walloff on a map like 2000 atmospheres.
Pathing correction: https://i.gyazo.com/bbbb426418f4888b6f40be235b64ccf5.jpg https://i.gyazo.com/89f5f7183f863770b16c13f5adf27cde.jpg
https://i.gyazo.com/862c8e81a42159e32edbf2db3eae0ee3.mp4 https://i.gyazo.com/2e07d2cfd32f94d60821a38b76827b8c.mp4