• We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
Nah, add CK2+'s non-guaranteed Aztec invasions. That way, we can leave the expansions enabled but it's not guaranteed to happen every game. :)

As someone said earlier this is in VIET Immersion, and even better you can customize the chance of an Aztec invasion (whether it's 0, 10, 50, or 100% if I remember correctly), as well as the chances of all horse invasions - separately or together, your preference.
 
I can in theory still maintain VIET's current system of CB restrictions, certainly, and in fact other than VIET's changes to ai weights (how likely the ai wants to use or not use a CB - which I feel is severely underused in PB as a tool to make more mnimalist changes to CB) there isn't a whole lot of changes VIET does to the PB set up at this point, since I already removed much of it (for instance I gave up merging VIET's trait restrictions and just used Meneth, even though I disagreed on small details, because, well, they were just small details and a matter of trait interpretation). It is still though a pain in the ass to continue merging new changes from PB since PB updates pretty quickly and those changes often deal with cbs. We don't lie when Ordep and I usually end up dealing with the CB code last every update because of this. Basically I'm just thinking of ways to save myself time so I can work on other things I find more interesting, and I think Ordep feels the same.

Well, I dunno what I'm rambling here anyways and whether it's even relevant but whatever, we can always continue discussing privately as to not spam this thread of course.

Understandable. If I were you, I'd maximize my manpower efficiency and just straight-up delegate vanilla CBs to PB. Their QA is already a matter of great import to us, and I'm a pretty slick CB coder, honestly. Might as well take advantage of that, as one can't control everything (if one wants to succeed). BTW, the CB ai_will_do overhaul is on my List, although since it only makes any difference as a tie-breaker between two available CBs (as I understand it in practice-- not like decisions where it's literally a mean frequency of consideration), it only really matters for certain CBs that are both commonly available at the same time and where any clear preference can be determined in favor of the AI being smarter. One example is dejure_county_claim vs. religious (former is always picked before the latter due to load order). Of course, there are also times when using an ai_will_do to reflect the trait-based behavior of an AI would be far more preferable and sophisticated than using inflexible trait-based blocks upon both the player and the AI using the CB at all.

I actually fervently wish someone could figure out something better than the trait blocks for CBs. I consider them more or less fine for the AI (perhaps a touch too restrictive?) since they don't care how the game plays, but as a human player they're so broad, sweeping, inflexible, and deterministic that they annoy me. It's become standard practice for me, as a PB+VIET player (though this is an issue for both mods separately, as well), to purposefully get rulers killed if they somehow pick up one or two of the real stinker traits.

