[MODCOMP] Multi-Building Unit Requirement

Multi-Building Unit Requirement
By: TheLopez

Last Update: 08/27/10

Version: v0.3BtS
Patch Compatibility: Beyond the Sword v3.19
MP Compatible: ?
Download Mod v0.3BtS

Version: v0.2w
Patch Compatibility: Warlords v2.0.8.0
MP Compatible: ?
Download Mod v0.2w

Version: v0.1
Patch Compatibility: v1.61
MP Compatible: ?
Download Mod v0.1

Description:
This mod adds the ability to specify multiple required and optional buildings
needed to building units. Any buildings added in between the <PrereqBuildings>
tag will now be required to build the unit. One of the buildings added in
between the <PrereqOrBuildinges> tag will now be required to build the unit.

For instance the updated battleship definition using the new tags looks like:

-----Notes to Modmakers-----

If you want to use this mod component in your mod I have tried to make things
as easy as possible for you. In the XML files I have added
<!-- Multi-Building Unit Requirement Start --> and
<!-- Multi-Building Unit Requirement End --> in all of the places where
changes were made. In the SDK files I have added
// < Multi-Building Unit Requirement Start > and
// < Multi-Building Unit Requirement End > in all of the places where changes
were made.

-----Version Information-----

-----v0.3BtS------

- Updated to be compatible with Beyond the Sword v3.19 patch.



-----===Credits & Thanks===-----

- Exavier
Composite Mod - readme.txt format

- Doronron
For proposing this mod.

Oooohh! The Building-AND-Building option doesn't interest me much, but that Building-OR-Building looks tasty!

I've already got half a dozen units that will now be requiring one or the other...

Shouldn't this be based on building Class, so for example the Zulu who cant build a BUILDING_BARRACKS can still have the unit in question.

Impaler, I did think about doing it that way but what would happen if you wanted to have the Zulu to have a unit that depended on only their building and another building?

Well, the good news is that with the "OR"option, you can fix this...

I was having the same issue because I wanted to have Factories be a requirement for building Bombers, but then that left the Germans in trouble... now I can set it so that one needs either the German factory or the regular one. Problem solved then

Wouldn't that then logicaly become a Unique Unit for the Zulu if it required their unique building, the moder could use the traditional system of UnitClass/UnitType to simpley have a Zulu Unique Unit. If your intent is to create truely unique units as in a unit that can only be built by one civ and their no coresponding unit built by any other Civ then that could be done by just giving the UnitClass None for the Default unit.

My opinion is that all such requirments should be Class based rather then type based, for example Firaxis altered the Pre-Requisite Building requirments for a building. In Vanilla it was type based but in WL its class based so that Unique Buildings still fufill requirments. They were aparently lazy/in a hurry and didn't do the same thing for units and several other tags probably because they themselves didn't make use of the tag in the official game. Its definantly better practice in my opinion to use Class rather then Type especialy as the number of Mods that add Unique Buildings such as CivGold continues to grow. We already noticed some problems in the XL composite mod ware bonuses were coded as Type and this resulted in the falure of a UB to get the apropriate bonus. I've got half a mind to start altering all the stuff Firaxis has too lazy to update. I'f I was you I'd change all three of thouse tags to be Class based.

Work arounds like Dom found are possible but I their rather a lot of unessary work and it grows exponentialy as the number of Unique Buildings incresses, every person adding a Unique Buildings would need to add references to it on files they would otherwise be able to ignore and then their mods will be incompatible with ones made by other people because of various dangling references.

Ok, good point impaler... I'll work on updating the mod this weekend.

EDIT1: Impaler, I'm not going to update the original <PrereqBuilding> tag since it was the one provided by Firaxis and would cause everyone to have to update their CIV4UnitInfos.xml. Instead if people want to they can move their building requirements to the new tags introduced by this mod when needed.

EDIT2: Mental note, it isn't always good to follow the examples set in a provided SDK since the implementation might have been done in a lazy manner...

Hmm... yeah, I was trying to think of a counter-argument to Impaler's point, but I couldn't...

