Requests for new components (and features)

Can I edit the XMLs manually then?
 
Yes, copy them from your BTS installation folder (Assets\XML\Civilizations?). Look for CIV4PlayerColors.xml I think. Copy it to your CustomAssets folder in the same folder structure and edit that copy. Note that with so many players it's hard to give everyone a totally unique color scheme unless you pick your rivals for each game.

If I made BULL expose those attributes for write access, I wonder if it would work to set them as a game starts/loads. Has anyone tried this?
 
I found no CIV4PlayerColors.xml file in that directory. However I opened CIV4CivilizationInfo.xml and found color tags for each civilization in the form of :

<DefaultPlayerColor>PLAYERCOLOR_GRAY</DefaultPlayerColor>

Right now I am searching other files for where the game defines the color in numerical values (hexadecimal or RGB) so I can change them.
 
Yes, copy them from your BTS installation folder (Assets\XML\Civilizations?). Look for CIV4PlayerColors.xml I think. Copy it to your CustomAssets folder in the same folder structure and edit that copy. Note that with so many players it's hard to give everyone a totally unique color scheme unless you pick your rivals for each game.

If I made BULL expose those attributes for write access, I wonder if it would work to set them as a game starts/loads. Has anyone tried this?
Could that be accomplished by adding the attributes to the ini file that BULL can read and apply on start up?
 
Ok found it, the colors are defined in Assets\XML\Interface\CIV4ColorVals.xml in the form of :

<ColorVal>
<Type>COLOR_PLAYER_PALE_RED</Type>
<fRed>0.780</fRed>
<fGreen>0.282</fGreen>
<fBlue>0.239</fBlue>
<fAlpha>1.00</fAlpha>
</ColorVal>

You have to multiply each number by 255 to get the RGB value. It looks like we can change these value to add more contrast (devide the color wheel by 36)... But as you said there will still be colors that are too similar. It would be much simpler and much better if someone could assign colors dynamically at the start of each game, or a each reload.
 
Could that be accomplished by adding the attributes to the ini file that BULL can read and apply on start up?

They would have to be changed on-the-fly as a game starts or loads as this is the point where BUG will see which civilizations are playing.

The easiest to code is to allow the player to rank 16 (MAX_PLAYERS) colors that should be used by whomever is playing in the game. For example, you'd select White, Red, Blue, Green, Yellow, Brown, . . . When the game starts, it gives player 0 (you normally) White, player 1 Red, player 2 Blue, etc.

This is suboptimal as it completely ignores each civilization's standard color. Ideally, you'd specify alternate colors for each civilization as well as group colors that are too similar to coexist in a game. If two civilizations (or the same civ) get picked for a game, it would assign an alternate to one of them. This way the standard colors would be preferred, but similar ones would be barred.

This latter method--while clearly better--has two drawbacks: 1. it's much harder to code the interface, so it may be relegated to an INI, and 2. picking the colors and alternates is no easy task.

The player colors are specified in XML\Interface\CIV4PlayerColorInfos.xml. Each one defines a set of primary, secondary, and text colors to use, and the actual RGBA values for these colors are defined in CIV4ColorVals.xml in the same folder.

I highly recommend that you change the <DefaultPlayerColor> tags in CIV4CivilizationInfos.xml rather than change the definition of the colors themselves. It would be odd to have PLAYER_COLOR_BLUE be off-white. Instead, point each civilization to a new player color. You can add new player colors and color vals if necessary.
 
When the game starts, it gives player 0 (you normally) White, player 1 Red, player 2 Blue, etc.

This is suboptimal as it completely ignores each civilization's standard color.
Honestly? This is not a drawback at all... they are just arbitrary colors that have nothing to do with the associated civs, and I believe randomizing them won't remove anything from the game.

Would it be easy to do a color patch this way?
 
Honestly? This is not a drawback at all... they are just arbitrary colors that have nothing to do with the associated civs, and I believe randomizing them won't remove anything from the game.

Given how our brains work, there definitely is an advantage for civilizations to generally use the same colors when possible. When I see yellow, I know that's Egypt. When I play Unrestricted Leader games it slows me down a lot since I have to constantly check the scoreboard to see which color goes with which player.

Would it be easy to do a color patch this way?