I played for a while with a custom variable system which assigned values to traits and every year calculated/updated how "warlike" a ruler would be and then gave a modifier which adjusted their CB access accordingly. It worked, and I liked it (and it had the advantage of making it very obvious what kind of wars you could use), but it was too much of a hassle to keep it working with all the CBs as they got updated and changed.
I'm more or less with you about "broad, sweeping, inflexible, and deterministic" part. I've never liked that aspect since day 1 (see above for ai_will_do being used to *actually* influence AI usage of CBs based upon traits-- and other factors). It is extremely static, and as a player, it just forces me to cheat (the new "remove_trait" console command is handy-- didn't used to be there) to get around it, unless the impact is minor. However, generally not being able to wage any reasonably possible wars for at least 1 generation of play is pretty much always never "minor" and going to result in me hitting the console and feeling a dirty cheat eventually. I'm sure that I'm not alone.

The custom variable system sounds really interesting. I bet maintenance was tough with as verbose/redundant as variable scripting in CKII pretty much always gets due to the lack of variable comparison (just to constants, not other variables) and arithmetic. And CBs are tricky places to be overloading with redundant code. Especially if they affect the can_use and you have overlapping CBs which you need to de-duplicate under certain conditions (so the can_use of one includes the complement of the other, roughly). We might get semi-proper variable support soon, though. Maybe that idea can be revisited...
 
I'm more or less with you about "broad, sweeping, inflexible, and deterministic" part. I've never liked that aspect since day 1 (see above for ai_will_do being used to *actually* influence AI usage of CBs based upon traits-- and other factors). It is extremely static, and as a player, it just forces me to cheat (the new "remove_trait" console command is handy-- didn't used to be there) to get around it, unless the impact is minor. However, generally not being able to wage any reasonably possible wars for at least 1 generation of play is pretty much always never "minor" and going to result in me hitting the console and feeling a dirty cheat eventually. I'm sure that I'm not alone.

The custom variable system sounds really interesting. I bet maintenance was tough with as verbose/redundant as variable scripting in CKII pretty much always gets due to the lack of variable comparison (just to constants, not other variables) and arithmetic. And CBs are tricky places to be overloading with redundant code. Especially if they affect the can_use and you have overlapping CBs which you need to de-duplicate under certain conditions (so the can_use of one includes the complement of the other, roughly). We might get semi-proper variable support soon, though. Maybe that idea can be revisited...

I play mostly multiplayer, so not only is the console stuff not usually an option for me, but of course it only makes getting CBs locked out all the more of a drag.

As for the variable system: I didn't mess with trying to calculate anything in the CBs themselves. I did a maintenance event which ran from on_actions every year and assigned the character a visible modifier which was then used by the CBs to determine what you could do. I wouldn't call it ideal, but I definitely liked the approach in theory. And having the modifier's description tell you what you could and could not do right there was a nice alternative to the War Check decisions.
 
I play mostly multiplayer, so not only is the console stuff not usually an option for me, but of course it only makes getting CBs locked out all the more of a drag.

As for the variable system: I didn't mess with trying to calculate anything in the CBs themselves. I did a maintenance event which ran from on_actions every year and assigned the character a visible modifier which was then used by the CBs to determine what you could do. I wouldn't call it ideal, but I definitely liked the approach in theory. And having the modifier's description tell you what you could and could not do right there was a nice alternative to the War Check decisions.

Ah, an MP-player (excuse my redundancy)! I've been looking for one of you! I've never played an MP CKII game in my life, yet I've tried my best to mod with it in mind.

Re: your variable system, if I were to choose between PB's trait blocks and your system, I'd definitely choose yours. Sounds much more elegant and minimalist, frankly. The requirement of a yearly maintenance event does not reduce the minimalism nor the elegance; those things should be judged in terms of what is exposed to the player, ultimately.

Personally, I think a lot of leeway needs to be given to players to allow them to roleplay the game way in the way that feels natural to their personal style. When you start forcing styles of play upon them, esp. in such a drastic way, not only do you severely limit the number of possible outcomes (a set so restricted that it's highly implausible) but also you alienate the player, forcing them to quit, cheat, or bite their tongue and play "your" way. Modding can, I suppose, be about what the author wants players to do, but at least personally, I'd rather make a good mod than a bad one. And a good mod doesn't force the player to kill themselves if they happen to randomly roll "content." To say the least, it breaks immersion.

There are plenty of less arbitrary and deterministic ways to influence the AI's use of CBs, meanwhile.
 
Note that in the next installer release (we're basically just waiting upon NBRT+'s next release to go ahead), we'll be using a much more robust version of the installer itself. One of its features is that it outputs a file called file2mod_map.txt in your installation target folder (usually Historical Immersion Project). The file is sorted in load order and includes exactly the set of files included in your install along with the actual mod that was responsible for contributing the file (which "won" the precedence conflict); it has one filename per line. You will be able to search through this file for whatever filename pattern you want in a text editor and see exactly where it came from.

So will this function also include entries from mods outside of HIP? I hope so, because that will help people like me who run a dozen at once know exactly what is being pulled from where.
 
So will this function also include entries from mods outside of HIP? I hope so, because that will help people like me who run a dozen at once know exactly what is being pulled from where.

I would be very surprised if it did. It should be HIP only as it will tell you when it combines the files for the install. As a general rule - I believe that which loads first gets preference. Thus BLG's files had preference as B loaded before H and caused the issue you saw yesterday. I normally hunt up the list in what I loaded to find the first file of the type (cultures/defines/etc) and then work my way back down the list if it appears there is a problem to find.
 
I would be very surprised if it did. It should be HIP only as it will tell you when it combines the files for the install. As a general rule - I believe that which loads first gets preference. Thus BLG's files had preference as B loaded before H and caused the issue you saw yesterday.

Ah, for some reason I was thinking just the opposite, that as it went through the list the most recent occurrence of a file would be used in place of a previous one. However, that would have made no sense in yesterday's scenario for the reason you stated, i.e. B coming before H. If the way I thought it was working was correct HIP would have completely overridden any files used by BLG.
 
Ah, for some reason I was thinking just the opposite, that as it went through the list the most recent occurrence of a file would be used in place of a previous one. However, that would have made no sense in yesterday's scenario for the reason you stated, i.e. B coming before H. If the way I thought it was working was correct HIP would have completely overridden any files used by BLG.

Frankly that would make a lot more sense. However as my limited modding knowledge tells me - the program logic looks at the mod, sees if a file has loaded - if no, loads the current mods version - if yes ignores the current mods version. Thus why before HIP there were all of the PB + (VIET/SWMH/etc) files that loaded before the main body of PB. The blend versions needed to load with precedence.
 
Frankly that would make a lot more sense. However as my limited modding knowledge tells me - the program logic looks at the mod, sees if a file has loaded - if no, loads the current mods version - if yes ignores the current mods version. Thus why before HIP there were all of the PB + (VIET/SWMH/etc) files that loaded before the main body of PB. The blend versions needed to load with precedence.
Load order for the compatches was ensured using dependencies, not based on name precedence.
Name precedence works in a rather arcane way, so I never bothered to look into it, so I'm not entirely sure what takes precedence there.
 
So will this function also include entries from mods outside of HIP? I hope so, because that will help people like me who run a dozen at once know exactly what is being pulled from where.

Not this function. Such a tool could be written that would include external mods, though, for people like you.

I would be very surprised if it did. It should be HIP only as it will tell you when it combines the files for the install. As a general rule - I believe that which loads first gets preference. Thus BLG's files had preference as B loaded before H and caused the issue you saw yesterday. I normally hunt up the list in what I loaded to find the first file of the type (cultures/defines/etc) and then work my way back down the list if it appears there is a problem to find.

Ah, for some reason I was thinking just the opposite, that as it went through the list the most recent occurrence of a file would be used in place of a previous one. However, that would have made no sense in yesterday's scenario for the reason you stated, i.e. B coming before H. If the way I thought it was working was correct HIP would have completely overridden any files used by BLG.

Frankly that would make a lot more sense. However as my limited modding knowledge tells me - the program logic looks at the mod, sees if a file has loaded - if no, loads the current mods version - if yes ignores the current mods version. Thus why before HIP there were all of the PB + (VIET/SWMH/etc) files that loaded before the main body of PB. The blend versions needed to load with precedence.

Load order for the compatches was ensured using dependencies, not based on name precedence.
Name precedence works in a rather arcane way, so I never bothered to look into it, so I'm not entirely sure what takes precedence there.

Yes, HIP load order is roughly based upon name load order for historic reasons, but it since it can do arbitrary ordering with its compatch logic, it needs something like file2mod_map.txt (or understanding Python and reading the compatch logic in the installer).

General name load order: actually, the highest lexicographic (i.e., - < 0 < 9 < A < Z < a < z) mod name (in the launcher) wins when a file conflicts / needs to be replaced. [NOTE: This sentence's trailing statement about which file "wins" is highly misleading, and I'd even just call it incorrect, insofar as the definition of "winning" would imply. The lexicographical ordering, however, is still correct. See my follow-up post for a detailed explanation and correction.] However, any dependencies explicitly listed in a mod's .mod file (probably the case for the BLG compatch) override the lexicographic ordering. Also, sometimes a conflict occurs NOT on the same file but instead on redefinition the same ID (be it a culture or an event) by different files included by different mods. In this case, file load order (which occurs in the same lexicographic ordering) controls which mod's definitions will "win." Some things can't be overridden this way and just produce errors, though, but most can.

Note that file2mod_map.txt sorts all the files in the installed HIP mod by the engine's file load order in any given directory, so if there are multiple definitions of the same thing included, the file occurring later down the list in the same directory will override the earlier one.

EDIT:
In the past, I already wrote a program that parses all the .mod files in a mod folder (their names and their explicitly-listed dependencies, if any), takes a selection of them, and then displays the fully-resolved mod load order (considering both lexicographic ordering and explicit dependency listings and how they interact when there are still "ties"-- it requires a modified version of a basic graph theory algorithm called topological sort) as well as allows you to query for a file and see which mod it would've come from as well as the other mods, in order of precedence, that would have provided the file had the top mod not been selected.

I would not be opposed to making a more formal program out of this (rewrite it) someday and releasing it to the CKII / EU4 communities. And I'd make it aware of HIP's compatch logic so that it could distinguish HIP's individual mods too.
 
Last edited:
Not this function. Such a tool could be written that would include external mods, though, for people like you.

Hopefully, there aren't too many people like me who consistently make problems for themselves by trying out any new goodie that catches my eye.

General name load order: actually, the highest lexicographic (i.e., - < 0 < 9 < A < Z < a < z) mod name (in the launcher) wins when a file conflicts / needs to be replaced.

Is Z considered "higher" than A? If so, this is the opposite of MFCamillus is saying and a mod called Zebra would overwrite files from a mod called Apple.

EDIT:
In the past, I already wrote a program that parses all the .mod files in a mod folder (their names and their explicitly-listed dependencies, if any), takes a selection of them, and then displays the fully-resolved mod load order (considering both lexicographic ordering and explicit dependency listings and how they interact when there are still "ties"-- it requires a modified version of a basic graph theory algorithm called topological sort) as well as allows you to query for a file and see which mod it would've come from as well as the other mods, in order of precedence, that would have provided the file had the top mod not been selected.

I would not be opposed to making a more formal program out of this (rewrite it) someday and releasing it to the CKII / EU4 communities. And I'd make it aware of HIP's compatch logic so that it could distinguish HIP's individual mods too.

I would not be opposed to you not being opposed to making a formal program out of this. I think I'll become a modder since no one wants to hire me to become a developer.
 
Hopefully, there aren't too many people like me who consistently make problems for themselves by trying out any new goodie that catches my eye.
There are.

Is Z considered "higher" than A? If so, this is the opposite of MFCamillus is saying and a mod called Zebra would overwrite files from a mod called Apple.

I'm sorry. While what I described is correct lexicographical order, I neglected to mention that mod and file precedence/load order is in ascending lexicographical order by name (barring any explicit dependencies specified in the .mod file). Therefore, since A < Z, A comes before Z. For mod file replacement, that means Apple's files beat Zebra's. For file load order, that means Apple.txt is loaded before Zebra.txt (and thus, if Zebra.txt defines an event w/ ID=42 which Apple.txt also defined, Zebra.txt will overwrite the in-memory definition of event ID 42 w/ its definition). To give a specific, real-world example that extends the concept to full names:

Note that PB VIET Events has always overridden the files of ProjectBalance, despite neither using an explicit dependency declaration in their .mod files. Why might this be? Well, let's do a lexicographical comparison of the two names, sorting in ascending order (lowest values first-- descending order would just be the reverse):
  1. Compare first character of both names.
    • They're both P, so they're actually equal right now. Proceed to next character to search for a tiebreaker.
  2. Compare second character of both names.
    • Since B < r (lowercase letters have the highest values), we terminate with PB VIET Events < ProjectBalance
Therefore, the files of PB VIET Events will win all precedence conflicts with the files of ProjectBalance. In this case, the only reason why a special PB-version of VIET Events exists anyway is to provided a pre-merged common/on_actions/00_on_actions.txt, one of the few types of CKII files that can't be just split up into mod-specific filenames (as, e.g., events or traits can) and be allowed to use regular inter-mod filename precedence to override the conflicting parts only (it'd be a few random chance weight tweaks that differ between the two if the file could be factored-out properly, about a 5-line diff).

You could also think of this as the set of files in mod B being loaded before the set in A, then the set in A is copied over the set in B to create a merged set that prefers A's files to B's. If you want to think of it that way, that is also OK, because it turns out that a file-set merge in descending lexicographical order by mod name is equivalent to a per-file conflict resolution strategy that always prefers the lowest [ascending] lexicographic-ordered mod names' files to to higher-valued mod names' files. This is a property of the definition of what one might think of as an "iterative, ordered file-set merge." However, it really is an ascending order conflict resolution strategy and not an actual merge of files, hence it is consistent with the way Paradox loads files too.

I would not be opposed to you not being opposed to making a formal program out of this. I think I'll become a modder since no one wants to hire me to become a developer.
Become a modder because you like modding, obviously. :p
 
Last edited:
There are.

[/LIST]Therefore, the files of PB VIET Events will win all precedence conflicts with the files of ProjectBalance. In this case, the only reason why a special PB-version of VIET Events exists anyway is to provided a pre-merged common/on_actions/00_on_actions.txt, one of the few types of CKII files that can't be just split up into mod-specific filenames (as, e.g., events or traits can) and be allowed to use regular inter-mod filename precedence to override the conflicting parts only (it'd be a few random chance weight tweaks that differ between the two if the file could be factored-out properly, about a 5-line diff).

You could also think of this as the set of files in mod B being loaded before the set in A, then the set in A is copied over the set in B to create a merged set that prefers A's files to B's. If you want to think of it that way, that is also OK, because it turns out that a file-set merge in descending lexicographical order by mod name is equivalent to a per-file conflict resolution strategy that always prefers the lowest [ascending] lexicographic-ordered mod names' files to to higher-valued mod names' files. This is a property of the definition of what one might think of as an "iterative, ordered file-set merge." However, it really is an ascending order conflict resolution strategy and not an actual merge of files, hence it is consistent with the way Paradox loads files too.

And this is the actual case that made me think it was that way... I didn't realize some of them could be split. I thought if you were going to split it you had to put in a separate file e.g. jordarkelf_events..... I knew dependencies could override it, but outside of groupings like HIP (which pre-merger did do it) most mods don't tend to write in dependencies for each other.

And I'll second Finarfin's comment. Watching your explanations here and on Git have taught me a ton in the last few months and challenged me to try more. Actually - challenging my daughter now too. Though I'm making her wait for summer break before we try to write the pre - 1066 event/balances we have thought of.
 
And this is the actual case that made me think it was that way... I didn't realize some of them could be split. I thought if you were going to split it you had to put in a separate file e.g. jordarkelf_events..... I knew dependencies could override it, but outside of groupings like HIP (which pre-merger did do it) most mods don't tend to write in dependencies for each other.

And I'll second Finarfin's comment. Watching your explanations here and on Git have taught me a ton in the last few months and challenged me to try more. Actually - challenging my daughter now too. Though I'm making her wait for summer break before we try to write the pre - 1066 event/balances we have thought of.

Not entirely sure what you mean by 'split': But I think I understand. Yeah, to split a file of vanilla's (or upstream mod's), you need to first replace the upstream file to be split with an empty file. Then, there won't be multiple definitions when you break out the content into separate mod- or topic- specific files. PB's common/cb_types/00_cb_types.txt split is a good example of this. A similar but slightly quirky example is how plain PB's landed_titles.txt is split into multiple files. In this case, certain titles (e.g., titles that have a head of religion) must remain in landed_titles.txt for some stupid reason. All the rest are taken-out and split de jure by empire with titular titles in a small collection of files as well.

