Mod-Modders Guide to Fall Further

Valkrionn said:
In case you didn't see this: Where exactly do you add this to the files? Just where you list the tags located in the XML file, or next to any content="eltOnly"?
Click to expand...

Probably just in any element tag which have children you want this behavior out of. Which is probably most info tags.

Great find xien!


Do you need to use this method of setting a default in the c++?
Code: 
pXML->GetChildXmlValByName(&m_iMaxAnarchy, "iMaxAnarchy", [B][COLOR=Red]-1[/COLOR][/B]);
I had to do this when I set minOccurs on such entries.
 
The ::read ::write in CvInfos are only used for verification of a savegame when you have the Lock Modified Assets option enabled, so not EVERYTHING saves, just the major items. I am only 60% certain on that though, as I haven't checked by finding something like religions and changing them in a Locked savegame.

GreyFox is right that you just place the sorting rule on anything that you want to be order independent. I've already modified the schema in our SVN, pretty sure you have access to that if you want them.

And yes, you need to specify default values in the DLL if you have a non-zero default value required. Unfortunately you cannot just specify the defaults in the schema because we use element containers.
 
xienwolf said:
The ::read ::write in CvInfos are only used for verification of a savegame when you have the Lock Modified Assets option enabled, so not EVERYTHING saves, just the major items. I am only 60% certain on that though, as I haven't checked by finding something like religions and changing them in a Locked savegame.

GreyFox is right that you just place the sorting rule on anything that you want to be order independent. I've already modified the schema in our SVN, pretty sure you have access to that if you want them.

And yes, you need to specify default values in the DLL if you have a non-zero default value required. Unfortunately you cannot just specify the defaults in the schema because we use element containers.
Click to expand...

Makes sense about the ::read ::write stuff... Didn't know that.

Yeah, I'll grab them from the SVN. :p I have read access, not write, but it works.

:blush: Up until last night, I actually assumed the 'minOccurs' line was the default. Then I tried to set it to -1 for the 'AlignmentShiftTowardsNeutral' tag, as I need 0 to be non-default for it... Didn't work so well. :lol: At least I'd already known you had to specify it in the DLL too. :lol:
 
pLoopUnit is a CvUnit* object, so you can treat it just as you would treat a more typically named pUnit. pLoopUnit->get___()
 
CvInfos section for units is part of GC.getUnitInfo(eUnit), CvUnit is a VERY different thing. If you do get a UnitInfo object, then you need to use a . instead of a -> as well, due to the type of object it is.
 
Ah... So where would I set these tags then? Do I need to add calls to CvUnit, that return the tags from CvInfos?

Edit: Or is there a way I can loop through the units you possess and return a UnitInfo object?

Edit2: Nevermind, I can apparently use pLoopUnit->getUnitInfo().getAlignmentShiftModifier(). Haven't tested it yet, but adding the bold section allows it to compile so we'll see.

Edit3: Yep, works. ;) Just need to edit GameText now, and then figure out how I'm going to handle events. :lol:
 
The only reason it might be worthwhile to have a function that points from CvUnit to CvInfos would be if you area going to allow promotions to modify a per-turn alignment modifier for units. Then you can load the promotion data into the Unit, add the UnitInfos to the promotion data, and process it from CvUnit.

You could also use the ::initUnit and ::kill functions to add/remove the alignment shift information to the player so that he can track it and you don't need a loop over all units at all. May help with speed.
 
xienwolf said:
The only reason it might be worthwhile to have a function that points from CvUnit to CvInfos would be if you area going to allow promotions to modify a per-turn alignment modifier for units. Then you can load the promotion data into the Unit, add the UnitInfos to the promotion data, and process it from CvUnit.

You could also use the ::initUnit and ::kill functions to add/remove the alignment shift information to the player so that he can track it and you don't need a loop over all units at all. May help with speed.
Click to expand...

I'm not planning on allowing it on promotions. A shift, rather than set amount, is rather powerful when you can spam it... It'll already be rare among buildings, virtually non-existent among units.

As for adding it to the player... The issue with that, is I can't have it deactivate when you reach the cap for it's alignment. ;)

Question for you: Am I right about what the following bit of code does?

Code: 
iAlignmentShiftDecay = ((int)sqrt((float)(abs(iAlignmentShift))));

The way I see it, it takes the absolute value of iAlignmentShift... Converts it to a float, gets the sqr root, converts the result of that to an int, and then sets the result to the new variable. How far off am I here?
 
