Mod-Modders Guide to Fall Further

There s no button in Unit Info :)
I would prefer if there would be one.

Anyway I'll go around it without too much problem, it was just not logical in my opinion, though disturbing.
 
Ah, now I see your example more clearly then.

Yes, the first art define you use controls the button which will appear, so in your case, wanting to use 3 models in various mixtures for 5 distinct units, you need at least 2 cases of the same NIF being defined twice to achieve the full 5 button spread.

Primarily for the case of Civ specific Art styles, it is a neccessary evil. Were the button defined on the unit, then how would you redefine the button along with the art style for a civ? It would have to also be included in the ArtStyles folder, leading to possibly MORE duplication than in the current method.
 
Happy to finally be clear enough that you understand perfectly my problem. :p

Primarily for the case of Civ specific Art styles, it is a neccessary evil. Were the button defined on the unit, then how would you redefine the button along with the art style for a civ? It would have to also be included in the ArtStyles folder, leading to possibly MORE duplication than in the current method.

Well, I must disagree here. I do not master ArtStyle, but I thought that ArtStyle did not overwrite a single unit ART, but really the unit art group. Am I mistaken here ?


Code:
<UnitArtStyleTypeInfo>
	<Type>UNIT_ARTSTYLE_BALSERAPHS</Type>
	<StyleUnits>
		(...)
		<StyleUnit>
			<UnitType>UNIT_WARRIOR</UnitType>
			<UnitMeshGroup>
				<EarlyArtDefineTag>ART_DEF_UNIT_WARRIOR_BALSERAPHS</EarlyArtDefineTag>
				<LateArtDefineTag>ART_DEF_UNIT_WARRIOR_BALSERAPHS</LateArtDefineTag>
				<MiddleArtDefineTag>ART_DEF_UNIT_WARRIOR_BALSERAPHS</MiddleArtDefineTag>
			</UnitMeshGroup>
			<UnitMeshGroup>
				<EarlyArtDefineTag>ART_DEF_UNIT_WARRIOR_BALSERAPHS</EarlyArtDefineTag>
				<LateArtDefineTag>ART_DEF_UNIT_WARRIOR_BALSERAPHS</LateArtDefineTag>
				<MiddleArtDefineTag>ART_DEF_UNIT_WARRIOR_BALSERAPHS</MiddleArtDefineTag>
			</UnitMeshGroup>
			<UnitMeshGroup>
				<EarlyArtDefineTag>ART_DEF_UNIT_WARRIOR_BALSERAPHS</EarlyArtDefineTag>
				<LateArtDefineTag>ART_DEF_UNIT_WARRIOR_BALSERAPHS</LateArtDefineTag>
				<MiddleArtDefineTag>ART_DEF_UNIT_WARRIOR_BALSERAPHS</MiddleArtDefineTag>
			</UnitMeshGroup>
		</StyleUnit>
		(...)
	</StyleUnits>
</UnitArtStyleTypeInfo>

So I was considering the CIV4UnitArtStyleTypeInfos.xml file to overwrite this part of the Unit Infos:

Code:
<UnitMeshGroups>
	<iGroupSize>3</iGroupSize>
	<iMeleeWaveSize>3</iMeleeWaveSize>
	<iRangedWaveSize>0</iRangedWaveSize>
	<UnitMeshGroup>
		<iRequired>1</iRequired>
		<EarlyArtDefineTag>ART_DEF_UNIT_WARRIOR</EarlyArtDefineTag>
	</UnitMeshGroup>
	<UnitMeshGroup>
		<iRequired>1</iRequired>
		<EarlyArtDefineTag>ART_DEF_UNIT_WARRIOR</EarlyArtDefineTag>
	</UnitMeshGroup>
	<UnitMeshGroup>
		<iRequired>1</iRequired>
		<EarlyArtDefineTag>ART_DEF_UNIT_WARRIOR</EarlyArtDefineTag>
	</UnitMeshGroup>
</UnitMeshGroups>

In which case we could simply add the button info in the CIV4UnitArtStyleTypeInfos.xml file, which is not bad as well.

Talking about what I do not fully understand with you make me feel strange :)
 