I will note that the PB/SWMH/PB+SWMH interaction is a complex thing to analyze in terms of what we've been discussing. There are multiple explicit dependencies in use and multiple cases of emptying-out and redefining files before they ever see the light of day. E.g., PB+SWMH unsplits what plain PB did to landed_titles.txt by emptying-out the topic-specific files and allowing landed_titles.txt to be overridden by SWMH in the normal, monolithic fashion.

Regarding the props, thank you. I have a tendency to be too detailed sometimes, but I think that's somewhat a product of my technical job and educational/teaching background. The advantages to such a style of writing pretty much only apply to technical topics. Even then, that's only when your audience wants to understand the topic you're explaining. :D

I'm glad that you're watching git and even more delighted to hear that you have a daughter that you've apparently raised-up as a Paradoxian and a tinkerer (and that you guys plan to do projects together, no less). That's really special.

Gotta say, z, I love your in-depth explanations of things. Does that make me a masochist?
Yes. When you choose to follow me down the rabbit hole, it will almost always be educational or generate new ideas for both of us, though. When you don't choose, well, that's more like me being a sadist. ;)

Rabbit Hole Alert:

If my nickname were a mod (it is), I'd have to be almost perfectly explicit about all my possible dependencies, because just about everything would take higher precedence. This is what I want, because I always explicitly list my dependencies for those mods I knowingly override; if I'm trying out a new, random mod, I don't want to run the risk of silently overriding some of their files (likely making the mod break or its important features never work right). I'll know full well if my own functionality was overridden, but at least the mod I'm trying will work properly.

