search

eronoobos / BABAR-The-Shardifant

Balanced Annihilation & Balanced Annilhation Reloaded configuration for Shard
2 stars 1 forks source link

Swittch to new FactoryBuildersHandler #43

Closed pandaro closed 8 years ago

pandaro commented 8 years ago

a lot of work to do but if you want merge to manage... but is not ready to stable

eronoobos commented 8 years ago

okay. keep the pull request open and i'll merge when i have time to work on it

pandaro commented 8 years ago

another problem: calculating a best factory before build it give us the problem that another unit can build over this area, if append, builder stuck so we need to reserve this area and on unit create remove the reserved area or ... calculate the factory on demand

pandaro commented 8 years ago

so cause i have already change the approach to this work (gaining a bit of experience) i will block this pr

eronoobos commented 8 years ago

cool

i forgot to say: i think that calculating the best factory (actually, just its position) on demand (when taskqueuebehaviour asks for it) is a better idea than reserving areas. if your new approach makes this feedback irrelevant, don't worry about it

pandaro commented 8 years ago

no no! please well come brainstorming!

eronoobos commented 8 years ago

ok, my thinking about the problem:

1) Keep a list of the types of construction units we have, and check whether to add/remove from it when a unit is built/dies. counthandler might already do this, I'm not sure.

2) Keep a list of all types of factories we can build, and add/remove from it when a new construction unit type is built, or all of one construction unit type dies

3) Among the factories we can build, decide which is best, regardless of where it can be built. I think this can be done by just iterating through ai.factoriesRanking until there's one that we can build and haven't yet built. Re-calculate the best factory only when the list of factories we can build changes, a new factory is built, a factory dies, or ai.needAdvanced or ai.needExperimental changes

4) When a construction unit (through taskqueuebehaviour) asks whether and where to build a factory, first check if that construction unit can build the current best factory. if not, disregard it. If it can build the best factory, then find a position for that factory and return it

I feel like i'm forgetting something, because the scheme sounds fairly simple

Edit: Ah yes:

4-A) Only go through with finding the factory position if the economic and strategic situation calls for building a new factory (ai.needUpgrade? + some kind of metal & energy check. the metal & energy check could be dependent upon what type of factory the best factory choice is.)

pandaro commented 8 years ago

i agree, your schema is more or less my idea, i have only a question: in my system, before new factorybuildershandler, shard was able to handle a particular case: in map that have 2 great area of water divided by ground, shard don't delete a factory simply because he have already build, so give he the capability to build the same factory in two non-contiguous area of map. yes this is a very ... unlikely things but, what you think? is totally useless or partial usefull implementing this?

eronoobos commented 8 years ago

That's a good point.

Maybe the way to catch such cases is to check for an already built factory per mobility network of that factory (which is what ai.factoryBuilded is, I think?). The trouble is, that opens a can of worms of needing to know where to place the factory before it's possible to evaluate whether to build it at all. Some shortcuts are possible, though. For instance: iterate through each mobility network of the factory's mtypes, and check whether we have any units in those networks. If we have units there, it's probably an okay area to build a factory. And then of course the position-finding algorithm needs to limit itself to that network.

A related but slightly different extreme case that comes to my mind is Lava Reef, where a kbot factory is useful because it's far more resource-efficient, but totally useless for attacking the other side of the map. That might be solved by carefully tweaking the mtype efficiency modifiers. Edit: and such a factory would need to know not to build any ground combat units.

eronoobos commented 8 years ago

@pandaro are you working on this? i want to update BABAR to https://github.com/Tarendai/Shard/pull/108 but i don't want to cause merge conflicts for you

pandaro commented 8 years ago

im working hard, status is 75% ready for an initial release(hope) ready in the weekend ok? you can find the solid things at myfork/testing

eronoobos commented 8 years ago

ok cool :-)