Thanks for the new release! Sorry to always do this right after a new one, but I found another issue
Not sure if this one is intentional, but by default each bot has a zero unit occupancy at each node in their territory exerting some pressure. Once another bot takes over the territory though, that zero-unit occupancy remains and doesn’t get transferred to the new territory owner. This means that even if you now own that territory node, you can’t leave it because the other bot still has some pressure there and will take it back once you have no units there.
Kind of makes it hard to clean up after the pillaging.
Yeah, @kobus-v-schoor, this one is more by design. The idea here is that each occupant group has an inherent pressure based on its proximity to the base. As soon as that area has been visited, it gets some legacy of ownership that remains after the fact. This is partly to keep territory dynamic and not easily maintained. The other side of this is to give smaller bases more pressure when occupying land that is very close to them, stopping bigger bots from swamping the territory of those smaller.
Thanks for the release! Unfortunately still got a crash in CreateLand with containedNode being null. Maybe the null check should be done before using containedNode.Id in the Land constructor?
Also, I don’t have the best grasp of what is going on in the engine code, only started looking at it a day or two ago. Do you know why containedNode would be null so rarely, and whether just returning out of the function in the null check would be messing other things up and causing any disadvantages/other weirdness later on?
EDIT: yep swapping the null check allowed me to run to tick 2500 (for the first time)
Thanks @TianCilliers you make a very good point. We should have checked deeper, that’s our bad. We’ll update the release tomorrow
Honestly, I’m not entirely sure what the fallout of not creating a land object would be… I assume there would just be a specific node that couldn’t be claimed when expanding territory with buildings.
A quick question, have you noticed anything special, unique or specific about the position whenever a containedNode is null? I’m wondering if it’s not a scout tower position sneaking through…
Thanks! In retrospect, it’s not impossible that I was trying to build on scout towers, but that should have been caught by the checks in BuildActionHandler so I doubt it is the problem. I’ll play with it a bit and see if I can figure out exactly what build action causes the issue (if it is deterministic)