open All Channels
seplocked EVE General Discussion
blankseplocked Is it do difficult to have a different color for BPO / BPC ?
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: 1 2 [3] 4

Author Topic

Morkus Rex
Solar Spice and Liquors Company
Posted - 2006.12.22 07:24:00 - [61]
 

Could it not be possible to just ad "BPO" or "BPC" to the name of the blueprints ?
Most equipment is already like that, same icon but another name for named and faction stuff...

Lucio
Gallente
Prosta Toots
Posted - 2006.12.22 07:30:00 - [62]
 

Originally by: Morkus Rex
Could it not be possible to just ad "BPO" or "BPC" to the name of the blueprints ?
Most equipment is already like that, same icon but another name for named and faction stuff...


It would appear that this is beyond their abilities at this present time because they didn't think it was a needed function to be able to tell the difference....

Ariel Dawn
Posted - 2006.12.22 15:35:00 - [63]
 

Im no computer mathemagician, but if BPOs and BPCs are the same thing in different states (if Im understanding this), couldn't some information that shows when you rollover the item saying BPO or BPC be added, if Copy = No, then it says BPO, and vice versa. No need to actually change anything dealing with them, just adding some text outside of the BPO/BPCs on rollover.

Okkie2
Posted - 2006.12.22 15:48:00 - [64]
 

Originally by: Ariel Dawn
Im no computer mathemagician, but if BPOs and BPCs are the same thing in different states (if Im understanding this), couldn't some information that shows when you rollover the item saying BPO or BPC be added, if Copy = No, then it says BPO, and vice versa. No need to actually change anything dealing with them, just adding some text outside of the BPO/BPCs on rollover.


Did you read the DEV-post a page earlier ? It is possible but will introduce 5-10% extra lag, and solving this problem is certainly not worth extra lag Cool

prsr
Gallente
Shiva
Morsus Mihi
Posted - 2006.12.22 16:25:00 - [65]
 

Originally by: kieron

Is this something that will be addressed in the future? Certainly.



On behalf of all the players that have gotten their grubby hands on sweet t2 bpo's because the previous owners sold their bpo for the price of a bpc on escrow by mistake I would like to say:

Nooooo!!!!!1111one, don't do it.

thank you.

j0sephine
Caldari
Reikoku
Band of Brothers
Posted - 2006.12.22 17:03:00 - [66]
 

Edited by: j0sephine on 22/12/2006 17:07:07

"Please explain in layman's term to me, how the current colour gets from the databases
onto the player's screen without generating that exact 5-10% performance lag you are
talking about.
Thank you Very Happy"


It's currently something the client can do it on its own. All it takes is internal information to the effect "items with ID 20, 35, 40-50 ... are blueprints, use this special blue background and hue to generate their icon for the player to see"

But because both BPO and BPC have the same item ID, the client cannot tell BPO from BPC just with the item ID alone... it would also have to examine content of the item to read its 'remaining copies' attribute. Which is something that normally doesn't happen until the player uses the "show info" command.

It's this additional information lookup multiplied by number of players multiplied by number of BPOs and BPCs scattered in players hangars EVE-wide multiplied by number of times a day players access their inventory/assets windows etc... that would result in overall load increase of mentioned 10-15%

... something like this, anyway o.O;

Ariel Dawn
Posted - 2006.12.22 17:10:00 - [67]
 

Originally by: Okkie2
Originally by: Ariel Dawn
Im no computer mathemagician, but if BPOs and BPCs are the same thing in different states (if Im understanding this), couldn't some information that shows when you rollover the item saying BPO or BPC be added, if Copy = No, then it says BPO, and vice versa. No need to actually change anything dealing with them, just adding some text outside of the BPO/BPCs on rollover.


Did you read the DEV-post a page earlier ? It is possible but will introduce 5-10% extra lag, and solving this problem is certainly not worth extra lag Cool


I know that, but my suggestion wasnt along the lines of splitting BPOs and BPCs into seperate items. Just thought if one were to hold the mouse over a BPO/BPC, it would simply say "BPO" or "BPC" in a floating text box based on the unchanged properties of the print. So as no actual changes would be made to differentiate the two, I doubt it would add any lag or stress.

spiritfa11
Battlestars
GoonSwarm
Posted - 2006.12.22 17:25:00 - [68]
 

