Mod-Modders Guide to Fall Further

[odalrick]

There is no tag to prevent mimicry. All exceptions are explicit in the postCombatMimic function.

It won't copy equipment or races, Divine, Channeling 3, Great Commander, bronze, iron or mithril. It also won't copy any promotion that the mimic already has, which is new.

It really is copying, not theft, though I don't know if there is a way for the defeated unit to survive.

 

[xienwolf]

Well if equipment wasn't prevented specifically then it would be important to make it theft instead of copy, as otherwise the unit would then also drop the equipment. And you should be able to survive via Immortal promotions, and possibly defensive withdrawal.... Hrm.... Mimic vs Loki would be nice.

 

[Mailbox]

How much is going to change between this FF and the next, I finally have some time to work on the Legion and I don't want the conversion from 043 to take too long, especially since that's the part where I always lose steam. I hate delaying the Legion over and over and I really want to release a new and improved version ASAP.

 

[Vehem]

How much is going to change between this FF and the next, I finally have some time to work on the Legion and I don't want the conversion from 043 to take too long, especially since that's the part where I always lose steam. I hate delaying the Legion over and over and I really want to release a new and improved version ASAP.

Quite a bit. We've got a handful of new features that will have a fairly big impact, but we need to finalize which are going to be in the initial 044 and which can wait for later.

 

[xienwolf]

Build it for the current release, and just let people know what it is valid for If the work is sweet enough (it generally is) then people won't mind playing a slightly outdated version of the base mod for it. And once you have players, it'll be easier to sit through a total update

 

[Vehem]

Build it for the current release, and just let people know what it is valid for If the work is sweet enough (it generally is) then people won't mind playing a slightly outdated version of the base mod for it. And once you have players, it'll be easier to sit through a total update

What he said

===

The other bit that I forgot to say is that if you have any trouble with the updates - let us know. We've had to do a few over the last 10 months or so and will be happy to help where we can (in between fiddling with the new features and getting distracted by Kael's scenarios )

 

[Mailbox]

Now I just have to find my version of .34 I've learned a lot from Kael and you two and realized that a lot can be cut and thus significantly improve the mod. Hopefully the Legion module can be as complete as the the Scions, I'd love for them to have a truly evil and less civilized rival.

 

[sylvain5477]

I'm sorry for asking a maybe obvious question, but I was looking for the place to change the yields for the city plot (seems to be by default 2 food + 1 hammer + 1 commerce) as I would like to remove the 1 hammer. Any idea ? (I checked in the XML files but got confused...)

Thanks in advance.

 

[MagisterCultuum]

It is found in Assets\XML\Terrain\CIV4YieldInfos.xml, a file not included in FfH or FF because these mods don't change anything there. I often include it myself as I like to have the game get moving faster by making cities provide 1 more and .


There are 3 entries in this file Food, Production, and Commerce. Presumably you could add several more types of yields if you want, but I have not tried. The tag you are looking for is probably <iMinCity>, under <Type>YIELD_PRODUCTION</Type>.


Wow, I just realized that this file also allows me to give Peaks yields, something I had been unable to do before (without clumsy python calls). Thank you for having me look it up.

Edit: I just tested it, and it seems like <iPeakChange> doesn't actually do anything. I think I vaguely recall an SDK block preventing impassible terrains from producing anything, which I really wish was not the case. Xienwolf, do you care to look into it? Removing all the blocks that stop you from building improvements on impassible terrain would be appreciated too.

 

[sylvain5477]

Thanks, it works indeed. I intended on supressing the hammer only for 1 civ, but seems it will be for all then..

Do you know if it is pôssible to use several block as :

<CivilizationYieldType>CIVILIZATION_xxx</CivilizationYieldType>
<CivilizationYieldChange>
<iYield>0</iYield>
<iYield>-1</iYield>
<iYield>0</iYield>
</CivilizationYieldChange>

In the terrainInfos file ?

The desert and snow tiles have a part for malakim and illians, but I would like to change the yield also for another civ ?

 

[xienwolf]

As I recall, those fields were designed to only work for a single civilization, so it wouldn't be possible to list another.


