These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

Player Features and Ideas Discussion

 
  • Topic is locked indefinitely.
 

Persistent names for jump clones
Author
Previous Topic Next Topic
Selaria Unbertable
Bellator in Capsulam
#1 - 2015-03-04 15:37:48 UTC
Hello fellow capsuleers,

a few expansions ago CCP allowed us to assign names to jump clones, which made handling them imho a little easier. You can now determine each clone's purpose by looking at its name instead of looking through its implants trying to remember what its use exactly was.
The only problem it seems is, that once you jump from your current clone into another, that name vanishes and you have to rename the clone you just left.
So my proposal is quite simple: store the name for each capsuleer's clone in persistent way either server-side (assuming each single jump clone has an id in the database, and once the capsule is destroyed, that entry in the database is invalid, adding a name row should not be a problem) or on the client.

Fly safe o/
Alvatore DiMarco
Capricious Endeavours Ltd
#2 - 2015-03-04 15:47:14 UTC
I have a pretty strong suspicion that there's a database reason why this doesn't happen. After all, it's such a logical thing that if CCP could do it from the very beginning they would have.
EVE-Lotteries
EVE-Lotteries Corporation
#3 - 2015-03-04 16:58:32 UTC
+1 this could be realy usefull for people that often use them.

You miss blink ? Come and play with us at EVE-Lotteries.com !
Lathalia
Science and Trade Institute
Caldari State
#4 - 2015-03-04 17:03:25 UTC
I can already see the petitioning rain at ccp, cause all names are already taken and therefor unavailable.
Mornak
Exotic Dancers Union
#5 - 2015-03-04 18:08:26 UTC  |  Edited by: Mornak
this would make life easier without any downside, +1 from me.



imho this would not necessarily be a big problem for the DB. I mean it's just another attribute. No need to be able to search for it or anything. It could be ignored for all purposes except displaying it on the character-sheet.


Lathalia wrote:
I can already see the petitioning rain at ccp, cause all names are already taken and therefor unavailable.
This idea is about a name/descrpition of the clone, not the character. No need to be unique. (E.g. "armor active", "kite", ... )
Swiftstrike1
Swiftstrike Incorporated
#6 - 2015-03-04 18:11:26 UTC
+1

Casual Incursion runner & Faction Warfare grunt, ex-Wormholer, ex-Nullbear.
Selaria Unbertable
Bellator in Capsulam
#7 - 2015-03-04 21:37:26 UTC
Alvatore DiMarco wrote:
I have a pretty strong suspicion that there's a database reason why this doesn't happen. After all, it's such a logical thing that if CCP could do it from the very beginning they would have.


This might be true. If this is the case, a client side solution might be possible instead.

Lathalia wrote:
I can already see the petitioning rain at ccp, cause all names are already taken and therefor unavailable.


Not necessarily. I do assume, that each jump clone has its unique id inside the database. Therefore, duplicate names should not be a problem, since the id is the primary attribute, not the name.
Alvatore DiMarco
Capricious Endeavours Ltd
#8 - 2015-03-05 00:15:49 UTC  |  Edited by: Alvatore DiMarco
If I were to take a wild stab at what happens, it may be something like ...

Jump Clones are stored in the database as some manner of object. When you activate a jump clone, the behind-the-scenes process involves "unpacking" the chosen object (which amounts to a set of variables dictating implants and such) and then packing your previously-active clone as a new object in the space the old one was recently occupying. The data from the newly-unpacked clone information is placed in your active character's data space (for lack of a better term) and when everything checks out serverside the client fades your camera in at the new station/Rorqual. The space available for these object-clones is regulated according to a variable that links back to your relevant skill level.

Each clone, however, does not have a persistent ID; it gets a new one every time it's "assembled" or "repackaged", much like any ship or module or can anywhere else in EVE's database - except that ships have very specific IDs when packaged and your repackaged clone identity probably gets whatever number is convenient for the database at the time and appropriate for being assigned to clones.

As your clone's assigned name is stored as part of the object data ("this name links to this object number") and a freshly-repackaged clone is a new object, it would not have that name assigned and there you go with having no name on the jump clone you just left.

That, however, is all theory and may be significantly incorrect.
Selaria Unbertable
Bellator in Capsulam
#9 - 2015-03-05 14:11:13 UTC
Alvatore DiMarco wrote:
If I were to take a wild stab at what happens, it may be something like ...

Jump Clones are stored in the database as some manner of object. When you activate a jump clone, the behind-the-scenes process involves "unpacking" the chosen object (which amounts to a set of variables dictating implants and such) and then packing your previously-active clone as a new object in the space the old one was recently occupying. The data from the newly-unpacked clone information is placed in your active character's data space (for lack of a better term) and when everything checks out serverside the client fades your camera in at the new station/Rorqual. The space available for these object-clones is regulated according to a variable that links back to your relevant skill level.

Each clone, however, does not have a persistent ID; it gets a new one every time it's "assembled" or "repackaged", much like any ship or module or can anywhere else in EVE's database - except that ships have very specific IDs when packaged and your repackaged clone identity probably gets whatever number is convenient for the database at the time and appropriate for being assigned to clones.

As your clone's assigned name is stored as part of the object data ("this name links to this object number") and a freshly-repackaged clone is a new object, it would not have that name assigned and there you go with having no name on the jump clone you just left.

That, however, is all theory and may be significantly incorrect.


Actually, having a diploma in computer science and growing experience with databases, I can tell you that it's not really like that. There is a golden rule when it comes to databases: Never delete. It only makes things worse, since you often have relations between two ore more tables via foreign keys. Once you delete a row that has such a relation to another table, you have to delete ever row in every other table that points to the row you delete. A more elegant way is using flags, in this case, an active flag indicating that you are using this specific jump clone, and maybe another flag for destroyed. And unless CCP deletes destroyed clones from their database, I see no problem in adding a separate attribute for the name. There would be no collisions between different clones using the same name, since the name is not the identifying attribute.