Neither option will be easy, but the first one is considerably easier from a user interface point of view. The first step is to do a quick test to see if it's even possible to change player colors on-the-fly.
 
Neither option will be easy, but the first one is considerably easier from a user interface point of view. The first step is to do a quick test to see if it's even possible to change player colors on-the-fly.

Hopefully we can, I've been getting requests for this feature among my users.

Sidequestion, how hard is it to add a new tab in the BUG panel? Can the panel edit the global defines on the fly?
 
How hard is it to add a new tab in the BUG panel?

It's pretty easy, though I haven't written up documentation for it yet. Off the top of my head you need a few things:

  1. Create a tab module. See any of the Python modules in BUG/Tabs for an example.
  2. Optional: Create translations for the settings that will appear on the tab.
  3. Create translations for the tab name and any labels you use that aren't already options
  4. Add the tab entry to init.xml (yeah I know, this sucks)
Can the panel edit the global defines on the fly?

Global defines? Do you mean the entries in the GlobalDefines[Alt].xml file? With a bit of work you could make that happen, but it won't be easy. Setting an XML value is trivial; hooking that into BUG wouldn't be since I didn't design it that way. Can you not switch it to a normal BUG option?
 
Global defines? Do you mean the entries in the GlobalDefines[Alt].xml file? With a bit of work you could make that happen, but it won't be easy. Setting an XML value is trivial; hooking that into BUG wouldn't be since I didn't design it that way. Can you not switch it to a normal BUG option?

IDK, I don't know how bug options work, and if they can be set in the SDK. I looked for documentation on your BUG panel but didn't see any, and didn't understand how it worked just from the python files.
 
On second thought, you could set up a BUG option to change an XML Global Define quite easily.

  1. Create an option to mirror the XML define.
  2. Write a simple function to push the option value into the XML.
  3. Set the option's <change> element to call that function.
For example, let's make the :yuck: from power into an option (don't try this on-the-fly as it will bork your current game). Here's the <Define>:

Code:
	<Define>
		<DefineName>POWER_HEALTH_CHANGE</DefineName>
		<iDefineIntVal>-2</iDefineIntVal>
	</Define>

Here's the function:

Code:
# MyMod.py

from CvGlobalExtensions import *

def onChangePowerHealth(option, value):
	gc.setDefineInt("POWER_HEALTH_CHANGE", value)

And the configuration XML:

Code:
<option id="PowerHealth" type="int" default="-2">
	<change module="MyMod" function="onChangePowerHealth"/>
</option>

You might also want to create an init function for that module that pulls the current XML value and pushes it into the BUG option. This way it will pick up whatever value is in the XML as the "real" value. It's unlikely the player will modify the INI whereas they might modify GlobalDefines.xml.

In fact, you may just want to make it an unsaved option (outside of the <options> element) so that it only stores the value in the XML and memory--never in an INI file. That's the best route. If I get some free time I'll investigate making this built-in by adding an XML-based option type, but don't look for that any time soon.
 
IDK, I don't know how bug options work, and if they can be set in the SDK.

BULL has functions for getting option values, but not changing them. Given that the DLL doesn't do any interface work, I saw no need for it. Is this something you need to do from the DLL? And here you're talking about BUG options, not XML Global Defines which can of course be accessed from the DLL already.
 
On second thought, you could set up a BUG option to change an XML Global Define quite easily.

  1. Create an option to mirror the XML define.
  2. Write a simple function to push the option value into the XML.
  3. Set the option's <change> element to call that function.
For example, let's make the :yuck: from power into an option (don't try this on-the-fly as it will bork your current game). Here's the <Define>:

Code:
    <Define>
        <DefineName>POWER_HEALTH_CHANGE</DefineName>
        <iDefineIntVal>-2</iDefineIntVal>
    </Define>
Here's the function:

Code:
# MyMod.py

from CvGlobalExtensions import *

def onChangePowerHealth(option, value):
    gc.setDefineInt("POWER_HEALTH_CHANGE", value)
And the configuration XML:

Code:
<option id="PowerHealth" type="int" default="-2">
    <change module="MyMod" function="onChangePowerHealth"/>
</option>
You might also want to create an init function for that module that pulls the current XML value and pushes it into the BUG option. This way it will pick up whatever value is in the XML as the "real" value. It's unlikely the player will modify the INI whereas they might modify GlobalDefines.xml.

