Why does shard so enjoy building in little tiny grids?

[Forboding Angel]

On an entertaining note, ntai did the same exact thing.

The attached shard is for spring 94.1.

[AF]

Its spacing and the engines closestbuildsite api, any and all AIs that relied on it had the potential for this to happen. It doesn't help that spacing is not at all what you think it represents ( 5 units means 5 footprints of the desired building, not 5 elmos or 5 pixels, so the same measurement means wildly different things depending on which unit you're building )

If you look at darkstars and the shard thread you'll see my thoughts on a new building placement algorithm in Shard

[Forboding Angel]

Ouch, that sucks.

I'm guessing that getting it fixed in the engine is a lolworthy endeavor?

[smoth]

af couldn't you convert footprints to elmos?

[yuritch]

From my experience messing with Shard building placement (see Shard for NOTA), spacing seems to be in some fixed units, not in building footprints. Maybe it's just because most buildings in NOTA are of similar sizes.

There is some strangeness going on with Shard and buildings, it seems sometimes Build() can return true without actually starting construction, so the unit sits there doing nothing (it has no active orders visible from spectator view) until my 'watchdog timer' code finds it. I suspect maybe it gets off-map coordinates for build location, so the order is not drawn and nothing is built? It's quite hard to debug this from lua side, as I have no access to unit's current order from Shard lua.

[AF]

af couldn't you convert footprints to elmos?

Several times I have tried, the results where significantly underwhelming, and probably not what I expected due to the way the algorithm works. I currently have code that looks at the biggest footprint length and tweaks the spacing values but while thats an improvement it's far from satisfactory, and in most cases it needs fine tuning on a per building basis anyway, as a consistent spacing value isn't the most optimal situation even if it's reliable

I'm sure if I sat down one afternoon I could write a lua based algorithm with a grid that relies on canbuildhere callouts. The problem then would be a tradeoff between performance vs accuracy, which i'm sure can be solved. My first experiments in NTai either worked flawlessly while melting the CPU, or worked well but would have people complain it missed an utterly obvious spot in tests, so I never invested too great an amount of time. All solvable problems still.

If someone feels like giving it a go, it's perfectly doable with the Shard already out there in pure lua. You could probably steal the algorithm wholesale from on of the lua gadget AIs with a handful of search replace changes even, which is likely what Ill do if I get some time this week to nose about in it.

As for closestbuildsite, thats unlikely to ever be fixed. It's more likely to be removed than fixed. It was never intended to be a reliable effective building placement algorithm, just a 'whats the nearest buildable spot from me?'

[AF]

In particular, here's CAIs algorithm:

https://code.google.com/p/zero-k/source ... AI.lua#614

local searchRange = 40

Code: Select all

local x = ux + math.random(-searchRange,searchRange)
local z = uz + math.random(-searchRange,searchRange)
		
while (spTestBuildOrder(defenceDef, x, 0 ,z, 1) == 0 or not IsTargetReallyReachable(unitID, x, 0 ,z ,ux,uy,uz)) or nearMexSpot(x,z,60) or nearFactory(team,x,z,200) do
	x = ux + math.random(-searchRange,searchRange)
	z = uz + math.random(-searchRange,searchRange)
	searchRange = searchRange + 10
	if searchRange > 400 then
		return
	end
end

Which is a lot simpler than I thought it would be

There's also:

https://code.google.com/p/zero-k/source ... AI.lua#814

and

https://code.google.com/p/zero-k/source ... I.lua#2479

General rotate around a point at a radius till you find a position, increase radius if you found none, abandon if radius reaches limit