Why not just have it so only 6 cubes can be used on any one planet? Im pretty sure it wouldnt be hard to add 2 lines of code, one to add to the artifact s that it increases a variable that planets have and another on planets to check if that variable is over 6.

Actually, I'm pretty sure this would be a LARGE change to the DB Schema and coding, and not be backwards compatible to anyone.

I've in the past suggested similar things regarding redistributing your ship's personelle and what-have you, and Dan has said it wouldn;t work.

Basically he has not been tracking the planets to that level, and in a lot of ways why woudl he? it would mean a lot more data to be held for each ship and planet.

Basically i imagine the DB Schema is something like this:

Planet DB:

| GUID | Name | Size | Type | Rarity | MP Level | AP Level | RP Level |

| 000001 | Pizza | 8 | Gas | 2 | 7 | 9 | 12 |
| 010101 | Crabopolis | 3 | Barren | 1 | 1 | 5 | 4 |
| 575403 | Dynomicon | 10 | Dyson | 7 | 46 | 32 | 51 |

When you use an artifact that increases it's stats the increase is just added directly to the planet. that's why the limit is generally enforced on the artifacts, and why you can "get around" some limits (Like how we needed up being able to create Mega Colossal planets, and why Toxic Purifiers allow you to get to 16x Mega, because the code is set to check when the artifact is used "is the planet at X size" or "is the planet at X resource of Type Y?")

So you would have to put the limit in the code to check to see if the planet was a certain abundance and then stop, which is unfair as that is not how the artifact has worked until now.

However there MUST be an Effect's Table, so if you changed Cubes to an EFFECT track it separately, and it would either be able to be stripped from the planet or left on the planet, and you could theoretically limit the number of times an effect was present on the planet with a small amount off code.

BUT, what about players who have already used their cubes? No way to track who used them on what planets, and limit them, so now players who steal the old planets get an unfair advantage of being able to use more data cubes on them.

IN the end this is a strange, and mostly useless, edge case scenario for this artifact type. It would be costly and require players having a lot of friends willing to spend a lot of time playing GL, to get the benefit, in which case they might like the game, and decide they want to use the artys for themselves, (which in the end would be good because, more players!) or it would require Multi-accounts which are a TOS violation, or it would require trading it to strangers and risk loosing that 26x Mega Rich planet they worked so hard on and paid so much for.

Plus, not for nothing, it's an RP improvement scheme, and RP is just not very valuable once you get into the higher ranks (and I mean in the 500s+, and Certainly in the 800s+).

So I don't see why everyone is going so nuts about it.

-Q

well, the planet db is defintely much bigger...
for starters
development lvl
buildings
buffs(event and/or artifact)
current production amount

And actully, it won't be hard to code something in at all. just add 1 interger to the database as a new column. and each time an item is used, "check" the "box" accordingly like so:
(psudo code)
if (planet.getCube1()==false) {planet.setCube1(true);planet.setRP(planet.getRP()+1);}
else if (planet.getCube2()==false) {planet.setCube2(true);planet.setRP(planet.getRP()+1);}
//repeat for 3-5
else if (planet.getCube6()==false) {planet.setCube6(true);planet.setRP(planet.getRP()+1);}
else {return warning and do nothing}

where "planet" is an instance of the entity Planets which is generated from the database
you might notice that it's booleans in the codes but database is integer. well, u can code the 18 booleans(3 typesx6 uses) into 1 int "hash", just decode/code it everytime it passes the thingy that "talks" with the database. what was that called again? DO?
others are pretty self explainantory