In fact, you may just want to make it an unsaved option (outside of the <options> element) so that it only stores the value in the XML and memory--never in an INI file. That's the best route. If I get some free time I'll investigate making this built-in by adding an XML-based option type, but don't look for that any time soon.

I thought about making the wonder limits changable in game. When you say borks up the game, by changing the dirty power amount, what do you mean, specifically?
 
I was speaking specifically of that particular setting. The :yuck: effect of power is added to or subtracted from a city in CvCity::processBuilding(). Any city that already has power when you change this setting will not have its :yuck: value adjusted. If you change the setting and load a game with a bunch of cities that have power, they will not be adjusted. It won't break the game, but it could mess up the cities' :yuck: values.

The only way to fix this would take a lot of work. First, you'd need to store the XML values that are active in the saved game. Second, you'd need to write code to go through the game's data structures, adjusting objects affected by the setting being changed. For example, if you changed the National Wonders per City limit from 2 to 1, you'd have to go through cities and remove extraneous wonders to enforce the limit.

As long as you make it clear that changing the settings may not affect future/loaded games, exposing these settings this way should be okay. The same thing would happen if they changed the XML themselves.
 
EmperorFool said:
That's already in the next release of BULL
Yay!

A couple things that i wished i had in my last game:

Tabs on the spaceship screen to see other civs space progress. The existing display has the civ it dubs to be the "leader", but last night i was watching cathy's ship/tech progress to figure out when to launch (she had every part build except the stasis chamber as she didn't have genetics), and ramesses ninja'd us by launching early with only one engine. Since it's all there in the event log, i should've seen it coming, but when it's more than a 2 horse race it would be nice to have it more readily available.

In the hover info for the scoreboard, having a civs "war with" and "defensive pact with" would be handy, sometimes when a game is just war after war, it's hard to remember who's fighting who without going into the F4 advisor.


Also, a couple ideas in the interest of reducing the overall scoreboard size (this may not be an issue for most, but playing @ 1024*768 it's a big % of the screen on larger maps):

maybe replace the word "DEAD" with a little skull.
Instead of the war and peace icons you could turn a civs score red if they were at war with you, and green if they had a peace treaty with you.

Of course i recognize that the majority probably play at better resolutions, so if people like the icons better no big deal.
 
Tabs on the spaceship screen to see other civs space progress.

That would be nice, yes.

In the hover info for the scoreboard, having a civs "war with" and "defensive pact with" would be handy.

BULL (and the Unofficial Patch) show the War With part, but Defensive Pacts would be a good addition I think.

maybe replace the word "DEAD" with a little skull.

You can leave their score (or zero, I forget what it shows) instead of DEAD, but a skull would be very cool.

Instead of the war and peace icons you could turn a civs score red if they were at war with you, and green if they had a peace treaty with you.

I would prefer not to overload columns like that, especially since I'll never see the end of the "Why is Mansa's score red? Why did it turn green?" questions. :lol:

Instead, I recommend putting in some negative values between some of the columns to move them closer together. Here's my scoreboard Display Order value:

F2W-4M-2S-1V-5C5?EP-4T1UN-2B-2R-2A-2H-2Q*LO
 
Tabs on the spaceship screen to see other civs space progress. The existing display has the civ it dubs to be the "leader", but last night i was watching cathy's ship/tech progress to figure out when to launch (she had every part build except the stasis chamber as she didn't have genetics), and ramesses ninja'd us by launching early with only one engine. Since it's all there in the event log, i should've seen it coming, but when it's more than a 2 horse race it would be nice to have it more readily available.
That would be nice, yes.
Someone was working on such a screen but (IIRC) it never got finished. I'll see if I can dig it out.
 
I've got an idea. "Hide Obsolete Buildings" so they don't clutter up your buildings list. With small screens, it can be painful...
 
I recommend putting in some negative values between some of the columns to move them closer together. Here's my scoreboard Display Order value:

F2W-4M-2S-1V-5C5?EP-4T1UN-2B-2R-2A-2H-2Q*LO

Thanks for that! I had thought to reduce the gaps but once i saw the default was zero i gave up, doh!
 
Back
Top Bottom