You are right with the equation
 
Finally took a quick gander at your code, and all I can say is that is a LOT of looping :) It might be better to actually load things into the player, but do it as a paired list. You'd have to set up a Struct for this. They aren't actually that hard to deal with though, and can save you a LOT of time and effort in dealing with this I think.

Anyway... seems like what you have written should do decently well, but it is hard to be certain while trying to read the code in the format of googledocs (I suppose I could copy/paste to VS, but it looks decent)
 
Yeah, lots of loops. I couldn't think of another way to do it that would allow both A)Store the shift and cap together, and B)If you go back below(or over) the cap, it comes back into effect.

Not sure the paired list would do the second one, there.

Yeah, googledocs doesn't work with C++ very well. :lol: Grey Fox post this (//statement ? true : false ;), let me get rid of a few if checks. I also changed the last bit of code, fixed the decay/storage rate...

Not sure if it's the way you guys intended to do it, but I set it so that the sqr of the current total shift (exact amount is done via a global define) is taken out of per-turn shift each turn. Makes it more difficult to reach large shifts. At the same time, though, every few turns a portion of that total shift is stored in a new variable... This one is immune to the decay. Means that the farther you get from the base alignment, the slower it is... But you can still get there. ;)

As of now I'm fairly satisfied with the mechanic. Needs actual values/balance work, but that will come after the next phase of my expansion.... :mischief:

Edit: Updated the GoogleDocs code.

My last post, btw, was related to the global defines for the decay/storage rates.... The values in xml were floats, but I was calling them as an int. :blush:
 
Paired list would work flawlessly IMO, could add a boolean tracker as well and do something like this:

Code: 
bool bFinished = false; // Tracker Flag to indicate that the loop should stop
while !bFinished
{
    bool bChangeApplied = false;  // Tracker Flag to indicate we have applied a new item
    //Insert proper command to iterate over your list, can never remember the format
    {
        if (abs(loopShift.AlignShiftModifier + getBroadAlignment()) < abs(loopShift.AlignShift))  //Note that this PRECISE format would not work well, as an evil spell with a limit of -300 would not effect a good player who is sitting at +450)
        {
            changeBroadAlignment(loopShift.AlignShiftModifier);
            loopShift.bApplied = true;
            bChangeApplied = true;
        }
    }
    if !bChangeApplied
    {
        bFinished = true;
    }
}

//Again, iteration command to go over the full list
{
    loopShift.bApplied = false;  // Reset all flags to prepare for next turn application
}


This would result in any shift which is too large to apply fully simply never being applied, BUT all net shifts other than that one heavy hitter would still apply (if I am 1 away from the 300 limit on a shift of 2, that one is skipped, but if on the next cycle through I am 3 away from that 300 limit, this time it IS applied)


Should work fairly flawless.


And don't worry about doing the alignments in the same way that we plan to do it. You are WAY off ;)
 
Makes me really wish I could see the plans. :lol:

As for what you proposed... Honestly, for now I'll stick with what I have. Mostly because it's code that I understand. :lol: May rewrite it eventually (taking C++ over the summer, now that I'm back in school, advanced C++ in the fall), but for now it works, works the way I want, and I'm happy with it.

Edit: Also, after having a look through the Wiki, it appears you may have planned what I'm already doing in the second phase? You need to get on #Erebus more, most of the people who frequent it know exactly what I'm meaning. :lol:
 
I can imagine that the rough appearance is about the same. :) Tend to have a kid in my arms or be at University, so unfortunately I am not compatible with chatrooms right now :) You'll notice many more short posts and tons of typos on the threads even, those being when I try to respond while holding a child in one hand and a bottle in the other :D Takes like 30 minutes to finish a single line sometimes
 
You must log in or register to reply here.

Similar threads

H
Combat mechanics overhaul tied with the three eras
Replies
4
Views
917
wolverine2112
W
MiRai
Misaligned Commander Promotion Level When Increasing Font Size
Replies
2
Views
225
MiRai
MiRai
D
Civ franchise idea- "spy points"
Replies
2
Views
131
Krikkit1
K
B
Nomadism
Replies
1
Views
408
<Nexus>
<Nexus>
Navelgazer
What are your priorities for Commander Promotions?
Replies
17
Views
951
vorlon_mi
vorlon_mi
Back
Top Bottom