As for the impassible tweaks, remind me sometime later and I might be able to look into it. Tied up with solving a few new bugs to make the next version releasable right now and can't get distracted.

 

[Vehem]

Do you know if it is pôssible to use several block as :

<CivilizationYieldType>CIVILIZATION_xxx</CivilizationYieldType>
<CivilizationYieldChange>
<iYield>0</iYield>
<iYield>-1</iYield>
<iYield>0</iYield>
</CivilizationYieldChange>

In the terrainInfos file ?

The desert and snow tiles have a part for malakim and illians, but I would like to change the yield also for another civ ?

As I recall, those fields were designed to only work for a single civilization, so it wouldn't be possible to list another.

That being said - we do need to enable that at some point to tidy up the way Marsh vs Wetland is handled and can enable the better yields for both Mazatl and Cualli...

 

[sylvain5477]

I tried to go around the limitation by using a tech oriented yield change instead of civ oriented, but seems it can only apply to improvement, not to terrain or feature.
Did I do it wrong or do you concur ?

(using the following:

<TechYieldChanges>
<TechYieldChange>
<PrereqTech>TECH_ORGANIC</PrereqTech>
<TechYields>
<iYield>1</iYield>
<iYield>-1</iYield>
<iYield>0</iYield>
</TechYields>
</TechYieldChange>
</TechYieldChanges>

)

I'm also wondering why isn't the following tag used:
<HillsYieldChange/>

and then where is the +1 hammer for hills coded ? (anyway to remove it also )

 

[Vehem]

I tried to go around the limitation by using a tech oriented yield change instead of civ oriented, but seems it can only apply to improvement, not to terrain or feature.
Did I do it wrong or do you concur ?

I think that's probably the case. It's also why "swamp" was made into an improvement for the Lizardmen...

 

[sylvain5477]

and then where is the +1 hammer for hills coded ?

May I abuse your patience insisting of this one ?

 

[MagisterCultuum]

The +1 hammer (and -1 food) from hills is found in the CIV4YieldInfos.xml file I mentioned yesterday, which is not included in FfH or FF because it is unchanged from vanilla.



When you get around to making multiple civs be able to get bonuses from the same terrain could you se abut making Hills and Peaks be able to give civ specific yields bonuses too? I'd like the Khazad to find Peaks much more productive than anyone else.

 

[Maniac]

While harvesting your code on allowing multiple invisibility and invisibility on promotions, I noticed what I assume to be a bug. In CvUnit.cpp it says on two places:

    m_aiSeeInvisibleTypes.clear();
    m_aiSeeInvisibleTypes.clear();

I assume one of those lines should be:
m_aiInvisibleTypes.clear();

Besides that , according to my basic knowledge of C++ grammar, there's a whole bunch of {}s missing. I wonder how you can get your DLL to compile.

 

[xienwolf]

Oops, the bane of line duplication Thanks for the catch, might have caused some of the incidental odd issues I've bumped into on occasion.


As for the {} signs, I am a minimalist when it comes to those (Primarily because WinMerge doesn't handle them very well in large chunks of code like CvInfos where most of your lines are JUST a bracket in the normal CIV format). Using those brackets tells the computer "This is all really just 1 line of code, I promise!", if what you wrote really IS just 1 line of code, then you don't need them at all. Of course, you have to keep this fact in mind when you revise your code, because with the normal method of using them everywhere you have a conditional or loop you just add another line and you are set, but with this approach if you add a second line where no brackets existed, then you are hosed because that new line is NOT included in the loop or conditional.

 

[Jean Elcard]

The missing braces aren't a problem per se, but it's certainly not the best kind of programming style, if you ask around. It's just too easy to forget to add them, when you add a second line of code. I'm forcing myself to use them, after running into some rather time-consuming problems with the minimalistic appoach in the past myself.

 

[xienwolf]

I've often run into just the opposite myself (Duplicate a line and wind up having more end-brackets than I want), but that only becomes a problem if you don't give the bracket a line to itself, which is another bad habit I have (again mostly for WinMerge's sake)