Mod-Modders Guide to Fall Further

You have to make both additive, or make the Cap only obey the largest loaded value I suppose, but even then you either have to loop over all promotions to find the current cap, or find a convoluted method to store all caps so that if you lose the current best cap, but still have a promotion with a slightly lower cap, you remain capped properly. Or I suppose the best solution would be that when the cap is removed, THEN you loop over all promotions to find if there should be a new non-zero cap set in place.

Pretty sure that the passive system will be massively overhauled to be easier for Joe Blow to understand precisely what he is getting out of the deal when we re-release someday. Quite possibly having it so that all gains are on a per-turn specification (so like the FreeXPPerTurn), with individual caps (So if I have +1 per turn up to 100, and +3 per turn up to 30, then I will gain 4 per turn for 10 turns, then continue to gain 1 per turn for another 90, getting me to a total of 130 at the end of it all, assuming nothing else gave me any XP during those 100 turns). Though I honestly don't know which method you reference, probably the same one I am thinking of, but it has evolved since I posted it somewhere.
 
Honestly I was going from a post made in the RifE forum, forgot you planned to overhaul the system as well. :lol:

I think having it cap out at a certain xp value is better than a turn value, personally... Easier to balance IMO. Of course, I'm unable to think of a way to do it beyond making a tag which allows me to obsolete a promotion when the unit goes past a set xp value... Not the best solution.
 
No, I am saying that each promotion will, itself, be worth a certain amount of XP total. So if my unit has 240 XP, then he gains a +3 per turn cap at 20 Promotion, he gets a total of 20 XP from that promotion, bringing him up to 260 XP in 7 turns.
 
A suggestion for WoC Lite. Adding a bSetZero tag. If the tag is 1, then all xml values that have default value are ignored and all that have a non zero value are set to zero.
Example:
Code:
        <CivilizationInfo>
            <Type>CIVILIZATION_BANNOR</Type>
            <bSetZero>1</bSetZero>
            <Leaders>
                <Leader>
                    <LeaderName>LEADER_SABATHIEL</LeaderName>
                    <bLeaderAvailability>1</bLeaderAvailability>
                </Leader>
            </Leaders>


This would remove Sabathiel as Leader of the Bannor. Right now the only way to do this is to use ForceOverwrite which overwrites all modificitaion by other modules.
 
While that would be possible, it would not be enjoyable. You would have to write a copy of ::read(pXML) and the other 2 readpasses which actively looks for specific tags (as in, does nothing if they aren't present, rather than the current of loading a default in those cases). Failure to find the tag would result in doing nothing, success at finding it would overwrite the original data to remove the element, if present. That also means you need to have the pClassInfo or whatever copyNonDefaults had chosen to call it, available at the time as well so that you can immediately query it and overwrite where needed, and of course you have to write set functions for most of the arrays, as typically they only offer get functions right now.


So yes, possible, and probably quite useful. Just... Lots of time investment required too :( Though that is the point of the current rebuild, invest the time to get an optimal basis. Still... lotta work ;)

EDIT: Oh, and of course you would have to have written the catch to trigger these new functions inside of the CvInfos basic accessor, forget what it was called, where you read in that the boolean for this tag is set. So that means adding a flag to all of the other read statements which will indicate that the normal read method should stop, and that the CvXMLLoadUtilitySet function which is processing the XML needs to use the new functions instead of the old. Since there is already a return value in the ::read(pXML) functions, that means you need to do it with a passed variable and permission to modify that variable, or swap from Boolean return to INT return.
 
yeah, it's probably not worth the time unless you find an easy way to implement it.
 
If you do not care about how a folder's contents load, you include a blank MLF (as we have done inside the Modules/NormalModules folder, as well as a few others). This last step is vital, as a folder which contains no MLF file at all will not load any deeper into the folder structure (but it will load XML within that folder itself).

This can be exploited to remove a module from loading without removing the full contents, just delete the MLF in the folder above it. But if there are multiple modules in the same folder and you want to stop loading only one of them, then you can edit the MLF to state that you wish not to load that Module (just by changing a 1 to a 0). Mostly it will be the Module Makers who worry about MLF files, and the Module Adicts who have so many of them and for some reason decide to see what life is like without one or two ;)

