Troop Display

[Freenhult]

Alright, Arthus told me that he lost troops. So I made him log off, and I accessed his account using the visual editor feature in the MiniMyAdmin feature.

Accessed Long2Players, and scrolled down to his troop count. This is what read.

code: Select all

8405796|216196|2.3E+7|24756

I checked a fellow clansmens and verified that he has his troops shown the long way.

For the time being, I re-typed in the number for Arthus and sent him on his way.

2.3E^1 +7 is 13.25. My guess is that the number was being scaled to reflect nothing. It should be 2.3E7 if its going to abbrivate.

[Freenhult]

I believe I found a fix. Credit goes to C4smok/WebOver.

w did you try out that new function? that is a new one, I found out my old one did not cover it =X

also another option was (int)round($value) but it created negative numbers in high values

that bcmath function does the trick, I got it set and working in wgz
eround($roundme)
{$roundme = bcadd($roundme,0);return $roundme;}
replacing round with eround..

problem is you have to replace every round in your code pretty much... if you have any exponents in bcmath it will break it..

This method is quicker then having to do bcadd($value,0)

which is basicly what it is

So yeah. (Sorry for the long form. Taken out of an IM)

[The Beatles]

Replacing all round calls with a new function is not very hard. If he is sure this works, we may as well go ahead and integrate it. bcmath is not universally deployed, which is one concern; we should also probably check for the function's existence when defining our new round. Something like:

If the function bcadd exists
Then define eround as above
If it does not exist
Make eround a simple fallback for round

[Freenhult]

Apparently, Wgz was being plagued by this, and the above has worked for them.

[Freenhult]

Don't implement this yet. It has a bug in it. The basic idea is right. The code has a hard time understanding it somewhat.

[Death]

WGZ and FAF aren't based on the same codes, so I'd watch out with that kinda thing.

[Freenhult]

Its a bug with PHP. Not the code in general.

Well, not even a bug. Its just PHP can't handle it anymore with the newer versions. As I understand it.

[Death]

My point was these games might be using different versions of PHP, but you would know better than I. Many rewrites are going to be happening soon, it's going to suck.

Is this acting up again? I may be able to come up with a fix, though it would probably be a little "ghetto" by FaF standards.

[Freenhult]

There isn't a fix you can make.

[Death]

Then don't you think it's about time to go PHP5? lol

And I'm just assuming FaF is using an old version, because I know that WGZ was/is and no other games have this problem to my knowledge.

[Freenhult]

They do. I'm not sure how it was resolved though.

[Tetigustas shadowson]

We had the same problem @schnizits my guy said the php5 was not understanding some of the FM used for most prom games, we dropped old QM style completely.

Sorry dont know a good fix

[Death]

I'm working on finding a solution. If not every game has this problem, something has got to work. Though I doubt it's big enough of a problem to warrant a rather large scale change, it's more that I'm having trouble finding a way and it's annoying me.

I know that WGZ is based on an old "stolen" code, but I highly doubt FaF is based on an extremely old QM code, and even if it was, the one Valhall is based on would be even worse.

[Freenhult]

It has to do with the way PHP reads the numerical numbers and rounds them properly into place. For example, 41mil is read as 41E6 and such. It isn't reconverted back into its numerical form, and thus is lost.

Like with Kuthloh, if I access his account, and he really had 41 guys, it should read 4.1E7

[Death]

You don't think there is any brute force or backwards way of fixing it?

Like I said though, I'm just operating under the assumption that it can be fixed, because it isn't ed up for everyone.