Wild Mana for FFH 2
- Thread starter Sephi
- Start date
Afterthought_bt
Warlord
- Joined
- Jun 27, 2009
- Messages
- 144
Starting to get frequent unrepeatable CTDs in the middle of the computer's turns. (As in every few turns)
Every time I reload, it keeps going for a few more turns, and then CsTD again. Is there anything I can do to narrow the problem down? Can't say end turn times are particularly long, or anything like that. Say if you want me to upload a save.
Every time I reload, it keeps going for a few more turns, and then CsTD again. Is there anything I can do to narrow the problem down? Can't say end turn times are particularly long, or anything like that. Say if you want me to upload a save.
The AI will build more siege weapons next version and use them smarter. Make an AIAutoplay and you will see that Barbs usually die pretty fast. The issue with the UNITAI is fixed.
@Afterthought
Maybe switching to base FFH graphics will increase stability for you.
Go into your FFH folder: Assets/XML/Buildings
, Exchange CIV4CityLSystem.xml and CIV4PlotLSystem.xml with the FFH ones
, Go into your FFH folder Assets/XML/Art
, Exchange CIV4ArtDefines_Building.xml with FFH base one
let me know if this removes the CTD for you.
Afterthought_bt
Warlord
- Joined
- Jun 27, 2009
- Messages
- 144
hmm... WM is desperately trying to make me look like an idiot.
By the time I saw your suggestion to change the graphics, it had just stopped CTDing. So I may never know why it was crashing. 
I suppose it was something to do with a unit which got destroyed or something, maybe... Seems to be stable again now anyway.
Anyway - I've noticed some barbarian orcs must have thought they were elves. There's a cottage in some trees near a barb city, and the only civs near them the whole game were the Elohim and the Luchuirp... and me. (Grigori) It is just above and to the left of the barb city in screenshot.
By the time I saw your suggestion to change the graphics, it had just stopped CTDing. So I may never know why it was crashing. I suppose it was something to do with a unit which got destroyed or something, maybe... Seems to be stable again now anyway.Anyway - I've noticed some barbarian orcs must have thought they were elves. There's a cottage in some trees near a barb city, and the only civs near them the whole game were the Elohim and the Luchuirp... and me. (Grigori) It is just above and to the left of the barb city in screenshot.
Attachments
works fine. just a few civs play too defensive, but already fixed
@Afterthought
I have no idea why the Elohim build a cottage there, but you can build improvements in new forests which grow into normal forests.
![[to_xp]Gekko](https://civfanatics-data.community.forum/avatars/m/74/74677.jpg?1475248346){kind=avatar}
[to_xp]Gekko
QCT junkie
next patch looks juicy, awesome job Sephi, as always 
it's great to see some of the AI improvements from snarko's mod are in btw
it's great to see some of the AI improvements from snarko's mod are in btw
[to_xp]Gekko
QCT junkie
maybe you got the idea from it and then forgot XD
I'm talking about the "AI can make demands from other AIs" thingie.
I'm talking about the "AI can make demands from other AIs" thingie.
Monkeyfinger
Deity
- Joined
- Oct 24, 2006
- Messages
- 2,002
As long as you're tinkering with inter-AI diplomatic relations, any chance of giving peaceweight and warmonger respect a closer look?
http://forums.civfanatics.com/showpost.php?p=8192952&postcount=1581
http://forums.civfanatics.com/showpost.php?p=8192952&postcount=1581
I am pretty sure it works very different from Snarkos Mod.[to_xp]Gekko;8483615 said:
the peaceweights are already changed in 5.0, the first thing actually that I did change (those of good leaders were weird, especially Cardith with +10)
There is a new event where a scattered tribe of elves is found in your land. If you choose to leave them alone, it places a cottage in the square in question. That's probably where the forest cottage comes from.
I can't merge in the hard coding in the UnitAI file (it would cause crashes for any mod modder that didnt include those spells/promotions). I wanted to get your opinion on a better way to do it. What do you think about:
1. Is it possible to update CvUnit::chooseSpell() to do this? Which should already take all of these things into account.
2. Would it be better if we added a few booleans to the spell schema so we could define if they are war spells, unit buffs, city buffs, etc? Then add a parameter to choosespell so we can isolate to just those spells.
3. If we added the schema attributes as above we could keep your functions. I wasnt sure if you checked out choosespell and what you thought of it or what you thought could be done to improve it.
4. We could farm all this out to python, but I hate to do so because of the performance cost, which is why I assume you hard coded it in the sdk.
Let me know what you think.
1. Is it possible to update CvUnit::chooseSpell() to do this? Which should already take all of these things into account.
2. Would it be better if we added a few booleans to the spell schema so we could define if they are war spells, unit buffs, city buffs, etc? Then add a parameter to choosespell so we can isolate to just those spells.
3. If we added the schema attributes as above we could keep your functions. I wasnt sure if you checked out choosespell and what you thought of it or what you thought could be done to improve it.
4. We could farm all this out to python, but I hate to do so because of the performance cost, which is why I assume you hard coded it in the sdk.
Let me know what you think.
xienwolf
Deity
I would say that adding the booleans to identify broad-scale when they are appropriate to consider (hostile action, city augmentation, unit augmentation...) and then within each of those allowing a python callback might be a nice compromise. Then you can still hardcode, but do it in python, and avoid SOME of the cost. But this approach would be more costly than a single general python override if many spells have multiple booleans flagged (then you have them making 2 or 3 calls for that spell instead of just 1).
I haven't looked at Sephi's code at all yet (so I am kinda sticking my nose where it doesn't belong by responding, sorry. I'm annoying sometimes
), but I know that some spells could use fundamental changes to make them more AI friendly, by which I mostly mean bringing them into the DLL instead of python. Vitalize/Genesis is one example where a function could be written to determine the "next best plot type" for any given plot (seek to upgrade food, then production, then Commerce). This brings it generalized into the DLL, automatically includes newly added terrain types like Marsh, and accounts for unique yields like the Illian Snow. Plus by having made it a DLL process, you can make a simple check in ::chooseSpell to see if there is a tile within a limited range which is not "maxed out" for tile type, and to travel there and upgrade it (you could even go to making separate spells for upgrading each of the three tile yields individually so you can aim for better production instead of better food as a final goal, and store the total "shift" from the base tile separate from what the tile actually is originally so that you can make a spell capable of only upgrading a tile once (can take snow->tundra, but cannot continue to take the tundra->plains) and another capable of upgrading an unlimited number of times.
But of course, those recommendations require more time and consideration, and potentially alter features of the game semi-heavily
You could try creating a python override for this function with a Callback control defined in the XML so it is easily disabled, then run a profiler with it on/off and see just how bad the cost really is. I would imagine it isn't actually bad enough to be significant since AI considers spells once per turn per unit. If it is bad, you could use a cache system to identify if a unit is capable of casting any spells at all and disable the callback for any unit incapable of casting (though again this is a more complicated approach which could take some time to develop)
I haven't looked at Sephi's code at all yet (so I am kinda sticking my nose where it doesn't belong by responding, sorry. I'm annoying sometimes
), but I know that some spells could use fundamental changes to make them more AI friendly, by which I mostly mean bringing them into the DLL instead of python. Vitalize/Genesis is one example where a function could be written to determine the "next best plot type" for any given plot (seek to upgrade food, then production, then Commerce). This brings it generalized into the DLL, automatically includes newly added terrain types like Marsh, and accounts for unique yields like the Illian Snow. Plus by having made it a DLL process, you can make a simple check in ::chooseSpell to see if there is a tile within a limited range which is not "maxed out" for tile type, and to travel there and upgrade it (you could even go to making separate spells for upgrading each of the three tile yields individually so you can aim for better production instead of better food as a final goal, and store the total "shift" from the base tile separate from what the tile actually is originally so that you can make a spell capable of only upgrading a tile once (can take snow->tundra, but cannot continue to take the tundra->plains) and another capable of upgrading an unlimited number of times.But of course, those recommendations require more time and consideration, and potentially alter features of the game semi-heavily
You could try creating a python override for this function with a Callback control defined in the XML so it is easily disabled, then run a profiler with it on/off and see just how bad the cost really is. I would imagine it isn't actually bad enough to be significant since AI considers spells once per turn per unit. If it is bad, you could use a cache system to identify if a unit is capable of casting any spells at all and disable the callback for any unit incapable of casting (though again this is a more complicated approach which could take some time to develop)
I don't know if this is a WM or FFH bug, so I'll post here first. Sorry if it's been brought before and I missed it, but I found nothing searching this and the bug thread.
The Governor's Manors in my game are counting all the unhappy towards production, namely the general population unhappies. See the screenshot. No wonder my game was going so easily.
WM Lite 5.0 & g
The Governor's Manors in my game are counting all the unhappy towards production, namely the general population unhappies. See the screenshot. No wonder my game was going so easily.
WM Lite 5.0 & g
I'm pretty sure that is how it is supposed to work (at least in FfH), despite the documentation.
Best wishes,
Breunor