sort by type ... the first blueprint of a given type starting from left to right has "generally" (every time ive done it) been the bpo, not the bpcs, is that difficult?

glorious emotion
Gallente
Brainiacs
Posted - 2006.12.22 17:29:00 - [69]
 

Originally by: kieron
Originally by: Lucio
It would be about bloody time to make this change, this has been consistantly asked for and consistantly ignored. It can't be that hard to recolour a few hundred icons!

Yes, this has been asked for a number of times and each time the topic is brought up, it is discussed, normally with someone posting sentiments such as yours.

CCP is not ignoring the issue. Due to the way in which BPo's and BPc's are stored in the database, simply changing the icon color would result in a significant amount of database queries. I was informed that to change the color would result in an increase in server response time by 5 to 10%. In layman's terms, we would be adding 5-10% more lag to everyone's connection.

Is this something that will be addressed in the future? Certainly. The some of Devs are working on reprogramming the underlying code structure and I believe this change is one intended for the revision. Obviously, this is a big task and will take some time.



Thanks for the info kieron, good to hear it's something that's being looked at in the future, even if it's the distant future Smile


j0sephine
Caldari
Reikoku
Band of Brothers
Posted - 2006.12.22 17:30:00 - [70]
 

"Just thought if one were to hold the mouse over a BPO/BPC, it would simply say "BPO" or "BPC" in a floating text box based on the unchanged properties of the print. So as no actual changes would be made to differentiate the two, I doubt it would add any lag or stress."

