NTai XE10.1b
Moderators: hoijui, Moderators
Spacing seems to be ignored in this build, particularly with factories. Not had a repeat of the crash bug with the logging turned on yet I'm afraid. It behaves very similar to the crash bug that I reported back on August 17th. That crash bug has never been resolved so I'd suggest that now you've changed much of the code you look at the changes you made back then and see which ones still apply now.
In other news using the build previous to August I have now built what I think is a really good config, despite your assertions that anti stall should be turned off I've found it to be a fantastic addition to NTai, also the correct use of the b_rule keywords makes producing a stable economy across different maps and starting values much easier. I'll try write some documentation on the use of these keywords. I also need to send you a patch to fix some bugs I found in the toolkit.
In other news using the build previous to August I have now built what I think is a really good config, despite your assertions that anti stall should be turned off I've found it to be a fantastic addition to NTai, also the correct use of the b_rule keywords makes producing a stable economy across different maps and starting values much easier. I'll try write some documentation on the use of these keywords. I also need to send you a patch to fix some bugs I found in the toolkit.
Antistall is problematic.
In theory the algorithm is a perfect model of spring economics. However spring economics does not follow the intended model, and as such the antistall algorithm works better under OTA than spring, for the same reason people like argh complain springs economics are fundamentally flawed.
As a result the antistall algorithm anticipates a cost and dclares a unit too expensive, but in reality the fixed unit costs that are necessary may not be deductable ebcause all the resources have already been suedfor construction costs, resulting in free resources. Thus the antistall algorithm is deemed to strict and the user complains, and the AI suffers from the flaw.
To combat this new tags were introduced to weight the antistall algorithm to be too strict or too lenient in order to find a compromise. But this lead to a no win situation where the optimum tag value lead to ok behaviour at the price of random fluctuations leading to decisions that were both too lenient and too strict all in the same game.
To deal with this there were 2 avenues.
1: Predict cost based on the past and extrapolate the future economy based on the current direction modified by the weight of the potential construction project.
2: Add other systems to catch the stall event and increase economic competency at a common sense level.
Since a predictive algorithm would be imperfect and would need to be re-evaluated or suffer from unforeseen circumstances such as a unit thatwas reclaiming suddenly stopping and repairing an existing building turning an income into a cost and throwing off the predictions, I decided to take route 2.
To do route 2 I created b_rule, which fitted in with user demand at the time which complained NTai had no intelligence like AAI or OTAI and wouldnt rebuild energy fi tis energy was destroyed. It made sense as it made NTai more adaptive.
However it wasnt enough so b_rule_extreme and the carry versions where introduced. This keyword acted like b_rule but only did so in extreme situations in order to prevent metal leakage or complete nanostall.
So if energy was below a certain set of parameters it would start building energy, or if energy was abundant but metal was not ti would choose metalmakers, if both resources where nearing the upper storage limit and had big surplus generation it'd buildstorage or factories. And if the economy was stable it would just return. That way you could put in lots and lots of the keyword and it would act as a safety net. So much so interpolation was introduced to insert the keyword between every other keyword in tasklists.
An extra 2 keywords were added, b_rule_extreme_nofact, and b_rule_extreme_carry. The first did not build factories and the latter keeps repeating over and over again untill the economy has left the danger zone and restabilized (aka when it reaches the point where the rules say it should skip it stops repeating and moves to the next task).
This is also where the build algorithm rule values in toolkit come from, the ones in the big 2 columns of textboxes. The values plug directly into the if statements controlling the b_rule mechanisms.
hmm I might make this a blog post
In theory the algorithm is a perfect model of spring economics. However spring economics does not follow the intended model, and as such the antistall algorithm works better under OTA than spring, for the same reason people like argh complain springs economics are fundamentally flawed.
As a result the antistall algorithm anticipates a cost and dclares a unit too expensive, but in reality the fixed unit costs that are necessary may not be deductable ebcause all the resources have already been suedfor construction costs, resulting in free resources. Thus the antistall algorithm is deemed to strict and the user complains, and the AI suffers from the flaw.
To combat this new tags were introduced to weight the antistall algorithm to be too strict or too lenient in order to find a compromise. But this lead to a no win situation where the optimum tag value lead to ok behaviour at the price of random fluctuations leading to decisions that were both too lenient and too strict all in the same game.
To deal with this there were 2 avenues.
1: Predict cost based on the past and extrapolate the future economy based on the current direction modified by the weight of the potential construction project.
2: Add other systems to catch the stall event and increase economic competency at a common sense level.
Since a predictive algorithm would be imperfect and would need to be re-evaluated or suffer from unforeseen circumstances such as a unit thatwas reclaiming suddenly stopping and repairing an existing building turning an income into a cost and throwing off the predictions, I decided to take route 2.
To do route 2 I created b_rule, which fitted in with user demand at the time which complained NTai had no intelligence like AAI or OTAI and wouldnt rebuild energy fi tis energy was destroyed. It made sense as it made NTai more adaptive.
However it wasnt enough so b_rule_extreme and the carry versions where introduced. This keyword acted like b_rule but only did so in extreme situations in order to prevent metal leakage or complete nanostall.
So if energy was below a certain set of parameters it would start building energy, or if energy was abundant but metal was not ti would choose metalmakers, if both resources where nearing the upper storage limit and had big surplus generation it'd buildstorage or factories. And if the economy was stable it would just return. That way you could put in lots and lots of the keyword and it would act as a safety net. So much so interpolation was introduced to insert the keyword between every other keyword in tasklists.
An extra 2 keywords were added, b_rule_extreme_nofact, and b_rule_extreme_carry. The first did not build factories and the latter keeps repeating over and over again untill the economy has left the danger zone and restabilized (aka when it reaches the point where the rules say it should skip it stops repeating and moves to the next task).
This is also where the build algorithm rule values in toolkit come from, the ones in the big 2 columns of textboxes. The values plug directly into the if statements controlling the b_rule mechanisms.
hmm I might make this a blog post
The antistall does have issues but can be used effectively to prevent the creation of uber units when they can't be accomdated whilst allowing them to be added to task list in the event that they can be accomodated. I agree that the system isn't perfect but if you are prepared to create a config to work round the limitations it can be very successful.
Any ideas on the spacing problem? Also have you got a profiler running now?
Any ideas on the spacing problem? Also have you got a profiler running now?
got an instance of that crash bug with logging enabled
Code: Select all
[01:34]|11:0:40| < Frame: 2834 ><0>function :: CManufacturer::Update
[01:34]|11:0:40| < Frame: 2834 ><0>function :: CUnit::RecieveMessage
[01:34]|11:0:40| < Frame: 2834 ><0>function :: CUnit::GetAge
[01:34]|11:0:40| < Frame: 2834 ><0>function :: CUnitConstructionTask::RecieveMessage
[01:34]|11:0:40| < Frame: 2834 ><0>function :: CUnit::RecieveMessage
[01:34]|11:0:40| < Frame: 2834 ><0>function :: CUnit::RecieveMessage
[01:34]|11:0:40| < Frame: 2834 ><0>function :: CUnit::GetAge
[01:34]|11:0:40| < Frame: 2834 ><0>function :: CUnit::RecieveMessage
[01:34]|11:0:40| < Frame: 2834 ><0>function :: CUnit::GetAge
[01:34]|11:0:40| < Frame: 2834 ><0>function :: CUnit::RecieveMessage
[01:34]|11:0:40| < Frame: 2834 ><0>function :: CUnit::GetAge
[01:34]|11:0:40| < Frame: 2834 ><0>function :: CUnit::RecieveMessage
[01:34]|11:0:40| < Frame: 2834 ><0>function :: CUnit::GetAge
[01:34]|11:0:40| < Frame: 2834 ><0>function :: CKeywordConstructionTask::RecieveMessage
[01:34]|11:0:40| < Frame: 2834 ><0>function :: Chaser::Update
[01:34]|11:0:40| < Frame: 2834 ><0>function :: Chaser::Update :: DONE
[01:34]|11:0:40| < Frame: 2834 ><0>function :: CManufacturer::UnitCreated
[01:34]|11:0:40| < Frame: 2834 ><0>function :: CMap::CheckFloat3
[01:34]|11:0:40| < Frame: 2834 ><0>function :: CManufacturer::WipePlansForBuilderThat suggests an issue with plans and pointers.
I cant debug on my laptop atm as the ATI vista drivers have abysmal openGL support. My spinning triangle OpenGL test app stutters and spurts every few seconds despite flawless operation at uni and on my main PC.
I'm going to have to figure out this EasyBCD stuff and get ubuntu booting again on my main PC. But I've gotten VS2005 all up and patched on my laptop and partially patched on my main PC.
I cant debug on my laptop atm as the ATI vista drivers have abysmal openGL support. My spinning triangle OpenGL test app stutters and spurts every few seconds despite flawless operation at uni and on my main PC.
I'm going to have to figure out this EasyBCD stuff and get ubuntu booting again on my main PC. But I've gotten VS2005 all up and patched on my laptop and partially patched on my main PC.
-
1v0ry_k1ng
- Posts: 4656
- Joined: 10 Mar 2006, 10:24
I've mde a few modifications. A few vector containers in the CUnit class switched to list containers which might prevent stl container related crashes (stl container expands, and copies all its contents into a new internal structure. During this process the shared_ptr/s all delete themselves and get re-assigned destroying any meaningful data they held leading to a crash the next time their pointer contents are handled).
I've also renamed the CInfo class to CConfigData and added a destructor and load function and moved a large chunk fo code into it out of the Global class and done a little formatting clean-up.
I've also renamed the CInfo class to CConfigData and added a destructor and load function and moved a large chunk fo code into it out of the Global class and done a little formatting clean-up.
A word of warning, I may end up sacrificing features in favour of simplification of the code base. Single build and solo build may be up for the chop.
For the code base I'm going to start trimming off anything that's unnecessary or will have little impact yet has a lot of complexity.
On top of that I'm going to shift as many thins as I can into lua once I have a working mechanism to move logic out of NTai and into extendable lua classes.
I'm hoping also that by doing this I can expose more data to lua about NTais internals and maybe some budding lua widget coder can start writing widgets to show NTai data or start replicating toolkit features.
However the main focus will be on streamlining NTai to serve the role as more of a framework for the config format.
For the code base I'm going to start trimming off anything that's unnecessary or will have little impact yet has a lot of complexity.
On top of that I'm going to shift as many thins as I can into lua once I have a working mechanism to move logic out of NTai and into extendable lua classes.
I'm hoping also that by doing this I can expose more data to lua about NTais internals and maybe some budding lua widget coder can start writing widgets to show NTai data or start replicating toolkit features.
However the main focus will be on streamlining NTai to serve the role as more of a framework for the config format.
I'd say that singlebuild and solobuild are two hugely important features, if you are going to get rid of them then the antistall stuff will need to be improved and extended and improved. Someway for it to the rate of unit production or a way to prioritise things over other items wil be needed. At the moment antistall can starve NTai of major buildings because smaller buildings and units will always be built. This will problem would be exagerated without singlebuild/solobuild.
-
1v0ry_k1ng
- Posts: 4656
- Joined: 10 Mar 2006, 10:24
are you insane? with my XTA config i proved NTAI with decent config is probably the most effective AI, why dont you just make a release with configs/installer and then just keep it upto date? dont hack it up again!AF wrote:A word of warning, I may end up sacrificing features in favour of simplification of the code base. Single build and solo build may be up for the chop.
also, if you remove single and solo you may as well just give up on this AI because if its working from configs it needs those to allow any kind of intelligence. so frustrating!
Ok.
Imagine you have a messy room to clean up.
People complain they cant just walk from one end of the room to the other and complain about speed issues.
At the same time a lot of space is wasted so new feature (in the form of piles of socks) cant really be added.
So the logical answer is to take everything out and add it in in an orderly manner?
Imagine you have a messy room to clean up.
People complain they cant just walk from one end of the room to the other and complain about speed issues.
At the same time a lot of space is wasted so new feature (in the form of piles of socks) cant really be added.
So the logical answer is to take everything out and add it in in an orderly manner?