TravianX Advocaite Revision 4.8.5 Collection

Tanx All

http://up8.iranblog.com/images/0pk4aqm6r3pad4dvf774.jpg

:(::(::(::(::(:

https://github.com/advocaite/Travianx/zipball/master

Quote:

---

Originally Posted by parniaznet

i use script that is in the first post!
i it last V?

---

Quote:

---

Originally Posted by Thyphoon

https://github.com/advocaite/Travianx/zipball/master

---

i had it,its runing on my test server:

TravianX

I have a problem making units on my server.. Sometimes it takes ages to make 1 unit.. If i forexample want to make 1 Teutonic Knight, it takes 0:00:02 seconds to make 1. but when i try make it, it says : The next unit will be finished in 0:00:04, and when it reach 0:00:00 it just start over again, from 0:00:04. So it wont make the unit. How can i fix that? and else, how can i do, so it trains the units in 1 sec?
Please help. Thanks

other problem for Hero's Mansion :

/home/nayabpro/domains/nayabprojects.com/public_html/travianx1/Templates/Build/37.tpl on line 351

an other,attack is freeze at 00:00 (actually at land time like 3:12:27)
this erore engross my cpu server!! they Disabled my server!

http://1.pandora.net84.net/images/fd29ee0cb4b9.jpg

Are we married to insisting that scores such as the robbery score be unsigned (aka never a negative score)?

Think for example of two players both of whom are terrible robbers, and the player whose sock-puppet or fan or friend etc (collaborator?) they are.

Fans A and B don't mind staying close to zero points as long as star C, who they idolise, gains more points than they lose, because then by minimax and prisoner's dilemma type game-theories they as a community co-operating come out ahead in total compared to a similar sized, similarly closed community of "defaulters" (the usual prisoner's-dilemma term for non-cooperators).

No matter how many points C gains robbing A and B when A and B are at zero, A and B lose no points on the deal.

If points were a marketable commodity, the A+B+C team would thus be obtaining that commodity out of no-where (discounting actual resources stolen, which can afterall be shipped back to A and B by C ready to be "stolen" again.

*If* we were not married to insisting on unsigned, *then* maybe whatever is thinking for example that Theodore's victims negative gain of 38128, which though I haven't done the arithmetic might let us guess have resulted in a score of negative 38128 for the victim, might have been content to record negative 38128 as the victim's score instead of ignoring the sign-bit (or twos complementarity, or however bits represent integers on the platform used in the case) and pretending that sequence of bits represented a large positive integer not a much smaller negative integer.

I am Wild-Ass-Guessing that MySQL would convert a negative integer into a zero when storing it as an unsigned value *if* it actually *knew* what it was told to store *was* a sign-and-negative integer.

So... who lied to MySQL about the "type" of the integer to be stored OR who didn't take signed vs unsigned into account during arithmetic they did prior to handing MySQL a large positive unsigned integer to store instead of handing it a small negative signed integer to do do a min(0,inpout) on in its own defense of its database field type integrity?

Do we *want* players A,B and C to be able to pull points of score out of (ahem lets not speculate what orifice etc) ?

Or do we prefer to potentially "fill two orifices with one plug" by telling MySQL those scores are in fact *unsigned* values, which might well result in whatever is messing up the attempt to do arithmetic with a mix of signed and unsigned values doing its sums right and coming up with small negative score instead of a large positive one for the victims and, in case any accountants might be paying attention, incidentally also keep zero balance dual entry accounting from throwing up its hands at the miraculous way the robbers invent points out of nothing?

-MarkM-

---------- Post added at 01:36 AM ---------- Previous post was at 01:29 AM ----------



NOTE that zero balance dual entry accounting would let us check the integrity of the entire column "simply by checking it adds up to zero".

Without it, we cannot really have any more than some Wild Ass Guesses as to how many points the robber community potenially can pull out of ahem wherever they pull them out of so cannot check their integrity, which as robbers might be a lovely state of affairs permitting them to not even bother merely robbing if simply-or-otherwise exploiting bugs turns out to be more profitable than their... other sources of points.

-MarkM-

---------- Post added at 01:55 AM ---------- Previous post was at 01:36 AM ----------

The screenshot posted by parniaznet might be obscuring something by having had too much already happen; I have had three robbers rob three victims for three different amounts and the first time it happened, for 2400 points, I zeroed the victim's score because I perhaps stupidly / naively imagined someone might actually want database columns whose integrity cannot be simply checked.

So I have three robbers with positive scores and two victims with what look like some kind of integer-overflow or mis-interpretation of a negative value's bit-pattern as a bit-pattern intended to represent a positive value.

Thing is though, both victims have the same huge number of points despite being victims of robbers who gained from them two different numbers of points.

Specifically, the three robbers gained 2400 (with victcim's score zeroed manually by me afterward), 300 and 1900 points. The two victims whose points I have not messed with yet due to not being convinced the community will agree that allowing negative scores in the database is the way to go, each have 4294967295 points.

I tihnk we have two problems at once, of which solving the first (refusing to believe a score can be intended to be negative) might well fix the second (truncating a huge positive integer? How else but truncation, on positive or negative or even "cannot go below zero" side, can they end up both the same like this?).

Right now I am not too late to salvage the integrity of my data by correcting the scores of the three victims to -1900, -2400 and -3000.

Is anyone going to insist the data should not have integrity?

Bear in mind we might not know what hoops the corporation running the main commercial Travian type game jumps through to check its database by means other than the simple one that ought to suffice for us.

(If we really want naive observers to imagine scores cannot be negative we could make all displays that show points only show them if the are positive, displaying zero instead of the actual score in cases where the actual score is in the database actually negative.)

-MarkM-

Quote:

---

Originally Posted by knotwork

Are we married to insisting that scores such as the robbery score be unsigned (aka never a negative score)?...

---

can you fix and give me new code?

I am not convinced that it calls for new code, unless someone wants to censor the values shown to players to try to fool the players into thinking scores cannot be negative.

I am fixing my own install of it by removing the "unsigned" characteristic from the score fields in the database (in this specific case that means the field RR in the %PREFIX%users table but in general all such or similar scores/points probably should not be unsigned since making them unsigned obscures corruption of the data by removing our ability to check that all such or similar columns each add up to zero. (Every point gained by someone is a point lost by someone else.)) and correcting the overflowed values to their correct negative value instead of (losing information and the ability to check integrity so simply by) zeroing them.

-MarkM-

---------- Post added at 03:20 AM ---------- Previous post was at 03:13 AM ----------

To clarify: the only new code my solution so far seems to call for would only be useful to people starting up a new server from scratch, and all it would consist of would be to have the install/data/sql.sql file not set such fields as being unsigned.

Since only qualified programmer/sysadmins should be attempting to run servers at the current stage of development anyone who already started one can correct the contents of their existing database as they see fit in accordance with the specifics of their own situation (number of users aka alpha-testers affected, how bad a restart would be in terms of driving away such alpha-testers (hopefully to developer-run servers so the developers can have the testing happen on their own servers instead of receiving secondhand reports from servers they have no direct access on or, worse, third-hand reports from users complaining about problems on servers run by non-developers and so on) using their own sysadmin and programmer talent / expertise / staff.

-MarkM-

Problem in new upadete.
Profile,. and massege ,.. http://nakokos.eu/problem.jpg

Dzoki before you said that you have already localised almost all the site, are you going to push that, cause I'am half way the buildings and if you have already done that I will turn my attention to code other things.

I have a problem , try the search but still the same : with the latest version , when I click on the submit attack button on the rally point my troops magically disappear.
I need your help.

Have you downloaded the latest version from git hub?
https://github.com/advocaite/Travianx

Quote:

---

Originally Posted by knotwork

Are we married to insisting that scores such as the robbery score be unsigned (aka never a negative score)?

Think for example of two players both of whom are terrible robbers, and the player whose sock-puppet or fan or friend etc (collaborator?) they are.

Fans A and B don't mind staying close to zero points as long as star C, who they idolise, gains more points than they lose, because then by minimax and prisoner's dilemma type game-theories they as a community co-operating come out ahead in total compared to a similar sized, similarly closed community of "defaulters" (the usual prisoner's-dilemma term for non-cooperators).

No matter how many points C gains robbing A and B when A and B are at zero, A and B lose no points on the deal.

If points were a marketable commodity, the A+B+C team would thus be obtaining that commodity out of no-where (discounting actual resources stolen, which can afterall be shipped back to A and B by C ready to be "stolen" again.

*If* we were not married to insisting on unsigned, *then* maybe whatever is thinking for example that Theodore's victims negative gain of 38128, which though I haven't done the arithmetic might let us guess have resulted in a score of negative 38128 for the victim, might have been content to record negative 38128 as the victim's score instead of ignoring the sign-bit (or twos complementarity, or however bits represent integers on the platform used in the case) and pretending that sequence of bits represented a large positive integer not a much smaller negative integer.

I am Wild-Ass-Guessing that MySQL would convert a negative integer into a zero when storing it as an unsigned value *if* it actually *knew* what it was told to store *was* a sign-and-negative integer.

So... who lied to MySQL about the "type" of the integer to be stored OR who didn't take signed vs unsigned into account during arithmetic they did prior to handing MySQL a large positive unsigned integer to store instead of handing it a small negative signed integer to do do a min(0,inpout) on in its own defense of its database field type integrity?

Do we *want* players A,B and C to be able to pull points of score out of (ahem lets not speculate what orifice etc) ?

Or do we prefer to potentially "fill two orifices with one plug" by telling MySQL those scores are in fact *unsigned* values, which might well result in whatever is messing up the attempt to do arithmetic with a mix of signed and unsigned values doing its sums right and coming up with small negative score instead of a large positive one for the victims and, in case any accountants might be paying attention, incidentally also keep zero balance dual entry accounting from throwing up its hands at the miraculous way the robbers invent points out of nothing?

-MarkM-

---------- Post added at 01:36 AM ---------- Previous post was at 01:29 AM ----------



NOTE that zero balance dual entry accounting would let us check the integrity of the entire column "simply by checking it adds up to zero".

Without it, we cannot really have any more than some Wild Ass Guesses as to how many points the robber community potenially can pull out of ahem wherever they pull them out of so cannot check their integrity, which as robbers might be a lovely state of affairs permitting them to not even bother merely robbing if simply-or-otherwise exploiting bugs turns out to be more profitable than their... other sources of points.

-MarkM-

---------- Post added at 01:55 AM ---------- Previous post was at 01:36 AM ----------

The screenshot posted by parniaznet might be obscuring something by having had too much already happen; I have had three robbers rob three victims for three different amounts and the first time it happened, for 2400 points, I zeroed the victim's score because I perhaps stupidly / naively imagined someone might actually want database columns whose integrity cannot be simply checked.

So I have three robbers with positive scores and two victims with what look like some kind of integer-overflow or mis-interpretation of a negative value's bit-pattern as a bit-pattern intended to represent a positive value.

Thing is though, both victims have the same huge number of points despite being victims of robbers who gained from them two different numbers of points.

Specifically, the three robbers gained 2400 (with victcim's score zeroed manually by me afterward), 300 and 1900 points. The two victims whose points I have not messed with yet due to not being convinced the community will agree that allowing negative scores in the database is the way to go, each have 4294967295 points.

I tihnk we have two problems at once, of which solving the first (refusing to believe a score can be intended to be negative) might well fix the second (truncating a huge positive integer? How else but truncation, on positive or negative or even "cannot go below zero" side, can they end up both the same like this?).

Right now I am not too late to salvage the integrity of my data by correcting the scores of the three victims to -1900, -2400 and -3000.

Is anyone going to insist the data should not have integrity?

Bear in mind we might not know what hoops the corporation running the main commercial Travian type game jumps through to check its database by means other than the simple one that ought to suffice for us.

(If we really want naive observers to imagine scores cannot be negative we could make all displays that show points only show them if the are positive, displaying zero instead of the actual score in cases where the actual score is in the database actually negative.)

-MarkM-

---

Quote:

---

Originally Posted by parniaznet

can you fix and give me new code?

---

Quote:

---

Originally Posted by knotwork

I am not convinced that it calls for new code, unless someone wants to censor the values shown to players to try to fool the players into thinking scores cannot be negative.

I am fixing my own install of it by removing the "unsigned" characteristic from the score fields in the database (in this specific case that means the field RR in the %PREFIX%users table but in general all such or similar scores/points probably should not be unsigned since making them unsigned obscures corruption of the data by removing our ability to check that all such or similar columns each add up to zero. (Every point gained by someone is a point lost by someone else.)) and correcting the overflowed values to their correct negative value instead of (losing information and the ability to check integrity so simply by) zeroing them.

-MarkM-

---------- Post added at 03:20 AM ---------- Previous post was at 03:13 AM ----------

To clarify: the only new code my solution so far seems to call for would only be useful to people starting up a new server from scratch, and all it would consist of would be to have the install/data/sql.sql file not set such fields as being unsigned.

Since only qualified programmer/sysadmins should be attempting to run servers at the current stage of development anyone who already started one can correct the contents of their existing database as they see fit in accordance with the specifics of their own situation (number of users aka alpha-testers affected, how bad a restart would be in terms of driving away such alpha-testers (hopefully to developer-run servers so the developers can have the testing happen on their own servers instead of receiving secondhand reports from servers they have no direct access on or, worse, third-hand reports from users complaining about problems on servers run by non-developers and so on) using their own sysadmin and programmer talent / expertise / staff.

-MarkM-

---

Stop writing so much,what wrong with you?:grr:

If I'm using the "old" version and make an "upgrade", I can use the same database or i loose all my players data ?.