But in order to show that information in the floater the client still has to request it from the server (it's not sent by default when you open the inventory to keep the load smaller) ... so while it'd be less stressful than automatic requests, there's some extra processing added nonetheless.

Wilfan Ret'nub
Singularity.
The SUdden Death Squad
Posted - 2006.12.22 18:36:00 - [71]
 

Originally by: j0sephine
But in order to show that information in the floater the client still has to request it from the server (it's not sent by default when you open the inventory to keep the load smaller)
It could be sent by default. If they put in some effort, they could piggy-back it on something else - probably there's already a set of item flags. If not, they could find some more features (quick) item data needs and amortize that extra byte.

Thor Xian
Rebirth.
THE GOD SQUAD
Posted - 2006.12.22 18:41:00 - [72]
 

I'd rather see the end of BPCs.

DukDodgerz
Amarr
Doomheim
Posted - 2006.12.22 18:59:00 - [73]
 

i see a lot of good ideas, and ccp just doesnt care that they made a mistake, and refuse to correct it with simple solutions, instead they make whiney refferences to complete code overhauls...jeeeez, some of us are software engineers and know better.

use the record set, on client side, to trigger an overlay graphic to change the color, add an icon, or what ever indicator you can think up. a minor patch would cover it.


j0sephine
Caldari
Reikoku
Band of Brothers
Posted - 2006.12.22 20:04:00 - [74]
 

Edited by: j0sephine on 22/12/2006 20:11:33

"It could be sent by default."

Which would cause that very 10-15% server load increase kieron mentioned. There is no free lunch here -- any piece of data (at least one that isn't static) has to be looked up by the server and sent to the client in order to make it available for you. And that lookup takes time and processing power.

Uggster
Caldari
FinFleet
KenZoku
Posted - 2006.12.22 20:07:00 - [75]
 

CBA to read the entire thread but if there was a way to easerly see the differance between BPO's and BPC's expect any decent BPO's to be scanned and then suicided.


j0sephine
Caldari
Reikoku
Band of Brothers
Posted - 2006.12.22 20:09:00 - [76]
 

"i see a lot of good ideas, and ccp just doesnt care that they made a mistake, and refuse to correct it with simple solutions, instead they make whiney refferences to complete code overhauls...jeeeez, some of us are software engineers and know better

use the record set, on client side, to trigger an overlay graphic to change the color, add an icon, or what ever indicator you can think up. a minor patch would cover it."


When the only information you receive from the server is item ID which is identical for BPO and BPC, how does the client tell them apart from this information alone, again?

The one thing a sofware engineer should really 'know better' is to read before they post something which was suggested and explained as meaningless heap times already. "jeeeeez" indeed --;;

Snarls McGee
Posted - 2006.12.22 20:16:00 - [77]
 

OK, so if it is too difficult to apply to EXISTING BPCs, why not take the (presumed) quick dev time to add a new BPC entry and make it exactly like ammo (1 icon, hopefully different colored than BPOs, with a "number of units remaining" [ ] on it).

Surely THAT can't be beyond the dev's capabilities. Assuming there are 1000-1200 unique BPOs in the game that are copyable (unlike COSMOS BPs) would it really take an intern more than a few days to enter in the new items (especially after the work was done to hammer out the first one)? Heck, couldn't they even just duplicate the EXISTING db entries for the BPs and make slight modifications?

Gariuys
Evil Strangers Inc.
Posted - 2006.12.22 21:01:00 - [78]
 

Originally by: DukDodgerz
i see a lot of good ideas, and ccp just doesnt care that they made a mistake, and refuse to correct it with simple solutions, instead they make whiney refferences to complete code overhauls...jeeeez, some of us are software engineers and know better.

use the record set, on client side, to trigger an overlay graphic to change the color, add an icon, or what ever indicator you can think up. a minor patch would cover it.




Yeah and someone thta works with code, should know a helluvalot better then to make guesses at wild solutions without actually knowing the code they're talking about.

god the only thing more tiresome then whiners, is whiners thinking they know all cause they know how to write a bat file.... get a grip

Gariuys
Evil Strangers Inc.
Posted - 2006.12.22 21:03:00 - [79]
 

Originally by: Snarls McGee
OK, so if it is too difficult to apply to EXISTING BPCs, why not take the (presumed) quick dev time to add a new BPC entry and make it exactly like ammo (1 icon, hopefully different colored than BPOs, with a "number of units remaining" [ ] on it).

Surely THAT can't be beyond the dev's capabilities. Assuming there are 1000-1200 unique BPOs in the game that are copyable (unlike COSMOS BPs) would it really take an intern more than a few days to enter in the new items (especially after the work was done to hammer out the first one)? Heck, couldn't they even just duplicate the EXISTING db entries for the BPs and make slight modifications?


Yeah, they're absolute ******s, if there was a quick dirty way around this problem, for one it would have to be a priority to begin with, which is doubtful, cause it's not something critical in any way. And secondly, the dirty way around would have to exist, and be a reasonable effort considering it's priority.

Conclusion, it's on their minds, and when priority, effort, and opportunity combine... we get captain planet...

Kargon
Posted - 2006.12.22 22:43:00 - [80]
 

Originally by: kieron
Originally by: Lucio
It would be about bloody time to make this change, this has been consistantly asked for and consistantly ignored. It can't be that hard to recolour a few hundred icons!

Yes, this has been asked for a number of times and each time the topic is brought up, it is discussed, normally with someone posting sentiments such as yours.

CCP is not ignoring the issue. Due to the way in which BPo's and BPc's are stored in the database, simply changing the icon color would result in a significant amount of database queries. I was informed that to change the color would result in an increase in server response time by 5 to 10%. In layman's terms, we would be adding 5-10% more lag to everyone's connection.

Is this something that will be addressed in the future? Certainly. The some of Devs are working on reprogramming the underlying code structure and I believe this change is one intended for the revision. Obviously, this is a big task and will take some time.



Rather than having the client query the server for some data field to decide how to draw the icon, why not just embed that data in something the client already gets?

For example, you could just put that data in the first character of the item name. The client already knows the name of the item when it goes to display it -- now the client will also know whether the item is a BPO or BPC (based on the first, invisible character).

Sure, it's a hack, but you would only need to update the DB once so that BPO and BPC names have the new data.

Gariuys
Evil Strangers Inc.
Posted - 2006.12.22 22:56:00 - [81]
 

Originally by: Kargon
Originally by: kieron
Originally by: Lucio
It would be about bloody time to make this change, this has been consistantly asked for and consistantly ignored. It can't be that hard to recolour a few hundred icons!

Yes, this has been asked for a number of times and each time the topic is brought up, it is discussed, normally with someone posting sentiments such as yours.

CCP is not ignoring the issue. Due to the way in which BPo's and BPc's are stored in the database, simply changing the icon color would result in a significant amount of database queries. I was informed that to change the color would result in an increase in server response time by 5 to 10%. In layman's terms, we would be adding 5-10% more lag to everyone's connection.

Is this something that will be addressed in the future? Certainly. The some of Devs are working on reprogramming the underlying code structure and I believe this change is one intended for the revision. Obviously, this is a big task and will take some time.



Rather than having the client query the server for some data field to decide how to draw the icon, why not just embed that data in something the client already gets?

For example, you could just put that data in the first character of the item name. The client already knows the name of the item when it goes to display it -- now the client will also know whether the item is a BPO or BPC (based on the first, invisible character).

Sure, it's a hack, but you would only need to update the DB once so that BPO and BPC names have the new data.


Sounds simple, but isn't, this is IT, if it sounds simple, it probably won't work, will take a helluvalot longer to do then any manager could be made to understand, and it will brake atleast 10 other things that will take weeks to fix.

In your example, just the problems from the top of my head.
1. It assumes the database entry you want to use for this can hold another character which is unlikely, without trouble which is even more unlikely, and no calls to the this attribute are made that will have a problem with a additional character which is highly unlikely.
2. The name is probably stored client side, and the only thing that's sent is a ID, so any client side tables that use that ID, or make a reference to it need changing.
3. You have to either make new icons, or have the icons able to switch around background colour. One requires you double all the bp entries. Other could require a rework of how icons are build, cause they're probably just standard images.
3. Doing the db update could take a while, there's a lot of bp's around. So depending on how long it takes it could mean anything from extended DT, to extending the time required to patch, cause it would probably need some client side fixes, putting it in a patch would be logical.

And all that for something that's slight convenient... so probably is on the bottom of a list somewhere... ain't gonna happen.

Barthez Thed
Posted - 2006.12.22 23:46:00 - [82]
 

Edited by: Barthez Thed on 22/12/2006 23:46:17
The resources needed are enormous. A colour has to be decided, the paint purchased and extra small paint brushed for the hamsters (custom made and very expensive).

Then they gotta hire more hamsters to do the job and the Working Hamsters Union (WHO) has been giving CCP hell recently because of the new patches etc so they are not on good terms.


Regards

Barthez Thed

Very Happy

Kargon
Posted - 2006.12.23 00:32:00 - [83]
 

Originally by: Gariuys
Originally by: Kargon
Originally by: kieron
Originally by: Lucio
It would be about bloody time to make this change, this has been consistantly asked for and consistantly ignored. It can't be that hard to recolour a few hundred icons!

Yes, this has been asked for a number of times and each time the topic is brought up, it is discussed, normally with someone posting sentiments such as yours.

CCP is not ignoring the issue. Due to the way in which BPo's and BPc's are stored in the database, simply changing the icon color would result in a significant amount of database queries. I was informed that to change the color would result in an increase in server response time by 5 to 10%. In layman's terms, we would be adding 5-10% more lag to everyone's connection.

Is this something that will be addressed in the future? Certainly. The some of Devs are working on reprogramming the underlying code structure and I believe this change is one intended for the revision. Obviously, this is a big task and will take some time.



Rather than having the client query the server for some data field to decide how to draw the icon, why not just embed that data in something the client already gets?

For example, you could just put that data in the first character of the item name. The client already knows the name of the item when it goes to display it -- now the client will also know whether the item is a BPO or BPC (based on the first, invisible character).

Sure, it's a hack, but you would only need to update the DB once so that BPO and BPC names have the new data.


Sounds simple, but isn't, this is IT, if it sounds simple, it probably won't work, will take a helluvalot longer to do then any manager could be made to understand, and it will brake atleast 10 other things that will take weeks to fix.

In your example, just the problems from the top of my head.
1. It assumes the database entry you want to use for this can hold another character which is unlikely, without trouble which is even more unlikely, and no calls to the this attribute are made that will have a problem with a additional character which is highly unlikely.
2. The name is probably stored client side, and the only thing that's sent is a ID, so any client side tables that use that ID, or make a reference to it need changing.
3. You have to either make new icons, or have the icons able to switch around background colour. One requires you double all the bp entries. Other could require a rework of how icons are build, cause they're probably just standard images.
3. Doing the db update could take a while, there's a lot of bp's around. So depending on how long it takes it could mean anything from extended DT, to extending the time required to patch, cause it would probably need some client side fixes, putting it in a patch would be logical.

And all that for something that's slight convenient... so probably is on the bottom of a list somewhere... ain't gonna happen.


1 & 2: If we assume that only the ID is passed, then add that data in the high bit(s) of the ID. That does assume there are enough bits free, but I'm hoping they used at least 32-bit IDs, so there should be enough room.

3: Make a new icon... so what? That's art time. It's relatively free.

4: One-time DB update. I doubt it takes very long to go through the items in the DB... EVE has to have a fast DB, otherwise the game would crawl with the thousands of transactions that happen during normal play.

j0sephine
Caldari
Reikoku
Band of Brothers
Posted - 2006.12.23 00:47:00 - [84]
 

"1 & 2: If we assume that only the ID is passed, then add that data in the high bit(s) of the ID."

OK, one more time, until it sinks in i guess. Currently the BPO and BPC for each item share the ID. As such you cannot encode anything in the ID that will be specifically interpreted as something reserved for either BPOs or BPCs.

If the BPOs and BPCs were separate items with different IDs then yes, making change to what their icon looks like would be relatively trivial. But if i remember right, the reason they are still treated as the same item is buried somewhere deep in how the whole manufacturing process in EVE is programmed and there isn't really easy nor quick solution for changing that to a new model.

Draegario
Posted - 2006.12.23 01:19:00 - [85]
 

Let me see if I can make a reasonable analogy for what this would take.

1) Open your window explorer and create a new folder. This represents your hanger/container.

2) Create two new text files and give them each an 8-digit number for a name. In one add the text “Original” and in the other add the text “Copy”. These represent your BPO and BPC.

3) Copy these two files as many times as you want, and each file has an 8-digit number for a name. You will probably want more BPC files than BPO files. Make enough copies so that you have 100 text files in the directory. These represent the blueprints you have in your hanger/container.

