[MODCOMP]Tax and Investment slider

[gfurst]

Its not completely clear what is unclear, and I hesitate to tell a real programmer how to read code...

Hehe, I'm not a real programer, relax

What exactly do you wanna do with this, then?

Yeah, i lacked focus yesterday, i guess was just tired.

Yeah, do that. So there should be one tax slider and four investment sliders, then? But since the investment sliders are already present as the default commerce sliders, then you only need to add the new tax slider? Like above the others...? Is the main tax slider available in the city screen or only outside of it? While the investment sliders are only available in city view...?

It is exactly that, adding one new slider above the others, keeping the usual CommercePercent stuff the same. It's just a question of flavor wether to add it to city screen and maybe others(financial screen), but that is less important.

Thanks for the detail of the code, that was illuminating. Just found this

	def updateGameDataStrings( self ):

in the CvMainInterface.py
The way i figured is the previous code serve only to display the strings, while this other updates them(get's information from the object written by the DLL)( i really wouldn't know, the part relating to the percent stuff is almost the same).

So both should be altered for our purpose, just adding bits of code to display one additional slider, or perhaps adding the TaxPercent as a commerce type. The latter could be easier, but may change a lot of other stuff and be unpredictable.

I will ask more on the BUG forums, since they may already have the hang on this stuff.

szOutText = u"<font=2>%c:%d%%</font>" %(gc.getCommerceInfo(eCommerce).getChar(), gc.getPlayer(ePlayer).getCommercePercent(eCommerce))

This is one line inside that updateGameDataStrings. Near the end you can see gc.getplayer.getCommercePercent
This may be how they get the data from the DLL, gc being an general gamecore object passed to the python via memory address.

I'm almost getting out of focus again? , gonna make a jar of coffee, be right back

 

[Baldyr]

I guess you need to make the widget in the SDK in order to display the new slider, then. You might also consider making a new enumerated type (or whatever) in the SDK, alongside with your redesigned CommerceTypes:

CommerceTypes:
-1 NO_COMMERCE_TYPE
0 COMMERCE_TAX
1 COMMERCE_INVESTMENT
2 NUM_COMMERCE_TYPES

InvestmentTypes:
-1 NO_INVESTMENT_TYPE
0 INVESTMENT_GOLD
1 INVESTMENT_SCIENCE
2 INVESTMENT_CULTURE
3 INVESTMENT_ESPIONAGE
4 NUM_INVESTMENT_TYPES

This might not be entirely necessary however, but might help you separate Tax from Investment.

 

[gfurst]

I though about this:

CommerceTypes:

-1 = NO_COMMERCE
0 = COMMERCE_GOLD
1 = COMMERCE_RESEARCH
2 = COMMERCE_CULTURE
3 = COMMERCE_ESPIONAGE
4 = NUM_COMMERCE_TYPES
5 = COMMERCE_ESPIONAGE

By only adding one more commercetype( maybe put it before num_commerce_types), it could be possible to use a lot of existing code without a lot of tweaking, for example the interface thingy would already add the slider, since it iterates between all CommerceTypes.

However this may cause undesirable effects, i would have to look everything that uses commercetypes to make sure they are not doing anything wrong. Got it?

Instead, i think it would better to(break)

	int* m_aiCommercePercent;
	int* m_aiCommerceRate;

Both above are arrays that keeps data from the CvPlayer scope( each player), they range commerce types ( 0 - 3).

(unbreak) better to add another variable:

	int* m_aiCommercePercent;
	int* m_aiCommerceRate;
	int m_aiTaxPercent;

to the player scope... the lack of '*', is because it is not an array.
In this method would work also and i wouldn't need to mess with the commercetype enum.

enum CommerceTypes					// Exposed to Python
{
	NO_COMMERCE = -1,

	COMMERCE_GOLD,
	COMMERCE_RESEARCH,
	COMMERCE_CULTURE,
	COMMERCE_ESPIONAGE,

#ifdef _USRDLL
	NUM_COMMERCE_TYPES
#endif
};

I found this, declaration of CommerceTypes, i don't know exactly how it works( this enum struct), so I'm still not comfortable changing it.
Maybe just adding something there could be easier, i don't know, that’s my dilemma.

Anyway thanks for the input, but i don't think the way you proposed would be feasible, did you understand why?

 

[Baldyr]

Yeah, you probably should keep things simple. I'd actually suggest you check if any code uses NO_COMMERCE_TYPE and if its not actually used you can use the -1 value for the new Tax commerce type. Then the present code should still work and you would be able to access the new commerce type with ease.

But I guess any setup will do. As soon as you get the SDK side in order I can probably help you out with the Python side of things. Just specify your widget, types and whatnot.

 

[gfurst]

Hey guys.
Baldyr, I've just reread all this stuff, when I try to remember it all seems fuzzy and complicated, but now I think we were on the right track.

Anyway, I've made an overall compilation on the ideas that should come together as a modpack
http://forums.civfanatics.com/showthread.php?t=420474
I'm trying to perfect the ideas based on concepts, the best I can before actually putting any work into it.
The tax modcomp may yet be usable, or not. I'm currently brainstorming so its best not to write much.