search

eronoobos / ShardSpringLua

gadget for Spring RTS that loads Shard AI as a Lua AI, see https://github.com/eronoobos/Shard
0 stars 1 forks source link

If shard cannot build something in the queue, it stops completely #7

Open ForbodingAngel opened 8 years ago

ForbodingAngel commented 8 years ago

I've tested this quite a lot, and shard will not progress past a failed order, to make matters worse, if an order fails, everything stops until somethings happens to shock it out of it's stupor.

eronoobos commented 8 years ago

what do you mean by failed order? a unit is blocking the build order? and everything stops until what specific things happen?

ForbodingAngel commented 8 years ago

Well lets say the next thing in a comm buildqueue is the make a radar tower, but in walking to his build order location, he gets stuck on a building and can't complete it. Everything will stop.

Same thing if a factory buildpad gets blocked. The queue stops and never restarts, plus it seems to disrupt the build-queues of all other builders as well. If the thing blocking the factory build pad is destroyed, the factory will not start building again, but if you switch teams and give it an order to build something, it will process in it's queue as per normal.

eronoobos commented 8 years ago

i hope this has to do with the recent addition of capturerbehaviour, though i have no idea why it would. otherwise i am baffled, especially since i have never seen this problem before.

ForbodingAngel commented 8 years ago

Nope, this has been something that has happened ever since the beginning. I always figured it was a fluke so I never said anything, but now it's pretty clear to me that it's an actual bug.

FWIW, it doesn't get all bound up in C++ shard, assuming that info is at all relevant.

eronoobos commented 8 years ago

that is extremely relevant info

eronoobos commented 8 years ago

Strange. I just tried to reproduce the problem by blocking a factory build pad with a given unit. The factory stopped, of course, but construction units kept going through their taskqueues. When I moved the blocking unit off the build pad with /godmode, the factory went back to producing more units.

I was testing with the default config, playing BA (not the real BA config). So I suppose this could be specific to Evo's config, somehow. I'll try to reproduce with Evo next time. I just happen to be in Windows atm.

ForbodingAngel commented 8 years ago

Hmm ok I just tested with the latest of everything and it all seemed to be ok... I don't know. I'll keep my eyes open and if I see it again I'll make a vid of it / give the demo (problem is lots of times the demo is worthless cause I'm using git version, which makes recreating something a bit more difficult.

eronoobos commented 8 years ago

I did notice something that may or may not have something to do with the engineers not building anything: units can't be constructed inside control points. That definitely needs to be addressed. I mean, eventually I think the engineers will find a place to build since they're moving randomly around, but it will slow the AI down a lot.

Ya, only a video would work really.

ForbodingAngel commented 8 years ago

Not building inside control points is by design. Building inside them would usher in all sorts of unwanted behavior.

I'll see what I can do wrt video. I'm testing more at the moment.

eronoobos commented 8 years ago

Oops, no, I know it's by design. What I mean is the AI needs to work around that, i.e., not waste its time trying to build inside control points.

It's probably another argument for implementing Tarendai's idea from https://github.com/eronoobos/ShardSpringLua/issues/5.

tomjn commented 8 years ago

What are control points? I see nothing in Shard that would handle that at the moment, if you could normally build there Shard would attempt it, but if a gadget is intercepting those build orders and saying Nope that's a control point, then what's to stop Shard trying it again?

Do we know if Shard is aware that the order was cancelled? If Shard issues a build order, and a gadget prevents it, is the unit idle event fired? If not, then that's what's causing this, it's a fundamental assumption of how spring AIs work that when a unit is idle, the idle event fires.

Otherwise Shard is unaware the unit is idle and assumes it's doing whatever it was last told to

eronoobos commented 8 years ago

Control points are just a gadget, that EvoRTS uses but is made with the idea of other games using it. I'm handling control points at the level of default modules & behaviours right now (module, behaviour). I'm considering making it part of the Shard API, since it's such a common type of RTS gameplay (capture and hold these points for various victory conditions), but because it's not part of the Spring engine, I'm not sure that would be the right place for it.

Good point re: potential taskqueue stalling from the control point gadget intercepting build orders. I think I'm going to make a build location grid module like you suggested, that also avoids control points.