4) Close the window explorer and reboot your computer to eliminate the internal cache of the file listings.

5) Open the window explorer and go to the new folder representing your hanger/container. Note about how long it takes to display all of the file names. This is like opening your hanger/container for the first time.

6) Now, select all of the files in this folder. Right click on them and select “open”. This will open all of the files. A warning window may open, go ahead and click yes. Note how long it takes to open all of the files. This represents EVE looking up each blueprint to check whether it's a BPO or BPC.

You can repeat this using 1,000 files. This represents the maximum number of blueprints that a hanger or container can have.

Now picture thousands of players doing this several times (multiple canisters in the same hanger) all at once.

Then ask yourself this. Do you really want this kind of lag to be added to playing EVE?

While this is not exactly what goes on with the EVE database, I think this represents a close approximation of the delays that would be caused by the added load on the database servers.

When you open a hanger or canister, all you are getting is the directory listing of what's there. To get anything more specific requires accessing the database.

- Drae

Lucio
Gallente
Prosta Toots
Posted - 2006.12.23 01:47:00 - [86]
 

Originally by: Snarls McGee
OK, so if it is too difficult to apply to EXISTING BPCs, why not take the (presumed) quick dev time to add a new BPC entry and make it exactly like ammo (1 icon, hopefully different colored than BPOs, with a "number of units remaining" [ ] on it).

