Yep, assuming again that building->id is a static (the same) number for all corsolar├óÔé¼Ôäós being built. Your implementation is spot on
AF wrote:
This would eb an ideal solution because threading isnt the only delay were this could occur, ti could occur while the units enroute to the construction site.
Are u saying that the second solution might work
Also another assumption I made: I thought that the solobuild element was pushed to cache, when the GiveOrder was executed (command pushed to queue). And NOT waited to push solobuild (to cache->solobuild), until the construction unit had reach the construction site.
solobuild/singlebuild etc are updated when the construction starts.
So, I have updated cubuild to check plans aswell. This should solve the problem nicely although it may be a performance issue.
I've also changed the way the matrix is depreciated so it depreciates mroe often and added in distance as requested factoring by DJ. The way efficiencies has been calculated initially for first tiem learn files has changed to greatly increase the values of resource producers, especially top tech producers, a fusion producing 5k will have an extra 10k added ontop of its efficiency aswell as its Unitdef::power value. Mexes arent affected by this change as much yet.
I tried making it add the average damage dealt to the value instead fo power for wapons but that failed terribly as theres a missing value from the interface AIs cant access. DamageArray:Numtypes (as far as I'm aware).
Tried NtaiLALE.rar in respect to factories.
When solobuild=corstorm; and corlab=corstorm;
The corstom will be produced by several factories in parallel.
I├óÔé¼Ôäóve tested this with upto 30 factories running in parallel.
Do factories use the build-placement-algorithm? (thread?):?:,
If not then a ├óÔé¼┼ôsmall conclusion├óÔé¼┬Ø must be that the solobuild issues, must also happen without build-place-algorithm OR the mobile constructors travel toward the construction site.
--------------------------------
The new ├óÔé¼┼ô74├óÔé¼┬Ø build introduces heavy stutter each time a constructor is trying to build a new unit (target).
- This happens regardless if target is in the solobuildlist (in config file) or not.
- This does NOT happen for factories.
(I have not tested the new thread matrix improvments yet) Update: post update in respect to better test with factories.
it calls ubuild okbuild selection on each iteration of the build algorithm loop.
Factories calling the build algorithm thread for a position would be a huuuuuge bug. I spent a lot of time getting this right with hubs normal building and factories when the algorithm was first written. After all you don't need it, the position of the factory will do.
With factories the only delay would be between when the command is issued and when it is passed through the engine and executed.
The attacking looks to be better in this build but as lale says there is a stutter when looking for a build site which is preventing me from really testing this as the game becomes un-playable
Is there any way to control what is built according to metal production as well as energy production? In some ways this would be more useful as you can be reasonably sure how your energy economy will progress but metal is heavily dependant on the number of metal spots and the number of players in the game
If anyone can spare some time to point me in the right direction about what they are for then I'll write a guide.
Being able to set build rules by Metal production would be massively useful, if you can look into it that would be fantastic. I realise you've got alot on so if you want me to do the toolkit side of it I can. If there's any enhancements to the toolkit that people would like I could also do those at the sametime. Was thinking of a search/filter on the units list for one thing.
The new build works without hiccups.
Solobuild and singlebuild seems improved, but not perfect.
DJ:
Build rules by Metal production is useful. But has some pitfalls that are important to realize, before applying:
1) If you use metal-P as rules for upgrading (to L2), the balance will change dramatically if your config is played on a metal map vs. a metal poor map. (energy prod. is not affected by maptype)
2) If no meta makers are available, then maps with little metal will have to be considered when making config file limits on metal-P. (energy prod. is not limited by map resource)
3) With metal makers, the usage of metal-P, is translatori. Eg. 1u metal for 60u energy.
4) Metal-P limiting can lead to a permanent energy and metal stall condition. This can happen because moho mines and metal makers shutdown if not enough energy is present. (This does not happen for energy-P limits, as solars do not shutdown during energy stall)
Of cause I realized that the above also makes arguments for having metal production limits in NTAI config file. But so fare my configs have done surprisingly well without
Open question:
If both methods is used within a config file, should the behavior be AND or OR eg.:
Corsolar limited due to E-min AND M-max
Or
Corsolar limited due to E-min OR M-min.
1) If you use metal-P as rules for upgrading (to L2), the balance will change dramatically if your config is played on a metal map vs. a metal poor map. (energy prod. is not affected by maptype)
That's what I'm hoping will happen, in general I've not really tested on metal maps but when i did it recently that's when i thought that metal rules would be useful because you want to be able to tech up earlier in these instances. I understand your other points but i was merely suggesting the option of having a metal rule. For instance you don't want to even consider going to level 3 unless you have a massive amount of metal, on metal maps this can happen... To be fair for NTai to work well on metal maps there would have to be some build spacing enabled for metal extractors. As AF hates metal maps as much as me I think you'll be lucky if he does any work to help with them.
If both methods is used within a config file, should the behavior be AND or OR Question eg.:
Corsolar limited due to E-min AND M-max
Or
Corsolar limited due to E-min OR M-min.
I don't hate metal maps, I just hate terrible maps. I quite like speed ball and metal heck v2, but metal heck v1 has horrible speed modifiers that unbalance the game, and speed metal is a terrible map that also has unbalancing speed modifiers.
Having said that metal rules have their uses, and just like energy rules can cause stall conditions if used incorrectly. Also overuse can lead to many states.
As a side note, can someone start a new thread and post a config in ti regardless of how well it plays, and everyone else follow suite? Because while you lot are discussing the tuning of your configs, the player base is ditching NTai because they have to build a config themselves to play it.
If only as a sign of goodwill to show people that progress is being done. The player base want something to play, they want results, and I think they'd rather play a config that pwns at arm but doesn't support core, than play a weak AI that does both.
released a BA config for people to test with, AF could you wrap the latest NTai build in an installer of some kind for people? It seems like a really solid build and works well
Does NTai allow to have several configs per mod (or several mods per config?) Does it allow the same for specific mod+map combination? E.g. ivory's config for xta on CC/CC redux and someone else's for xta on small divide?
that would be useful for making sea map and air battle configs for mods too. i reckon my config will play small divide ok, but its lack of clever defence placement means NTAI will never be good at "rush popup/gaurdian" maps