Version 2.62 released

[UnderKingDuck]

Not needed that's just source code for compilers

ok. Thanks.

 

[A Moon]

Does anyone else enjoy the symmetry of the last version of vanilla FFH having the pyre zombies/sons of Asnea glitch, to which Tholal himself released an unofficial patch, and the intended-last version of MNAI having this bug with units having the bulb tech ability, for which someone else puts up a patch-patch to fix?

I feel like some great cycle has finally drawn to an end.

 

[Terkhen]

Not really, I think it just means that Tholal is on vacation or something like that

 

[MagisterCultuum]

Or that having twin toddlers takes up a lot of time.

 

[Calavente]

that can do it ....

 

[[to_xp]Gekko]

Tholal himself jinxed it when he wrote "unless there is some major bug"

 

[KingGonzo]

Hi there,

we found a new bug in the release 2.62.
All Civ's are now able to recruit monks, but only the Elohim should be able to do so.

Can anyone help or find Tholal.

 

[Terkhen]

KingGonzo: Welcome to the forums!

That's really weird, as I cannot find any recent More Naval AI changes related to monks, and they still appear to be marked as "Elohim only" in the code. Does this happen with other civilization unique units (Malakim lightbringers for example) or only with monks?

 

[jackal1234]

Does anyone else enjoy the symmetry of the last version of vanilla FFH having the pyre zombies/sons of Asnea glitch, to which Tholal himself released an unofficial patch, and the intended-last version of MNAI having this bug with units having the bulb tech ability, for which someone else puts up a patch-patch to fix?

I feel like some great cycle has finally drawn to an end.

Agreed.. Hope the final fixes get officially incorporated tho!

 

[lfgr]

Since Tholal's hasn't been on the forums for quite a while now, I decided to go ahead and release my fixes. I created a repository on bitbucket. It contains Terkhen's fix (many thanks) and some other fixes to reported and unreported bugs. While Tholal is absent, I will upload bugfixes there.

To see what's still planned, check out the issue tracker.
You can download the compiled DLL here. If you want to aid development, you can download the assert version and report an assert messages you come across.

Terkhen, I can add you as a developer, so you can commit fixes directly to the repository, if you want.

Tholal, the next time you're online, could you please state whether you plan to continue developing MNAI? I'm not sure how to interpret "final release".

Edit: Added version b, which fixes PyHelp for spells. Nothing interesting for players, though.

 

[Terkhen]

Terkhen, I can add you as a developer, so you can commit fixes directly to the repository, if you want.

Tholal, the next time you're online, could you please state whether you plan to continue developing MNAI? I'm not sure how to interpret "final release".

While you wait for Tholal's answer, I could port and upload all the recent PitBoss and interface fixes I coded for ExtraModMod to that repository. When Tholal is back, all fixes (yours and mine) could be contributed as a single zip in order to simplify the whole process.

 

[lfgr]

While you wait for Tholal's answer, I could port and upload all the recent PitBoss and interface fixes I coded for ExtraModMod to that repository. When Tholal is back, all fixes (yours and mine) could be contributed as a single zip in order to simplify the whole process.

Yes, I was thinking along similar lines. You should now be able to commit to the repository.

 

[MagisterCultuum]

I am almost ready to release yet another update of my modmod, which uses the PyHelp tags to explain exactly what units may be targeted even for the effects of XML-only spells.

The one issue I have with displaying such targets is that the list for promotion-granting spells still includes those units that should not be eligible due to having another promotion which blocks access to the promotion being granted.

This same issue, by the way, also makes spells light up as able to be cast even though they cannot in fact do anything. That is a base FfH2 and MNAI issue, not just something in my modmod. It should probably be changed.

I think the easiest way (for a C++ modder) to solve this would be to edit
bool CvUnit::canAddPromotion(int spell) in CvUnit.cpp around line 16610 so the it checks the unit's promotions and does not return true if any of them have the promotion in question as a (PromotionTypes) GC.getPromotionInfo((PromotionTypes) iI).getPromotionImmune1(), (PromotionTypes) GC.getPromotionInfo((PromotionTypes) iI).getPromotionImmune2(), or (PromotionTypes) GC.getPromotionInfo((PromotionTypes) iI).getPromotionImmune3() of any promotions they already have.


Things could get more complicated though if some modder makes a spell which adds a promotion at the same time as removing a promotion hat grants PromotionImmune to the added promotion. I don't know if it is worth checking for that case too.


It would also be very useful if you exposed a function to find the PromotionImmunes granted by a promotion and a function to find all of the promotions to which a unit is immune.



I would very much like it if pretty much every tag in CIV4SpellInfos.xml was exposed to python for the spell info type. That way I would not have to hardcode things like the range of a spell, what promotions it may add/remove, how much damage it may do, ect.


I already have such PyHelp functions working in Python, but I wonder if it might be better for the C++ code to handle listing what units/plots will be targeted by the xml effects of spells.

 

[lfgr]

I am almost ready to release yet another update of my modmod, which uses the PyHelp tags to explain exactly what units may be targeted even for the effects of XML-only spells.

So, for example, the Haste spell would state "Targets Adept, Warrior and Swordsman" or "Targets 4 units"? This might be good to implement directly for all spells.

The one issue I have with displaying such targets is that the list for promotion-granting spells still includes those units that should not be eligible due to having another promotion which blocks access to the promotion being granted.

This same issue, by the way, also makes spells light up as able to be cast even though they cannot in fact do anything. That is a base FfH2 and MNAI issue, not just something in my modmod. It should probably be changed.

Agreed. Added as an issue in mnai-fixes.