Surely THAT can't be beyond the dev's capabilities. Assuming there are 1000-1200 unique BPOs in the game that are copyable (unlike COSMOS BPs) would it really take an intern more than a few days to enter in the new items (especially after the work was done to hammer out the first one)? Heck, couldn't they even just duplicate the EXISTING db entries for the BPs and make slight modifications?


That's actually a quite sensible suggestion, duplicate the BPO information and use the new ID's for BPC only and then write a querry that substitutes all BP's with runs listed for the new item ID.

Sure it breaks one of the rules of good database design, never duplicate information, but it seems a good bodge until they can recode the entire way BP's work.

Kargon
Posted - 2006.12.23 02:14:00 - [87]
 

Edited by: Kargon on 23/12/2006 02:19:28
Originally by: j0sephine
"1 & 2: If we assume that only the ID is passed, then add that data in the high bit(s) of the ID."

OK, one more time, until it sinks in i guess. Currently the BPO and BPC for each item share the ID. As such you cannot encode anything in the ID that will be specifically interpreted as something reserved for either BPOs or BPCs.

If the BPOs and BPCs were separate items with different IDs then yes, making change to what their icon looks like would be relatively trivial. But if i remember right, the reason they are still treated as the same item is buried somewhere deep in how the whole manufacturing process in EVE is programmed and there isn't really easy nor quick solution for changing that to a new model.


