Mod-Modders Guide to Fall Further

Is there a hard cap on number of gameoptions?

I'm adding one that doesn't show up... If I put it before the next-to-last one, it shows up, but the n-t-l, now the last, doesn't show up.

I checked the DLL and NUM_GAMEOPTION_TYPE is GC.getNumGameOptions() which returns NUM_GAMEOPTION_TYPES...
 
I don't think there is any cap, but gameoptions must be added in the DLL. The xml for gameoptions only controls their names and what textkey to use in the game for things like promotions which can have gameoptions as prereqs. Xienwolf tried to move the system to pure xml, but he failed and settled for a hybrid system.

I vaguely recall him saying a couple months ago that he thought he had figured out the proper way to make gameoptions work without needing to define them in the SDK. Since they also said that they are starting over from scratch for their next version I suspect the next release will include the ability to add gameoptions using only xml.
 
Aren't you confusing them with feats? I'm not sure xienwolf ever attempted to move them out from the DLL... They are hybrid since the beginning, irc.

And the thing isn't that it doens't work, it doesn't appear at all, except if I switch it with another gameoption, which then doesn't appear.
 
I don't think there is any cap, but gameoptions must be added in the DLL. The xml for gameoptions only controls their names and what textkey to use in the game for things like promotions which can have gameoptions as prereqs. Xienwolf tried to move the system to pure xml, but he failed and settled for a hybrid system.

I vaguely recall him saying a couple months ago that he thought he had figured out the proper way to make gameoptions work without needing to define them in the SDK. Since they also said that they are starting over from scratch for their next version I suspect the next release will include the ability to add gameoptions using only xml.

Opera is right, you are thinking about Feats. It is absolutely impossible to move gameoptions completely outside of the DLL, unless you remove their hardcoding and make them be customizable like a unitInfo to act on properties instead of strict rules, which would be really bizarre (I suppose you COULD use a getInfoTypeFor each time you try to use them and leave it all outside the DLL that way, but then each time you check one you have to account for the possibility it doesn't exist as well). I had at one point tried to make a parallel system to the gameoptions which would only be toggled by Scenario file or Python commands, but hadn't been successful at it.


In my code, any new options you add MUST come before the Civ Selector. Everything listed after that option is forced to be off. This is the compromise to avoid disabling the saving of gameoptions or requiring players to execute a PLAY NOW game to clear hidden options. Everything before CivSelector is left as visible, everything after is hidden.
 
Yeah, I don't think so; especially since swapping it with another in the XML file makes it visible but hides the other.
 
Swapping it with another XML file? You mean changing the order of the XML entries without changing the order of the CvEnums.h? That just makes it SAY that it is your new option, but it still will ACT like the old/actual one.

You don't accidentally have it set to be invisible maybe? Wouldn't think so as you would likely move that mistake with the rest of the entry when swapping with another in the XML...


Try adding a bunch of junk options, maybe there IS a limit on the screen. But with Kael having removed so many options from the FfH base, I don't find it likely that you exceed what he had used.
 
Xienwolf, the resource bug I PM'd you about exists in Wild Mana as well, so it's likely inherent to the WoC fonts file. Interestingly, rather than taking place once you hit 74 resources it comes in at 73 in Wild Mana... Makes me think there IS a way to control it.

Until that's found though, do you know how to increase the size of the Character line? I'm hoping to get around the bug by the expedient of expanding the line, and duplicating it. That way if it decides to use the second line of icons, they're the same. :lol:
 
Does anyone know what this function does:

Code:
def canDoBrothersInNeed1(argsList):
	kTriggeredData = argsList[1]
	newArgs = (kTriggeredData, )
	
	return canTriggerBrothersInNeed(newArgs)

~This is the pyReq for an event (not eventtrigger) I'm trying to document.
 
Alright... Apparently expanding the fonts file is simple. That much I had working.

However, even when all characters were on the same line, with a duplicate below, the bug STILL OCCURS, switching the exact same font files. Somehow, even though all characters were put on the same line, the same characters are switched. Happiness with the Animal char, on down the line.

To give you an idea of what I did, I've attached a copy of the font file.
 

Attachments

Does anyone know what this function does:

Code:
def canDoBrothersInNeed1(argsList):
	kTriggeredData = argsList[1]
	newArgs = (kTriggeredData, )
	
	return canTriggerBrothersInNeed(newArgs)

~This is the pyReq for an event (not eventtrigger) I'm trying to document.

It calls the function canTriggerBrothersInNeed with a mildly changed argument. Looking at the code I can't figure out why they bothered with that indirection.

I get the feeling that's not what you're wondering though, even if it is the question you asked.

Maybe the question is: "What does the function canTriggerBrothersInNeed do?". Though if it is, I don't know why you wouldn't look at that function instead, it's defined right above the snippet you quoted.

Anyway, the answer to that question is: It checks if two players (defined by the arguments to the function) can trade strategic resources and are at war with a third party. (Details omitted.)

Or it is a general question along the lines of: "How does pyReq in the random event system work?"

It is the name of a python function that gets called to determine if a random event can trigger. It returns False if the event cannot trigger, True otherwise. Note that True does not mean that the event can trigger, just that the pyReq doesn't have any objections.

Or maybe you want to know something else entirely. Precise questions often answer themselves.
 
I didn't notice that it was just calling another function. the names are so similar.
But I guess what I'd really like to know, what difference does this function make to the output of the one it calls. What does that minor adjustment accomplish ?
 
Back
Top Bottom