Race, like not what civ it is, but elf/dwarf/etc?

You could check for the promo.
 
Use getDefaultRace(), it seems to be exposed to python, according to CyInfoInterface2.cpp ;)
 
Probably not the place to ask this but...

Modules... how will they effect Multiplayer? I was looking at the Spider Art module and wondering if I install it, will all 3 of the guys I play with have to have the Same module? (I always host if that matters)

I was thinking since THIS one is just an art mod it may not cause any issues but thought I should ask 1st.
 
To the end user, it's just an art mod. But really, it also modifies the spider promotions, and creates new artdefines.

A pure art mod would just be replacing a model or texture.

I'd guess that it will require everyone to use the same module, to make it work. And if it doesn't, then OOS errors seem almost certain
 
Not sure on that. Normally, any mod will affect multiplayer. But being only art, it MIGHT be an exception, since that wouldn't cause a natural conflict. But the people who wrote the code to verify MP games would have needed to specifically make such an exception, which they may have chosen not to do.

EDIT: Ninja'd by someone who has actually looked at the Module :) Go with WarKirby's post, he's the art guy afterall!
 
Is there a way to get at the currently loaded mod from python?

That is, in a normal installation of Fall Further, I'd get a string along the lines of "Fall Further 051".

edit: It's the directory the mod is in I need, not whatever name the mod chooses to go by.
 
CIV4ArtDefines_Misc.xml has it defined in one location, might be able to access that, but not sure what route you would have to take. CvPath.py also ought to have it defined, it is a python file already, so should be easily accessed.
 
Well, the CvPath module has an answer at least...

From CvPath:
NOTE: activeModName does not currently work in a completely automated fashion. There does not appear to be a way to determine the active mod programmatically from Python code. A mod that wishes to export its name to this module must create a Python module called CvModName that contains a string variable named modName set to the name of the mod. A sample CvModName is shown below.

Code:
# CvModName.py
modName = "American Revolution"

Of course, a CvModName Python module should only be used if the mod is indeed installed in the Mods directory, not when it is installed in CustomAssets. Furthermore, if the value of the modName variable does not correctly match the mod directory name, the path variables will not be set properly.

So basically impossible. Will have to use hardcoding then.
 
Here xienwolf, source files uploaded. I uploaded all of them, not only the one I modified though.

There's some uncommented changes in CvInfos.cpp, most likely some Orbis tags I put in CopyNonDefaults.

Thanks again :)

(Now I just hope it's some crazy thing so I don't look like an idiot when you'll come up with the solution :p)
 

Attachments

I remember seeing some time ago someone complaining about the worldbuilder wrongly setting a custom terrain as ocean floor level, instead of land plot level, making it impossible to use.

But I cannot remember the solution nor can I find it throught the search in the forum :eek:

Would someone know how to make the new terrain being set up correctly in the worldbuilder ? :mischief:
 
From the bug thread: "It is "decoded" from the XML by checking for the things which make it possible to acquire a promotion, primarily that is having a UnitCombat type for which it is defined to be valid for. For further questions, please jump over to the modder's guide, as now you are wondering about how to change something, not reporting something which is broken."

Regarding the Religious Leader II promotion. There's no difference in the XML between it and the Religious Leader I promotion, except there is an <iMinLevel>-1</iMinLevel> item. I cannot find this promotion in the python or any other XML files, so I thought that it must just be a miskeyed entry there, since <iMinLevel>-1</iMinLevel> is used for the promos that commanders give to their minions.
 
sylvain: New one to me. So worldbuilder cannot change terrain for you right now? Or just a new terrain which you added doesn't work properly? Could you post the XML for the terrain if so?

Westmasta: iMinLevel of -1 also makes something impossible to purchase with XP. That is how Zealous II is blocked from being gained by any units at all. Seems that there aren't any units who start with it by default right now for some reason. So it would be a question for Vehem on what the mistake is, making it impossible to buy, or forgetting to put it on some Hero unit.

iMinLevel is on all of the promotions which the commanders grant their minions because those promotions are not allowed to be purchased by XP as well, they MUST come from a commander.
 
Back
Top Bottom