It's easy enough to treat them the same, yet have the extra info in the ID. Update the current code so that the effective ID is determined using a bitmask...

For our case, say we hijack the high bit for this extra info. The current code that checks against ID would be updated to check (ID & 0x7fffffff). Pretty simple. The client-side code that retrieves the icon for the given ID would check the high bit and change the icon as appropriate...

Say our convention is to set the high bit to 1 for BPOs. Now, whenever a new BPO is created, just set that high bit. But everything else in the code will think it's exactly like the current BPO/BPC because they've been updated to check only the low order bits which remain unchanged.

You would need to make one pass through the item DB to update item IDs as appropriate. It should be easy enough to automate.

I understand it may be difficult to do a search & replace through the source code to make sure that anything referencing the "item ID" variable is updated to mask off the high bit. Then again, it could be easier than expected; one can hope that EVE used some sort of data abstraction and has a "GetID" function that could be changed and globally fix the issue. If EVE used an object-oriented language (e.g. C++), then maybe "item ID" is a private member variable that has a public accessor which could be updated simply.

If you close your mind to the problem, you won't find a solution.

Kargon
Posted - 2006.12.23 02:26:00 - [88]
 

Originally by: Draegario
Let me see if I can make a reasonable analogy for what this would take.

1) Open your window explorer and create a new folder. This represents your hanger/container.

2) Create two new text files and give them each an 8-digit number for a name. In one add the text “Original” and in the other add the text “Copy”. These represent your BPO and BPC.

3) Copy these two files as many times as you want, and each file has an 8-digit number for a name. You will probably want more BPC files than BPO files. Make enough copies so that you have 100 text files in the directory. These represent the blueprints you have in your hanger/container.

4) Close the window explorer and reboot your computer to eliminate the internal cache of the file listings.

5) Open the window explorer and go to the new folder representing your hanger/container. Note about how long it takes to display all of the file names. This is like opening your hanger/container for the first time.

6) Now, select all of the files in this folder. Right click on them and select “open”. This will open all of the files. A warning window may open, go ahead and click yes. Note how long it takes to open all of the files. This represents EVE looking up each blueprint to check whether it's a BPO or BPC.

You can repeat this using 1,000 files. This represents the maximum number of blueprints that a hanger or container can have.

Now picture thousands of players doing this several times (multiple canisters in the same hanger) all at once.

Then ask yourself this. Do you really want this kind of lag to be added to playing EVE?

While this is not exactly what goes on with the EVE database, I think this represents a close approximation of the delays that would be caused by the added load on the database servers.

When you open a hanger or canister, all you are getting is the directory listing of what's there. To get anything more specific requires accessing the database.

- Drae


Imagine that the "BPO or BPC" data was encoded in the filename. Now you avoid opening the file altogether. Now you can determine the "BPO or BPC" data straight from what you already have -- the filenames that you've always needed.

j0sephine
Caldari
Reikoku
Band of Brothers
Posted - 2006.12.23 02:45:00 - [89]
 

"It's easy enough to treat them the same, yet have the extra info in the ID. Update the current code so that the effective ID is determined using a bitmask...

(..)

I understand it may be difficult to do a search & replace through the source code to make sure that anything referencing the "item ID" variable is updated to mask off the high bit."


This is interesting idea, though afraid implementation would be more complicated than that. For example if you just mask off the 'original bit' everywhere, then it's possible a simple act of BPO transfer to another person or maybe even to factory/research slot can result in loss of that piece of information unless the system handling it is taught to preserve it or set again. Etc.

Overall, i'd guesstimate the amount of coding work involved (given you'd need to consider all of current common game mechanics that touch assets IDs and decide in what way each of them handles this extra information) ... is likely not really much smaller from going the clean 'split BPOs and BPCs' route, if any. But then again, it's something only CCP knows -.o

Grez
Neo Spartans
Laconian Syndicate
Posted - 2006.12.23 02:50:00 - [90]
 

Originally by: Arienne Thielis
Blah, Blah, Blah.


Depends on how fast the hard-drive is, remember. You could have 50000 CPU's all processing data, but if the HDD isn't fast enough to load it as fast as the CPU's request it, it won't do anything, and 100 billion entries is a lot (and EVE has way more than that).


Pages: 1 2 [3] 4

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only