Here's where it gets truly geeky (what? you said you might be a masochist!):

The name of my personal mod is actually ~z, however. Why? Among the symbols directly accessible via a keyboard, only the tilde (~) has a higher ASCII/byte/lexicographic value than lowercase z. That guarantees I override no mod implicitly (unless they started with two tildes-- then, I'm in trouble). Indeed, the tilde is actually the absolute highest-valued ASCII character (with a byte value of 0x7F, or 127 in decimal). All of the rest of normal punctuation characters are either between or below the digits, uppercase, and lowercase sets (making each one serve a different purpose in such an ordered scheme). Lot of tricks can be performed with the tilde. Among other places, you'll see it used in software version numbers (version strings must be capable of automatic comparison to each other).

The ASCII subset in Windows' Character Map utility shows all printable characters (i.e., the visible ones) in order from lowest to highest. You can always use that as a guide to figuring-out mod or file load orders-- particularly when punctuation is involved-- as it really does come up a lot in intelligent modding and/or troubleshooting.

No, that's Ziji! :p
Aye, 'tis z.


Pop Quiz:
What happens when one mod or file name is a prefix of another? Which comes first (the lowest lexicographic value)?
Example:
We've got two mod versions named: MFCamillus and MFCamillus-NorseExtensions

They overlap in the files they override big time, as you might imagine. Which one's files will take precedence over the other? Why? Note that I haven't actually explained this quirk, but it is quite easy to intuitively derive. And, of course, there's an easy way to cheat (but not on the why). :p
 
Last edited:
Pop Quiz:
[/COLOR]What happens when one mod or file name is a prefix of another? Which comes first (the lowest lexicographic value)?
Example:
We've got two mod versions named: MFCamillus and MFCamillus2.0

They overlap in the files they override big time, as you might imagine. Which one's files will take precedence over the other? Why? Note that I haven't actually explained this quirk, but it is quite easy to intuitively derive. And, of course, there's an easy way to cheat (but not on the why). :p

Here's my thinking: The first part of both names are the same. Then one of them has a 2 where the other one has nothing (null). The one with the null is going to be read first and therefore any files it contains will have precedence over MFCamillus2.0. My whole reason is based on the assumption that the ASCII value of Null is considered in the name comparison.
 
Regarding the props, thank you. I have a tendency to be too detailed sometimes, but I think that's somewhat a product of my technical job and educational/teaching background. The advantages to such a style of writing pretty much only apply to technical topics. Even then, that's only when your audience wants to understand the topic you're explaining. :D
Speaking as a manager, accountant, and Project Manager - no such thing as too detailed.



Pop Quiz:
[/COLOR]What happens when one mod or file name is a prefix of another? Which comes first (the lowest lexicographic value)?
Example:
We've got two mod versions named: MFCamillus and MFCamillus-NorseExtensions

They overlap in the files they override big time, as you might imagine. Which one's files will take precedence over the other? Why? Note that I haven't actually explained this quirk, but it is quite easy to intuitively derive. And, of course, there's an easy way to cheat (but not on the why). :p

LOL I like pop quizzes that change between the time I look at it on my tablet and come to the computer......

I have to assume (but boy does that make me leery) that MFCamillus ends with either a null or a space. Both of which come before - (being item 45 in ASCII). So it would be MFCamillus MFCamillus2.0 MFCamillus-Extended MFCamillus-NorseExtentions. (just to cover all the versions I've seen) But frankly that is also basically a DB sort order....
 
Speaking as a manager, accountant, and Project Manager - no such thing as too detailed.
Good. Then we'll get along. :D

MFCamillus said:
LOL I like pop quizzes that change between the time I look at it on my tablet and come to the computer......
As you found, none of the changes altered the answer or the order. I just renamed it to make it more realistic; it's quite common to have a parent mod and then sub-mods with the same prefix (or a mod and a related compatch mod). Unfortunately, given the answer, the default won't give the expected behavior of a sub-mod, to override its parent.

I have to assume (but boy does that make me leery) that MFCamillus ends with either a null or a space. Both of which come before - (being item 45 in ASCII). So it would be MFCamillus MFCamillus2.0 MFCamillus-Extended MFCamillus-NorseExtentions. (just to cover all the versions I've seen) But frankly that is also basically a DB sort order....

Here's my thinking: The first part of both names are the same. Then one of them has a 2 where the other one has nothing (null). The one with the null is going to be read first and therefore any files it contains will have precedence over MFCamillus2.0. My whole reason is based on the assumption that the ASCII value of Null is considered in the name comparison.

I wouldn't do any underhanded trickery like ending with a space. Both of your logic is correct, though. One can either think of it pragmatically or theoretically.

Theoretically, the "character" that follows the end of the prefix is epsilon, the "empty string." There are an infinite padding of those after both strings, making them equal width but differing in the extra characters of the longer version. The empty string is always the lowest value, because it doesn't exist.

Pragmatically, such strings are usually stored in memory as an array of bytes with a terminating 0-valued byte at the end (which ASCII annoyingly calls the NUL character, as if it were actually a character, but hey, it's better than epsilon, right?). The zero-sentinel is there so that algorithms can traverse the bytes directly in memory without accounting for their current location relative to the start. Losing you? It's OK, because the point's obvious: if you just considered the NUL character as part of the string, then any string sorting/comparison algorithm would terminate as soon as it compared 0x00 to any other possible character value. Hence, shorter always wins.

IOW, success. That must have been way too easy.