Now it tells me they already have been instantiated (which is right)
However, when I comment out the code above, linker can’t find these two functions ><
Just want to let you know that revision 3629 compiles fine.
Good to hear, however it does not compile for me in this form.
Makes no sense, does it?
I would like to report significant progress with AI. It ddidn’t learn any new tricks, but what it does, it does well. Thanks to implementation of Fuzzy logic in one vital point, it is now simpler, consistent and smarter. Also, the code was cleared and shortened . It is now is more manageable and predictable.
The key is ability to compare many different sub-goals at once. So far it was implemented only for VisitTile goal, but since most of actiions end up in visiting tiles, performance improvement is significant. AI considers distance to tile, tile danger and hero strength all at once, choosing optimal solution. A breaktrough was to penalize strong heroes for visiting unguarded objects. AI won’t use hero with horde of dragons to farm windmills anymore, thus move forward faster.
Also, recruting hero dillema was solved. Now recuriting hero is just one of possible actions. It has fixed value for now, so AI chooses it if no better solutons are available. AI may recruit 7 new heroes as well as none, depending on situation.
I plan to extend fuzzy logic on other areas, such as gathering army or building management. But that’s all in the future.
Thumbs up Warmonger! I have to fix 1 minor bug, test a few cases and then we have mostly fully playable campaigns. (2-3 mantis tickets are still open, but OK)
That’s great - better AI and campaigns would be a great additions 
beegee,
In H3 campaigns have some hardcoded features:
- non-standard victory conditions (working on it)
- Gem has custom class named “Sorceress”. Can be fixed easily using our modding system.
- Yog who can’t equip spellbook.
(could be more of them)
What we should do with Yog? Maybe implement hero flag “can’t use spells” and give it to him? Should be simple to do.
(and sorry for offtopic)
Warmonger
My humble opinion - AI should be allowed to see the entire map. He will never be able to play like a man. Give such odds is quite logical. Think about it. Perhaps then he will be able to better analyze the map. And properly prioritize.
At least you can try, at least for the test. At least for this. Maybe it’s not so scary;)
(sry my engleash - translate)
AI will never be able to play like a good player, that’s right. It should, however, appear smart and smooth. It also should be able to play on any scenario. Certainly AI shouldn’t get stuck forever or report weird errors.
AI is unable to cheat, that’s the goal of engine. Everybody can only see or do what player could do.
If you want challenging games, play maps where AI has advantage.
I say this (offer) to play random maps. (Sooner or later, because they still appear. I hope.) And so it will be much more interesting to play. Best analysis - the best performance. (And the average user may not notice). It will only be glad that the VCMI computer plays better than the original heroes.
If AI can consistently break dragon utopia on the fair on the third week. Of course this will be enough.
Way at the expense of the original heroes, I heard that there he sees the map immediately.
Current AI looks very stable. Just passed 13 months with 4 players without crash and no serious issues. I’d leave it as it is for next release. How about dev build soon?
Give it to me. And I’ll find you the error 
I try to handle spawning new objects on adventure map, especially week of double creatures. However, with the following code uncommented, game freezes for good after few objects have spawned. Probably threading issue.
void VCAI::newObject(const CGObjectInstance * obj)
{
LOG_TRACE(logAi);
NET_EVENT_HANDLER;
if(obj->isVisitable())
addVisitableObj(obj);
//AI should reconsider strategy when spawning monsters block the way and free reserved objects
//FIXME: AI tends to freeze forever on a week of double growth if this code is active
//auto safeCopy = reservedHeroesMap;
//for (auto hero : safeCopy)
//{
// auto h = hero.first;
// for (auto reservedObj : hero.second)
// {
// auto pos = reservedObj->visitablePos();
// if (!(isAccessibleForHero(pos, h) && isSafeToVisit(h, pos)))
// {
// erase_if_present (reservedObjs, reservedObj);
// for(auto &p : reservedHeroesMap)
// erase_if_present (p.second, reservedObj);
// }
// }
//}
}The code looks innocent enough. One possible reason for freeze might be if you request an action from callback when in the event handler function. But that doesn’t seem to be the case here.
Could you paste the stacktraces at the freeze moment?
To all testers: in order to effectively debug AI, you need to enable AI console output.
I uploaded mod “adventure AI trace” to our repository. It shuld help users to configure the console.
Oh my, I just figured out a serious issue. Actually, value returned by fuzzy engine is always the same for every type of input, regardless its value. Not sure for how long this issue has been around, but probably not from the very beginning.
Bad thing: It doesn’t work at all.
Good thing: AI can work much better once fixed.
That reminded me of another possible issue - this TODO note I made some time ago:
github.com/vcmi/vcmi/blob/maste … s.cpp#L161
In short this is status of victory/loss conditons in AI:
- Some not implemented conditions, most notably “flag all objects of type” and “destroy all objects of type”.
- AI will only try to complete first detected goal. That “for” loop iterates over all possible goals but only first one will be evaluated by AI.
- Proper detection of human-specific victory/loss conditions and possibly AI-specific conditions (not applicable to H3 but already allowed in vcmi).
I can try to implement last one but first two I’d rather leave to somebody else.
Engine allows to consider multiple goal already, however many pieces are still missing.
For example, to get Grail, AI could consider all known Obelisks and pick the closest one. However, if the win condition is to “gather resources”, AI won’t benefit from it, since resources gathering (and saving) is somehwat simplified.
Got it. Seems that centroid algorithm fails is the positions of terms are too far away (even thoug they overlap). Rules must densily fill entire value range for it to work.
One question to Tow that bothers me recently:
Does function isAccessibleForHero return true for tiles that are guarded / blocked by removable objects?