However, for my purposes, this works. There's only one instance where I have to make this workaround for my mod.. nevertheless, I download and incorporate most everything TheLopez puts out

I dont "think" their are any intances of the tag being used in the original game Assets and I cant think of any instances ware people have used it so theoreticaly their should be no conflict.

Another idea. Its the XML loading stage ware the tags contents are assosiated with a particular information grouping, in this case the BuildingClass vs the BuildingType with the data stored in a particular variable of the InfoClass. Firaxis always used a 1:1:1 relationship witch each tag searching a single Infotype and being stored to a single variable. But what if we expanded the searching to both data types and achived a 1:2:1 relationship.

It would go like this the section ware we search for the string in the InfoClass looks something like this...

int = pXML->FindInInfoClass(STRING, GC.getINFOInfo(), sizeof(GC.getINFOInfo((TYPE ENUM)0)), GC.getNumINFOInfos());

This will return the index if it finds it or -1 (NONE) if it dosn't so lets set up an if statment and ALSO check another InfoClass if we didn't find it in the first.

if (FindinInfoClass(SRTING, FIRSTINFOCLASS) != -1)
{
int = FindinInfoClass(SRTING, FIRSTINFOCLASS);
}else{
int = FindinInfoClass(SRTING, SECONDINFOCLASS);
}

Now we can include both types of references, and 2 infoClasses get searched. As BuildingType is always equal to or larger then BuildingClass size wise we store the data in a BuildingType boolean array. When we find a BuildingClass tag a loop is initiated to set all buildings of that Class true just as if they had been found on their own. Thus all the data gets packed up in the same locations and your able to use either type of reference seamlessly, best of all the old Assets will continue to read in without any problems.

Thank you, TheLopez! Quick work!

thank you lopez,

just what i needed.


man - you are a one man factory of mods!!!!!! where do you get all these ideas?
god bless you.

I confess that I have run into similar 'Laziness' in regards to the <BuildingHappinessChange/> tag in CivicsInfo. Rather than make it BuildingClass based, they APPEAR to have left it as BuildingType. Damn them all to HELL .

Aussie_Lurker.

Aussie_Lurker said:

I confess that I have run into similar 'Laziness' in regards to the <BuildingHappinessChange/> tag in CivicsInfo. Rather than make it BuildingClass based, they APPEAR to have left it as BuildingType. Damn them all to HELL .

Aussie_Lurker.

Click to expand...

It's worse than that... it gives a bonus to the wrong building... at least it did for me. I'd set it to Granary and it would apply it for Stables.

that sounds like a mismatch, granary is the 10th BuildingClass, Stable is the 10th BuildingType. The data is being taken off the XML properly and stored at the 10th index but the bonus is being given to the 10th BuildingType.

Their are a couple of diffent ways to fix it, either convert the data at XML loading into the proper BuildingType data OR alter the bonus awarding mechanism to key off of BuildingClass. I would recomend the latter solution as it would be simpler and the textmanager would remain as it is listing the Class of building.

Actualy this means your half way their as to converting it to class based.

Ah... thanks for the tip... I had no idea where they'd gone wrong. I'm working on correcting the mistake as we speak.

EDIT: After looking at the code a bit more, I think it's even more half-done than I'd thought... I'm trying to find where it actually adds the new happiness, but the only thing I'm finding is building happiness changes for civics, which since they use the same term "buildinghappinesschanges" makes me wonder if somebody didn't get confused...

In vanilla Civ their would have been a perfect match between the Class and Type Index's so no one would have had a problem. So its possible that this could all be firaxis fault when they failed to realized that the new buildings would screw up their own tags. This seems to have been the patern in WL, they made the absolute minimum code changes to accomadate the existing XML assets, tags that weren't being used didn't get updated.

Sounds like the CCCP crowd has something to work on

Updated Warlords version to be compatible with the v2.0.8.0 patch.

I have a question... What do I do with the C++ files?

Depends on what you want them for. If you just want to use this mod as is, then you leave it well enough alone. If, however, you want to merge it with other mods, then you need to copy and paste the tagged sections into the new mod's C++ files, then compile it. This will give you a new .dll file that will run when you load the new mod.