I don't think this is an accurate description of the MLF system.

First of all, you don't need a blank MLF in the folder above in order for the folder to load. My module Golem Workshops works fine without it.

Secondly if there is a blank MLF in a folder above the module folder, module specific MLFs doesn't work. This is really bad since it means that no module can control it's own load order unless an existing file is modified when the module is installed.
 
Are you sure that the final MLF located before your Golem Workshops isn't a blanked one? I had wanted to just not include any MLFs at all and let it all fly, but testing had shown that if I have an MLF which specifically states a folder name, then any folders within that (barring another MLF also being contained in it) will fail to load.
 
Are you sure that the final MLF located before your Golem Workshops isn't a blanked one? I had wanted to just not include any MLFs at all and let it all fly, but testing had shown that if I have an MLF which specifically states a folder name, then any folders within that (barring another MLF also being contained in it) will fail to load.

The structure of that module is that all the xml is in a subfolder: Golem_Workshops/base_mod .
There is also an art folder (Golem_Workshops/art) and a plain textfile in the Golem_Workshops folder. No MLF at all in the module.

I tested by placing it in NormalModules, loaded ok despite being more than one folder deep.

Then in LoadOrderVitalModules with no other changes. It didn't load, which it shouldn't since the MLF in LoadOrderVitalModules doesn't name it to be loaded.

Then I added it to be loaded last in LoadOrderVitalModules and it loaded ok. There are no blank MLF in any parent directory, but there are in all siblings which were loaded before Golem_Workshops.

That's not important though, just not the behaviour described in the first post.

---

What is important is that if there is a blank MLF in any parent directory, that overrides any that should control the mod itself.

I just thought of something: Since blank MLFs are not needed to load subdirectories, maybe removing them altogether will allow custom MLFs to work.


edit:
I don't have any problem with Golem Workshops, I just used that as an example since it works despite the description in the first post.

My actual problem is another mod where I want to use a MLF to turn off parts of it.
 
Question for you... Trying to add a new barb faction (Frostlings, for the White Hand). There's a reference to RANDPLOT_(CIV HERE) for all the existing factions... Looking at the file they are defined in, it reads:

Code:
#define RANDPLOT_EVIL			(0x00000080)
#define RANDPLOT_ORC_ALLY		(0x00000100)
#define RANDPLOT_ANIMAL_ALLY		(0x00000200)
#define RANDPLOT_DEMON_ALLY		(0x00000400)
#define RANDPLOT_NOT_IMPROVED		(0x00000800)
#define RANDPLOT_WATER			(0x00001000)
#define RANDPLOT_UNOCCUPIED		(0x00002000)

I'm hoping the following addition works?

Code:
#define RANDPLOT_EVIL			(0x00000080)
#define RANDPLOT_ORC_ALLY		(0x00000100)
#define RANDPLOT_ANIMAL_ALLY 		(0x00000200)
#define RANDPLOT_DEMON_ALLY 		(0x00000400)
[B]#define RANDPLOT_FROSTLING_ALLY		(0x00000800)[/B]
#define RANDPLOT_NOT_IMPROVED		(0x00001000)
#define RANDPLOT_WATER			(0x00002000)
#define RANDPLOT_UNOCCUPIED		(0x00004000)
 
Cases where people actually want to turn things off were a "fringe" in my mind since I wasn't sure that people would ever reach a point of being comfortable editing the MLF files and thus using that ability. So in those cases I am fine with people needing to get a tad more inventive, as it ensures that they learn the system :p

That said, if the blanked MLFs are not required, I will more than happily not include them in future releases. Try plucking them out and seeing if you notice any errors as a result. I do not recall the precise scenario that led me to deciding they were required, but I do know that it took a little bit of time to figure out a way to set them up that allowed things to work for whatever the test scenario was that I had utilized.

Valk: Yes, that should work, the important thing is that they be binary shifts from one another (1,2,4,8) as I recall. Changing the order shouldn't matter since outside of that one location everything is referenced by name, not number, so it is self-updating.
 
Valk: Yes, that should work, the important thing is that they be binary shifts from one another (1,2,4,8) as I recall. Changing the order shouldn't matter since outside of that one location everything is referenced by name, not number, so it is self-updating.

