If you want Debian package and don't want to install dependency libraries with make install, then for this purpose replace
Code: Select all
make install
Code: Select all
checkinstall
Moderator: Committer
Code: Select all
make install
Code: Select all
checkinstall
Code: Select all
char hprefs[] = "kMGT";
Code: Select all
mag=floor(mag+0.500);
Code: Select all
if (integer==0) { d-=1; }
else { d-=(floor(log10(integer))+1); }
Code: Select all
if (integer == 0)
d -=1 ;
else
d -= (floor(log10(integer))+1);
Code: Select all
Error 17 error C2668: 'log10' : ambiguous call to overloaded function ClientUI.cpp 806
Error 18 error C2668: 'pow' : ambiguous call to overloaded function ClientUI.cpp 827
Error 19 error C2668: 'log10' : ambiguous call to overloaded function ClientUI.cpp 829
Error 20 error C2668: 'log10' : ambiguous call to overloaded function ClientUI.cpp 833
Error 21 error C2668: 'log10' : ambiguous call to overloaded function ClientUI.cpp 838
Good observation. 12345 is displayed as 12.345k because "prefixes" are the default choice. After all, 12.345k still shows 5 digits, so they both show the correct number of digits.Looking at your power-of-ten selection, it looks like you're not considering the number of digits requested. Would your code properly handle the case of val = 12345 with 5 digits? The result should be "12345" and not "12.345k".
I totally agree. Originally I was displaying a u so I could get away with the more elegant solution (hence the two arrays). But with the utf-8 character I'll have to switch to the if-else structure.Having a special case check at the end for mu is rather clunky... could you not use the same structure / method to pick the string representing all the prefixes?
I didn't get warnings or errors. But now that you're making me notice it, I'll static cast the integers.Also, I get some compile errors:You probably need to static_cast<double> the integers.Code: Select all
Error 17 error C2668: 'log10' : ambiguous call to overloaded function ClientUI.cpp 806 Error 18 error C2668: 'pow' : ambiguous call to overloaded function ClientUI.cpp 827 Error 19 error C2668: 'log10' : ambiguous call to overloaded function ClientUI.cpp 829 Error 20 error C2668: 'log10' : ambiguous call to overloaded function ClientUI.cpp 833 Error 21 error C2668: 'log10' : ambiguous call to overloaded function ClientUI.cpp 838
For the values shown, that looks OK.Kuhlschrank wrote:Is this, what it's meant to look like?
No. 12.5 is not an integer.Kuhlschrank wrote:I think the values as shown in my screenshot erroneously are set to integerize = true. Is that right?
Ok, i mixed the words.... i meant:Geoff the Medio wrote:No. 12.5 is not an integer.Kuhlschrank wrote:I think the values as shown in my screenshot erroneously are set to integerize = true. Is that right?
I don't know if that is why they're shown wrong in the SVN version, but if I recall correctly, that is the result that is a problem.Kuhlschrank wrote:Ok, i mixed the words.... i meant:
"I think the values shown in my screenshot are erroneously set to integerize = true in SVN, and so are only displayed with the 'integer part' (1k instead of 1.04k when the double value is 1043 e.g.). Is that right?"
StatisticIcon::Refresh() in CUIControls.cpp. You'll probably need to find where those StatisticIcon are created though, since it gets the integerize parameter from the constructor.Kuhlschrank wrote:Where in the code are the calls to update these resource (food, minerals...) values?
That's the answer for my next question... =)Geoff the Medio wrote:Really, we don't need an integerize parameter at all, though.
Code: Select all
m_population = new StatisticIcon(m_btn_siterep->UpperLeft().x-LAYOUT_MARGIN-ICON_DUAL_WIDTH,GG::Y(LAYOUT_MARGIN),ICON_DUAL_WIDTH,m_turn_update->Height(),
ClientUI::MeterIcon(METER_POPULATION),
0,0,3,3,false,false,false,true);
m_toolbar->AttachChild(m_population);
m_industry = new StatisticIcon(m_population->UpperLeft().x-LAYOUT_MARGIN-ICON_WIDTH,GG::Y(LAYOUT_MARGIN),ICON_WIDTH,m_turn_update->Height(),
ClientUI::MeterIcon(METER_INDUSTRY),
0,3,false,false);
m_toolbar->AttachChild(m_industry);
m_research = new StatisticIcon(m_industry->UpperLeft().x-LAYOUT_MARGIN-ICON_WIDTH,GG::Y(LAYOUT_MARGIN),ICON_WIDTH,m_turn_update->Height(),
ClientUI::MeterIcon(METER_RESEARCH),
0,3,false,false);
m_toolbar->AttachChild(m_research);
m_trade = new StatisticIcon(m_research->UpperLeft().x-LAYOUT_MARGIN-ICON_DUAL_WIDTH,GG::Y(LAYOUT_MARGIN),ICON_DUAL_WIDTH,m_turn_update->Height(),
ClientUI::MeterIcon(METER_TRADE),
0,0,3,3,false,false,false,true);
m_toolbar->AttachChild(m_trade);
m_mineral = new StatisticIcon(m_trade->UpperLeft().x-LAYOUT_MARGIN-ICON_DUAL_WIDTH,GG::Y(LAYOUT_MARGIN),ICON_DUAL_WIDTH,m_turn_update->Height(),
ClientUI::MeterIcon(METER_MINING),
0,0,3,3,false,false,false,true);
m_toolbar->AttachChild(m_mineral);
m_food = new StatisticIcon(m_mineral->UpperLeft().x-LAYOUT_MARGIN-ICON_DUAL_WIDTH,GG::Y(LAYOUT_MARGIN),ICON_DUAL_WIDTH,m_turn_update->Height(),
ClientUI::MeterIcon(METER_FARMING),
0,0,3,3,false,false,false,true);
m_toolbar->AttachChild(m_food);
We're probably fine without it.Kuhlschrank wrote:So there really is NO need for this integerization?
This is the bug in how DoubleToString handles the integerize flag. It should round 1435.5 to 1435 (an integer).Kuhlschrank wrote:I think this 'integerize' isn't very useful in the way how it works.... [...] a population of 1450 would be formatted to 1k which cuts very much information...
"Population" isn't individual people. Rather, it's population points, which are a race-neutral measure of population. A single population point can be thought of as roughly 1 billion humans.A population of 25.0 people is some kind of weird where there are only whole numbers of people...
Yes. Particularly since there are other issues with DoubleToString than the integerize flag. See the discussions earlier in this thread.Is this topic worth more investigation? =)
Depends what you mean by severe...Or are there more severe things to do?
So, when integerize is set tot true, the variable digits has no meaning anymore?Geoff the Medio wrote:This is the bug in how DoubleToString handles the integerize flag. It should round 1435.5 to 1435 (an integer).
OKGeoff the Medio wrote:"Population" isn't individual people. Rather, it's population points, which are a race-neutral measure of population. A single population point can be thought of as roughly 1 billion humans.
I'll take a look at this soon... =)Geoff the Medio wrote:Yes. Particularly since there are other issues with DoubleToString than the integerize flag. See the discussions earlier in this thread.Is this topic worth more investigation? =)