I think the easiest way (for a C++ modder) to solve this would be to edit
bool CvUnit::canAddPromotion(int spell) in CvUnit.cpp around line 16610 so the it checks the unit's promotions and does not return true if any of them have the promotion in question as a (PromotionTypes) GC.getPromotionInfo((PromotionTypes) iI).getPromotionImmune1(), (PromotionTypes) GC.getPromotionInfo((PromotionTypes) iI).getPromotionImmune2(), or (PromotionTypes) GC.getPromotionInfo((PromotionTypes) iI).getPromotionImmune3() of any promotions they already have.

I have to check whether that could break anything, but thanks for the hint.

Things could get more complicated though if some modder makes a spell which adds a promotion at the same time as removing a promotion hat grants PromotionImmune to the added promotion. I don't know if it is worth checking for that case too.

Shouldn't be too hard: If x makes immune to y AND x isn't removed by that spell, y can't be applied.
Actually, I don't think the casting of a spell should be blocked if it does anything, so the spell above would work on all units that aren't immune against the added promotion, but also on units which have the immune-making promotion, because that would be removed (if the adding of the other promotion would work or not is a different question).
I guess I'll have to take a look how all that stuff works before deciding what to do.

It would also be very useful if you exposed a function to find the PromotionImmunes granted by a promotion and a function to find all of the promotions to which a unit is immune.

I would very much like it if pretty much every tag in CIV4SpellInfos.xml was exposed to python for the spell info type. That way I would not have to hardcode things like the range of a spell, what promotions it may add/remove, how much damage it may do, ect.

Agreed.

I already have such PyHelp functions working in Python, but I wonder if it might be better for the C++ code to handle listing what units/plots will be targeted by the xml effects of spells.

What sort of interface would you like to have for that?

Please note I'm still waiting for Tholal to respond, so I'll only tackle the more simple and obvious bugs for now.

 

[Tholal]

So far I have found one minor bug, which causes temporary terrains to be displayed incorrectly so that it does not look like you are changing them even when you really are.

Thanks for the fix!

Why are ordinary units like adepts and disciples able to research technologies? Not only that, but they seem to be completing even advanced techs which would normally take multiple great persons to learn. This needs addressing.

I think I found the commit in which the issue was originally introduced.

In the int CvUnit::getDiscoverResearch(TechTypes eTech) code change, it seems that the intention was to prevent calculating research if the unit has casted a spell (as in that case the value will always be zero). The calculation itself has also been changed to the following:

The key is the std::min line. At that point, iResearch is not initialized. Therefore, if iResearch happens to have a positive value, this method will return a positive research value and CvUnit::canDiscover will return true.

Good find! I dont remember coding that. Must have been something I copied over from K-mod without checking thoroughly.

Tholal seems to be away, so I went ahead and prepared a hotfix dll for More Naval AI 2.62. [

Tholal: Sourceforge is still offline, so instead of creating an issue in your repository I'm attaching the modified source code to this post.

While fixing this issue, I found another place for performance improvements.

Thanks!

I feel like some great cycle has finally drawn to an end.

Would have been fitting!

It contains Terkhen's fix (many thanks) and some other fixes to reported and unreported bugs. While Tholal is absent, I will upload bugfixes there.

Awesome!

While you wait for Tholal's answer, I could port and upload all the recent PitBoss and interface fixes I coded for ExtraModMod to that repository. When Tholal is back, all fixes (yours and mine) could be contributed as a single zip in order to simplify the whole process.

That would be awesome as well!

Also, since I'm having to reboot anyway, I would be willing to move my code over to bitbucket if it would help with coordination.

 

[Terkhen]

Also, since I'm having to reboot anyway, I would be willing to move my code over to bitbucket if it would help with coordination.

That would be awesome. Allowing to create merge requests for MNAI contributions would greatly reduce the time required for providing them, but specially for merging them into MNAI. In most cases, the code will get merged automatically with just clicking on accepting the merge request in the bitbucket interface.

 

[Terkhen]

Also, since I'm having to reboot anyway, I would be willing to move my code over to bitbucket if it would help with coordination.

That would be awesome. Allowing to create merge requests for MNAI contributions would greatly reduce the time required for providing them, but specially for merging them into MNAI. In most cases, the code will get merged automatically with just clicking on accepting the merge request in the bitbucket interface. It would also help me greatly with my own development, so count with me if you need help with anything.

 

[morchuflex]

Hello.

This modmod is awesome. Many thanks to Tholal and anyone helping to maintain and improve it.
But the last version has at least 2 problems.

- As reported elsewhere, you can now "bulb" any religious tech with a disciple unit.
- Less important, but flavor also counts, doesn't it? The Lanun hero (can't spell his name, sorry) no longer has the ability to sing. The button is still there, but clicking it does nothing. Too bad, listening to him spices up the long, late turns.

Another thing, don't know wether that's WAD or a glitch: in my latest game (Lanun, Immortal), NO computer player even bothered attempting an Altar of the Luonnotar strategy. When I completed the final Altar by turn 308 (Normal speed), noone else even had built the first altar. This is unusual. Generally, at least some of them (especially the Ljosalfar) follow the Altar path.

 

[Miguelitus]

so, I'm just starting with MNAI and it seems there were some issues with the latest release... do you recommend to use that anyways or should I rather get an older version? Also I downloaded the fixes from lfgr's repository. Should I just replace the DLL file in the mod folder to make those work?


Thanks to everybody who is contributing to this Mod

 

[lfgr]

Should I just replace the DLL file in the mod folder to make those work?

Yes. The main issues mentioned here are fixed in that DLL, so you can safely move to the new version.