That's exactly what I hoped, good. May be back with more questions later on. ;)
 
Cases where people actually want to turn things off were a "fringe" in my mind since I wasn't sure that people would ever reach a point of being comfortable editing the MLF files and thus using that ability. So in those cases I am fine with people needing to get a tad more inventive, as it ensures that they learn the system :p

I have no problem with things being obscure, as long as they are obscure for the mod-maker. Installing and using the mod needs to be as simple as dropping the mod in some directory, which it isn't currently since one must modify a MLF that already exists on the users computer.

The only way to achieve a 'one-click' installation that respects MLF is currently to make an installer and write a script to modify the existing MLF.

And turning off parts of a mod isn't a fringe use-case. Optional parts of a mod, different versions for different game speeds, or variant difficulty modes.
 
The only way to achieve a 'one-click' installation that respects MLF is currently to make an installer and write a script to modify the existing MLF.

Not even that necessarily works; things could get ugly if your modules needed to be at the TOP of the list, instead of appending them to the bottom. MLF files have proven incredibly useful to me, and at the same time, the source of several errors...
 
Not even that necessarily works; things could get ugly if your modules needed to be at the TOP of the list, instead of appending them to the bottom. MLF files have proven incredibly useful to me, and at the same time, the source of several errors...

Well, if you're making a script to modify the xml anyway; why would it be any more difficult to append to the start of the list?
 
Well, if you're making a script to modify the xml anyway; why would it be any more difficult to append to the start of the list?

Okay, maybe that was a bad scenario. But what if you need to be before element X, but after element Y?

I just gave up on making a script myself, and created a universal MLF, that had every conceivable entry in it.
 
Alright, I've changed the PrereqCivilization tag in projects to an array, so I can list multiple civs (Needed for the Illian/Frozen rituals). The tag itself is working, but I can't get it to display correctly.... What am I doing wrong here?

To clarify, any project which has the prereq fails to show in the pedia, and it pops up a python error on line 321 of PediaMain, in def placeFilterSort... It's the line that adds icons to the display.

Code:
    int iNumPrereqs = kProject.getNumPrereqCivilizations();
    bFirst = true;
    if (iNumPrereqs > 0)
    {
        if ((pCity == NULL) || !(pCity->canCreate(eProject)))
        {
            szBuffer.append(NEWLINE);
            szBuffer.append(gDLL->getText("TXT_KEY_IMPROVEMENT_PREREQ_CIVILIZATION"));
            for (iI = 0; iI < iNumPrereqs; iI++)
            {
                if (!bFirst)
                {
                    szBuffer.append(gDLL->getText("TXT_KEY_OR"));
                }
                szBuffer.append(GC.getCivilizationInfo((CivilizationTypes)kProject.getPrereqCivilization(iI)).getDescription());
                bFirst = false;
            }
        }
    }
 
First off, why is PrereqCivilization even displayed for a city which cannot construct the Project? It isn't like you'll magically change which Civ you are playing with in that city and thus suddenly become capable of completing the ritual, so it should be blocked outside of the bVisible checks to just never show for those cases, thus doesn't need a text key for those cases either. But I assume that is an issue in the base code which ought to be resolved.


In what way is the display not working? Only displays the first Civ, the last civ, nothing, compiler error... Just be nice to know what I should be looking for, because with a cursory glance it seems fine.
 
First off, why is PrereqCivilization even displayed for a city which cannot construct the Project? It isn't like you'll magically change which Civ you are playing with in that city and thus suddenly become capable of completing the ritual, so it should be blocked outside of the bVisible checks to just never show for those cases, thus doesn't need a text key for those cases either. But I assume that is an issue in the base code which ought to be resolved.


In what way is the display not working? Only displays the first Civ, the last civ, nothing, compiler error... Just be nice to know what I should be looking for, because with a cursory glance it seems fine.

I edited the last post to show what error was popping up.

For a screenie:
 

Attachments

  • Civ4ScreenShot0031.JPG
    Civ4ScreenShot0031.JPG
    155.9 KB · Views: 85
  • Civ4ScreenShot0032.JPG
    Civ4ScreenShot0032.JPG
    167.4 KB · Views: 60
Top Bottom