| Pages: [1] :: one page |
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |

Datsevlu
|
Posted - 2003.09.30 07:13:00 -
[1]
We seemed to have reached a limit on how much of one thing you can have in a pile (trit in this case) the limit seems to be 2,147,474,943 kind of an odd number to have as a limit in a corp hanger. Guess when we go to make that station (if they ever come out) you will have to have many piles of trit. -- Datsevlu Blow'em up we'll build more.
Techell's ingame site |

Jarjar
|
Posted - 2003.09.30 08:44:00 -
[2]
2^31 (signed 32-bit integer): Max 2,147,483,648 (-1?) I suppose that's the problem.
|

Avaton White
|
Posted - 2003.09.30 13:53:00 -
[3]
Correct. In VB it's called a "Long Integer" data type. û2,147,483,648 thru 2,147,483,647 Seems a little silly to restrict the item piles to this data type. ------------------------------------------------ "The best defense is a dead opponent." - Avaton White
"The very notion of adding new features to broken code is self defeating to the point of being borderline insane." - Par'Nabuk ------------------------------------------------ |

Datsevlu
|
Posted - 2003.09.30 15:31:00 -
[4]
so I wonder if this should be filed as a bug report? Or just looks like game limitation to me. -- Datsevlu Blow'em up we'll build more.
Techell's ingame site |

Avaton White
|
Posted - 2003.09.30 20:33:00 -
[5]
In my opinion if items like stations are going to require huge piles of minerals then it needs to be changed to some other data type and could be considered a bug. Again, in VB (the only language I know) there is a "currency" data type that would work well for this since it doesn't degrade to scientific notation. It's range is -922,337,203,685,477.5808 thru 922,337,203,685,477.5807
I know EVE Online isn't written in VB but I'm sure there has to be some equivalent in whatever language it's written in. They could also create a user defined data type to handle the huge numbers. The downside is EVE would use more memory to store these variables. ------------------------------------------------ "The best defense is a dead opponent." - Avaton White
"The very notion of adding new features to broken code is self defeating to the point of being borderline insane." - Par'Nabuk ------------------------------------------------ |

Jarjar
|
Posted - 2003.09.30 20:40:00 -
[6]
A few 64-bits here, a few 64-bits there... (2^64)-1 = 18,446,744,073,709,551,615
|

Lurk
|
Posted - 2003.09.30 22:33:00 -
[7]
I would be pretty difficult to change that i guess.
But i don't think it's a problem ... i mean how many corps have those stockpiles in their hangars ?
And even then, make a second pile should not be so much of a problem.
EVE is very much database related, i know that you can restrict integers in MySQL to only allow positive numbers (unsigned ?). This could double the limit but there are tons of issues that are more important ...
|

Ivanova
|
Posted - 2003.10.01 02:56:00 -
[8]
Eve runs on 32-bit processors, so integers range from -2147483648 to 2147483647. Now, they could easily do a quick-fix by making it an UNSIGNED integer that holds this number. (A signed number is one in which one of the bits indicates that the value is positive or negative). It doesn't really make any sense to use a signed integer, because you cannot have negative values of tritanium, or anything for that matter. As Eve players progress, eventually that will not be a large enough value either (obviously, it is only twice as large as the current ceiling. By the way that is a hell of a lot of tritanium.) If CCP makes the storage type a double-precision floating point value, the max number of an item would be 1.7976931348623158 E + 308, or greater than the number of protons, neutrons, and electrons in the known universe (Sagan, Cosmos). Problem is, floating point numbers have a tendancy to round, and aren't really very appropriate for when exact integer numbers are needed. (You can't have 1.7381 trit, after all). They are also slower to use, and the FPU is already quite busy with all of the math needed to render polygons. While it isn't ANSI standard, many compilers, including Microsoft's, support 64-bit integers. These would also be quite a bit slower than using regular 32-bit integers, because two general purpose registers would be needed (rather than one) to store the number, and since it is split between two storage locations, the CPU has to do more work to do math with them. (This is all taken care of by the compiler, and the extra work would likely not be noticeable). This would probably be the best option. One other, which would also be ANSI-C compliant, would be to make a custom data type that holds an arbitrary number of bits, but that would be quite a bit slower than any of the above.
If we all get Athlon64's and CCP makes use of them, this won't be a problem, but until then, that limitation is definitely going to haunt some of the larger corporations. That said, if you have those kind of resources, you could easily resolve the issue by giving the excess to me. I would be more than willing to help out Techell or any other corp by doing this for you. -- "Never use a sledgehammer to drive a thumb tack." |

Dr Boskonovich
|
Posted - 2003.10.01 05:03:00 -
[9]
Just make another pile. Topic dead.
|

Jojin
|
Posted - 2003.10.01 05:19:00 -
[10]
If making another pile doesn't work, just evolve the tritanium. For example build tritanium bars where it takes 1 million tritanium to make one bar.
|

Datsevlu
|
Posted - 2003.10.01 05:55:00 -
[11]
Another pile is made that is not the problem where the problem comes is when you do a stack all it no longer stacks you have to mannual build this pile (I know boo hoo big deal) it is not that big a deal just wanted to point it out. But I did find you can make the pile bigger if you just add 1 trit at a time (this is a pain). -- Datsevlu Blow'em up we'll build more.
Techell's ingame site |

Avaton White
|
Posted - 2003.10.01 15:23:00 -
[12]
Quote: But I did find you can make the pile bigger if you just add 1 trit at a time (this is a pain).
Hmmm that would mean that the variables that are used to sum the piles are long integers and not the variable that holds the amount of the pile itself. Interesting. ------------------------------------------------ "The best defense is a dead opponent." - Avaton White
"The very notion of adding new features to broken code is self defeating to the point of being borderline insane." - Par'Nabuk ------------------------------------------------ |

Athan
|
Posted - 2003.10.01 16:31:00 -
[13]
Note that his pile hasn't actually yet hit the actual limit, hence being able to add small piles to it.
-Ath --
http://big.wayland.dk/Lottery.asp - The BIG Lottery |

Wodka
|
Posted - 2003.10.01 17:24:00 -
[14]
if they make it a double you will have more then enuf space unless you really make HUGE stacks of stuff
|

Avaton White
|
Posted - 2003.10.02 11:23:00 -
[15]
Only problem with a double data type is the fact that it degrades to scientific notation and doesn't represent the actual number for really big numbers. I've never had a use for it since it is so completely inaccurate. ------------------------------------------------ "The best defense is a dead opponent." - Avaton White
"The very notion of adding new features to broken code is self defeating to the point of being borderline insane." - Par'Nabuk ------------------------------------------------ |
| |
|
| Pages: [1] :: one page |
| First page | Previous page | Next page | Last page |