Implemented: Funding nations and activity scores

[Warboy1982]

i'll take that as a "do it"

guess now i'll just wait for the rage.

[Fenyő]

I have an agreement with karvanit.

And i think you don't need to keep any further feature development seperate until the next release.
The point in michal's speech is that a couple of weeks (i think days) before the release is the interval when new feature should not be merged. Before that, you don't have to wait between every new features to fully debug them.

[Warboy1982]

i always find something that needs a fix about 5 minutes after the merge

SELECT REPLACE(developer_name, 'i', 'karvanit')
SELECT REPLACE(timescale, '5 minutes', '30 seconds')
FROM Quote;

[SupSuper]

It's fine to put new vanilla features directly in Git as long as they compile and aren't horribly broken but there's nothing wrong with making sure your work is good first either. Any further issues can be ironed out as development goes along. The "test it throughly before sending it in" is mainly for people using pull requests so I don't have to deal with a flurry of requests for every development step or last-minute fixes.

Do note that people do implicitly treat the Git builds as finished things, with stable releases just being general courtesy. People are always waiting for the latest Git builds to use as the real thing, if I try to cover them they complain. No matter how many warnings, disclaimers or more I put up, I still get the exact same "missing features", "incomplete functionality", etc. I can't put anything under development out without it being picked to death. Don't overestimate users, expect the worst.

[Warboy1982]

i hope you realize, i'm going to use that as my reference point for when i ask myself "should i push this?"

[michal]

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 work on new feature, test it as much as you can (as you already did now) and commit to master. Then work on another new features, wait for bug reports to last commited features, etc. We're in developing stage, so only rule is that master should compile and don't crash at start Bugs are acceptable in that stage.

At some point, after developing phase, we should switch to bugfixing phase, where adding new features should be avoided as much as possible. It's better on concentrate on bugfixes and translations. Then release.

Disclaimer: This is only my personal opinion. It's not official OpenXcom development rule (do we have such?)

Btw, git builds are being made by gcc compiler on linux server. So don't worry if you're code compiles under windows, but not on linux. That happens When you see there's no new git builds, that means that code doesn't compile or git builder is dead and need to be (re)started

[Daiky]

Don't overestimate users, expect the worst.

I wouldn't call people that run the gitbuilds "users", they're more like test pilots trying to fly a plane that is still under construction and has parts still missing. They should be glad they can take off and not be upset when they crash

[Fenyő]

When you see there's no new git builds, that means that code doesn't compile or git builder is dead and need to be (re)started

It seems its happening right now.

[Warboy1982]

uh oh. i've done something bad.
hopefully it's "git builder is dead and need to be (re)started"
because it compiles fine on my machine, and i only made a one line change that wouldn't have broken anything, and the only other changes were 2 PRs i accepted from karvanit, but he's on linux, and i see nothing in his PRs that could possibly cause it.

so if HE was able to compile it on linux, and i'm able to compile it on windows, surely it's not a compiler error, but an error with the compiler?

[michal]

This time it was problem with pulling changes from git (authorization issues). Nothing related with you, don't worry Works now.

[Warboy1982]

k, help requested with this one.

i can't figure out a good formula for the vertical scale on the graph.
here's what i'm using currently

Code: [Select]

_scale = highest

if(_scale < 90)
_scale = 100;
else if(_scale < 180)
_scale = 200;
else if(_scale < 360)
_scale = 400;
else if(_scale < 720)
_scale = 800;
else if(_scale < 1440)
_scale = 1600;
else if(_scale < 2880)
_scale = 3400;
else if(_scale < 5760) https://this should never occur but what the heck.
_scale = 6800;
where "highest" represents the highest score for this statistic (ie: xcom activity by country).
_scale gets multiplied by 10, then divided by 9-0 as it adds the numbers to the vertical scale.

what i basically want to do is find a nice round number as the maximum. but i can't come up with the math to do this.

not sure what do.

[smerch]

Warboy1982, you could try this

Code: [Select]

_scale = 1<<(int)(ln((int)(highest/90))/ln(2));

if(_scale > 16) https://first adjustment for 3400
_scale = 34;
else if(_scale > 32) https://final adjustment for 6800
_scale = 68;

_scale = _scale*100;


[Warboy1982]

i ended up using this:

Code: [Select]

for(int check = 100; check <= 100000; check *= 2)
{
if(roof < check - (check/10))
{
_scale = check;
break;
}
}

[smerch]

Warboy1982, then

Code: [Select]

_scale = 1<<((int)(ln(floor(roof/90)+0.5)/ln(2))+1);

if(_scale > 512) https://top boundary
_scale = 512;

_scale *= 100;

P.S. I found some errors in my code, now it should work.

[smerch]

After some thoughts, I came to conclusion that my code is a bit overkill and cpu intensive – so I made slightly simplified version

Code: [Select]

int _scale = 0; https:// just to make sure that _scale = 0

for(int check = roof/90; check > 0; check >>= 1)
++_scale;
if (_scale > 9) https:// top boundary
_scale=9;
_scale = (1 << _scale) * 100;