The problem with this is that it will add a bit of data to the DB(it's just a single integer per planet so it's not really much. It does, however, generate quite a lot(comparatively speaking) of system load everytime a cube is attempted to be used due to the large quantity of codes involved. However, given the rare nature of the items, it won't be too bad)
And obviously adding this would allow 6 more to be used on ANY planet, which include ones already have stacks of it. But tbh, it isn't too bad to stack just an extra of 6, as opposed to 6000

it's not hard at all....

Adding a column to a table is NOT "Simple" it can completely change how all your views and stored procedures, and code functions, depending on how they have been written.

For instance is Dan is using Select * from DBTBL and you add a new column, then the code that handles the returned data will bomb because a new column which was unexpected was returned.

Also, as I mentioned Effects are going to be in a different table, as is colony development level, as are a lot of other things. the point of a relational database is to have tables with unique common data which applies to all objects of a certain type, and then sub tables for easily repeated sets of data for these objects.

So while yes you can put every effect on the DB table, you don;t want to, what you want is a separate set of tables like this:

PlanetTbl:

| GUID | Name | Size | Type | Rarity | MP Level | AP Level | RP Level |

| 000001 | Pizza | 8 | Gas | 2 | 7 | 9 | 12 |
| 010101 | Crabopolis | 3 | Barren | 1 | 1 | 5 | 4 |
| 575403 | Dynomicon | 10 | Dyson | 7 | 46 | 32 | 51 |

EffectsTBL
| GUID | Name | Desc. | Target | Modifier | Duration |
| ABC123 | Planet Vortex Deflector | Stops any artifacts or Abilities from being used for 24 hours | Planet | -100 | -1 |
| 1C2C3C | Livorithic Stem | Gives planet a 10% Mining Bonus | Planet | 1.1 | -2 |
| ACBC2C | Crimson Amplifier | Gives planet a 10% Mining Bonus | Ship | 1.15 | 640 |
| FE6C29 | Advanced Civilization Ruins | Gives planet a 10% Artifact Bonus | Planet | 1.10 | -1 |

PlanetEffectsTBL
| PlanetGUID | EffectGUID | DateTimeAPPlied |
| 000001 | ABC123 | 2012-01-07 03:42 |
| 575403 | 1C2C3C | 2011-09-18 10:45 |
| 010101 | 1C2C3C | 2011-10-04 15:11 |
| 575403 | ABC123 | 2012-01-07 17:23 |
| 000001 | 1C2C3C | 2011-12-04 22:18 |
| 575403 | FE6C29 | 2012-12-12 16:34 |

Some method would then cull the temp effects, OR there would be two tables one for Temp, one for Perm, but that seems excessive, considering some "perm" effects are only as long as a structure is present, though perhaps those are their on table as well.

there will be views which will assist the code to display the stuff we see on the web page, but to be strait, simply adding a column would not be worth doing, there is such a small ability to exploit this loop-hole compared with the over-head to stop it, that it hardly seems worth it.

-Q

There are already caps when using artifacts on planets, figure out a cap and then apply it. If you try to use a toxic purifier on a 17x, it won't let you. Clearly, data cubes were meant to be more rare and harder to acquire, so the number should be larger. It should not be that difficult to find something that doesn't annoy everybody, and it wouldn't require a change to the planet database which has got to be really scary looking. Especially considering the new effects that were just added.

it only takes 2 lines of code change to solve that porblem if the codes are properly written.
I spent my summer interning at a place and wrote a message send/recieve system. And added columns constantly to add functionaliyy(type of mail, sender category, priority and such)
because the only part that should interface with database is ur DO, and you only have two places where you interface with the data. A get and a write. And each column is "taken care of" by 1 line of code.

In fact, depend on the db and code used, ADDING a column might NOT REQUIRE any code change. Simply speaking, if u call data by using column names instead of number from the returned data, then the program does NOT require u to use all that you have recieved.
Although removing a column would be hell.... you would have to manually remove everything that uses it or the program will bug out. But we are adding and not removing so we are fine.

Although I must say I don't know what kind of data style dan uses, so I can't be certain that it will be an easy job. But it could be 20 min of code if not less.

On a side note.... i now feel kinda stupid... use 1 int (3 ints total) would be sufficent to track each type of arts. and being a small int (0 to 6), you can actully store all 3 as a coded char, which takes much smaller data size, almost negligible.
and the code would take smaller run time too~

I think you're finally getting it, the stuff I wrote was all supposition, but there are tons of ways of doing things, and I didn't even get into views, and stored procedures, as whatever writes to that table will need to be modified, and what if Dan does already write all the planet into to one flat table, then it would be even harder.

and yes, in your pseudo code of course you would just check that the value returned < 6, and apply the cube is allowed otherwise denied I wasn't gonna bop you over the head w/ that mate, lol.

but again, it's a matter of a really tiny edge case, which would not really be very exploitable, and tracking new data which was not tracked before, which always presents a problem when the item was used before but not tracked..

~Q