Implemented: Funding nations and activity scores

[Warboy1982]

just when you thought i couldn't break savegames between versions any more, i went and refactored activity and funding levels to vectors.
i'm still fiddling with some of the calculations, but it's at a complete enough state now where people can bug test it.

 - countries now have defined zones that we can check if targets are inside of (as per original x-com) similar to regional zones in implementation (read: copy pasted).
 - countries and regions will now store 12 months worth of activity data, and countries will keep track of the last 12 month's funding levels.
 - countries will now make both individual and group based decisions regarding your performance level and subsequently your funding level, based on activity levels.
 - countries that have had 2 consecutive months of sufficiently low score based on difficulty, will sign a pact with the aliens, terminate funding permanently and generate an alien base somewhere within their borders.
 - activity scores are based on the exact same triggers as in the original, and with the same numbers of points awarded.
 - the monthly report screen (and funding window) now accurately show changes and relevant information, just like in the original.

LINK TO GITHUB BRANCH

LINK TO PRE-COMPILED WIN32 EXE

[karvanit]

Just two coding observations:

• Prefer ++var over var++, unless the code will behave differently.
• You don't need to use .c_str() when sending std::wstring to streams (ie in you reporting function).

[Warboy1982]

k, i killed all the .c_str(), cause that probably WILL actually make a difference, also it was most likely left over from a copy/paste/replace variable and never taken out because it didn't cause an error.

i'll alter the divisors to ++var; for the sake of consistency.
but i have to ask:
does it make a difference (at least in this method)? i always figured that was just a "programming style" thing. except in the case of iterators where i believe it DOES actually matter, although i keep room for the possibility i could be completely wrong on both accounts.

by all means, keep it coming, i'll take all advice on board.

[Fenyő]

++var  as an expression, means: increase the value of var, store it in var and return the increased value where it typed.
var++  as an expression, means: return the value of var, and then increase the var.

examples:

1)
int a;
int b = 5;
a=++b;

This point: a=6 and b=6.

2)
int a;
int b = 5;
a=b++;

This point: a=5 and b=6.

Of course both operators can be defined, overloaded.

When used independently as an instruction, there is no difference in what they do. (since we don't use the return value)

[kkmic]

Correct and clean explanation.

Well done.

[SupSuper]

does it make a difference (at least in this method)? i always figured that was just a "programming style" thing. except in the case of iterators where i believe it DOES actually matter, although i keep room for the possibility i could be completely wrong on both accounts.

Besides what fenyo said, ++a and a++ makes a difference in STL iterators, because a++ needs to do extra work in order to only increment after the call, so ++a is faster and preferred when you don't need to worry about the return value.

[Warboy1982]

actually, looking at the coding again, why the hell do i even HAVE divisor integer variables when i could simply use _game->getSavedGame()->getCountries()->size()

[Fenyő]

Besides what fenyo said, ++a and a++ makes a difference in STL iterators, because a++ needs to do extra work in order to only increment after the call, so ++a is faster

Not necessarily.
On source code level, you're right.
But on processor level (/assembly) they might have exact performance.
The difference is only a value saving. That's the extra work, - in the case of pointers - to save that 32-bit to a variable, which is returned after the original var is increased.

On assembly level, 32-bit values usually returned in the EAX register, the value is put in that before executing the RET instruction.
If the compiler is clever enough, it might optimize the code to copy the value to the EAX first, (this way it doesn't need an EXTRA saving) and then increase the original var, and then executing the RET.
This way there is no difference in performance between the two!

[karvanit]

If the iterator is not a simple pointer / integer, iter++ involves a copy, which the compiler may not be able to optimize away.
Since it costs nothing to prefer ++iter and it MAY cost when using iter++, it's considered good practice to use ++iter unless you need the other behaviour.

[Fenyő]

To ENSURE the same performance, yes.

[Warboy1982]

k, so assembly-level discussion of iterator incrementation aside...

has anyone actually TESTED this? anything to report? i'd like to merge this after i've fiddled with the formulae a bit, but i need to be sure it works. because no matter how much i test it internally, i always find something that needs a fix about 5 minutes after the merge, and i'd kind of like to avoid doing that as much as possible (ie get it all in with one push)

[Fenyő]

has anyone actually TESTED this? anything to report?

Usually i test only the "official" git-builds. So i'll test after you merge.

i'd like to merge this after i've fiddled with the formulae a bit, but i need to be sure it works. because no matter how much i test it internally, i always find something that needs a fix about 5 minutes after the merge, and i'd kind of like to avoid doing that as much as possible (ie get it all in with one push)

Why is this a problem?
This is the reason we call the git-Builds NIGHTLY.

[michal]

Yeah, i also think that trunk may contain bugs. That's why we have git builds and official releases.

Basically i think there should be such developing / releasing process :
1) couple weeks when new features are being merged in
2) couple weeks when ONLY bugfixes and translations are merged
3) releasing new version
4) Go to 1

[Warboy1982]

so you're saying merge it now, then focus on collecting bug reports until next release (and keep any further feature development seperate until then)?
or should i hold this off until next version?

i mean, it's ready to go, and it works fine according to INTERNAL testing. like i've said i need to adjust formulas, but until i find/deduce the exact methods/variables used in decision making, these will do the job in at least a reasonably similar manner.

[karvanit]

My opinion is:
'master' should always compile and run.

Once a feature has no obvious bugs and is relatively complete (functionality is there, just not every case), it should be merged.

Since the project is still very young, getting access to new features is good for faster development.