OpenXcom Forum
Contributions => Programming => Topic started by: Warboy1982 on November 22, 2012, 10:09:06 am
-
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 (https://github.com/Warboy1982/OpenXcom/tree/FundingNations)
LINK TO PRE-COMPILED WIN32 EXE (https://github.com/downloads/Warboy1982/OpenXcom/FundingNations.rar)
-
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).
-
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.
-
++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)
-
Correct and clean explanation.
Well done.
-
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.
-
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()
-
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!
-
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.
-
To ENSURE the same performance, yes. :)
-
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)
-
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.
-
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
-
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.
-
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.
-
i'll take that as a "do it"
guess now i'll just wait for the rage.
-
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.
-
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;
-
It's fine to put new vanilla features directly in Git as long as they compile and aren't horribly broken :P 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. :P
-
i hope you realize, i'm going to use that as my reference point for when i ask myself "should i push this?"
-
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 ;)
-
Don't overestimate users, expect the worst. :P
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 :)
-
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. :)
-
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?
-
This time it was problem with pulling changes from git (authorization issues). Nothing related with you, don't worry :) Works now.
-
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
_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.
-
Warboy1982, you could try this
_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;
-
i ended up using this:
for(int check = 100; check <= 100000; check *= 2)
{
if(roof < check - (check/10))
{
_scale = check;
break;
}
}
-
Warboy1982, then
_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.
-
After some thoughts, I came to conclusion that my code is a bit overkill and cpu intensive – so I made slightly simplified version
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;
-
Warboy1982, I have looked in to GraphState.cpp and find out that a bit of refactoring wont hurt as well as some tweaks. WDYT?
For example.
In original game the main formula to calculate scale factor for graph is (my guess)
scale_factor = ln(max(Val1, Val2, ..., ValN)/9)/ln(scale) where Val1...ValN is maximum value for each region/country/etc throughout a year, and scale is the first value on the scale of current graph, i.e. 50 for Income, 250 for Finance and 10 for rest. Pay attention, that these scale values are the default values that are used when no button is pressed. And also, scale factor is calculated only for currently visible values (whose buttons are pressed). So values on scale depends on scale factor and based on scale base (mentioned above).
So. Should I post a patch here or make a push request?
P.S. I'm not familiar with an english terminology, so if I screw it up somehow - I beg your pardon.
-
DO IT
currently i'm iterating through all the countries/months and setting a "roof" value based on the highest value being DISPLAYED and basing the scale off that. an array of booleans keeps track of which are on and which are off.
i'm using the scale to represent the upward maximum rather than the first value to display, and dividing as i go down the scale (which for all intents and purposes is the same as multiplying the scale as i go up), then dividing the top end of the scale by the number of vertical pixels on the graph to figure out a "units" measurement (ie how many points = 1 pixel)
i think what i'm trying to say is that the METHODS are sound, i don't think you'd have to fiddle with the math.
The implementation probably sucks tho, there has to be a more efficient method than iteration,l and i could probably condense a lot of it down into smaller functions.
that said, if you can get it all working your way (stress WORKING) then i'd have no problem with it.
-
OK. I'm on it. ASAP.
I have only one question left. May I change class GraphState in some way or should I stick to recent implementation (properties, methods, etc.)?
Be cause I don't want to break anything but in sake of refactoring some entities might gone.
-
if you can get it all working your way (stress WORKING) then i'd have no problem with it.
note that i am making a few small changes to the current implementation in my bughunting branch (https://github.com/Warboy1982/OpenXcom/commits/BattleScapeBugHunting), there are more to come (allowing for negative score values, for example), not sure if any of it will be of interest to you, but probably worth mentioning anyway.
basically i want this to be functionally identical to the original (as far as the player is concerned), how the back end is handled is of little consequence. just make sure to make it modifiable via the ruleset (ie adding a new country to the ruleset should add a new button)
-
do you think it would be possible at all to mod the game in a way that the nation's funding can go to somebody else instead of the player?
what I mean is that especially in a modded game that supports factions, perhaps the countries can be "conquered", so the funding goes to the faction that currently has control over the country - or even partial funding by "influence"... I'm just wondering if something like that is possible at all with the current code, or completely impossible, or if perhaps it would become possible by including a few small things now that would make it easier later... if you catch my drift :)
-
there is zero chance in current engine to have "faction" as beneficiaries except for xcom (player). it was about new country adding or modifying (changing set of) others.
-
warboy, could you add a space between every three digits for the monthly funding change, to improve readability? in the end-of-month report as well as in the "funding" screen.
the actual funding is displayed as "x xxx xxx", but the funding change is displayed as "xxxxxx"
also, it would be even easier to read if the columns were aligned to the right :)
-
on it, thanks! ;D