Back

Suggestions

Make Flight Rising better by sharing your ideas!
TOPIC | #UnnamedIsValid
1 2 ... 60 61 62 63 64 ... 162 163
Hi folks, Just a quick reminder [quote name="Aequorin" date="2015-11-18 05:30:26" ] Hey all - Just a head's up: A number of posts have been removed from this thread in accordance with the update to our [url=http://flightrising.com/main.php?p=wiki&article=62][b]Suggestions Forum Policy[/b][/url]: [quote][b]The Suggestions Forum is a discussion forum, not a petition forum. Replies may not have ONLY the following in them:[/b] [LIST] [*]“Support” [*]“No support” [*]Quoting another post [*]Quoting another post with ONLY “support/no support” [/LIST][/quote] Thank you! [/quote]
Hi folks,

Just a quick reminder
Aequorin wrote on 2015-11-18 05:30:26:
Hey all -

Just a head's up: A number of posts have been removed from this thread in accordance with the update to our Suggestions Forum Policy:

Quote:
The Suggestions Forum is a discussion forum, not a petition forum. Replies may not have ONLY the following in them:
  • “Support”
  • “No support”
  • Quoting another post
  • Quoting another post with ONLY “support/no support”

Thank you!
I support this completely. Unnamed can breed and be exalted why not battle? Also, cool lore opportunities!
I support this completely. Unnamed can breed and be exalted why not battle? Also, cool lore opportunities!
Stuff will one day go here.
Support,

While I don't have any permas right now that I want to level unnamed The lore possibilities are wonderful, and I would love to have a lvl25 unnamed perma!
Support,

While I don't have any permas right now that I want to level unnamed The lore possibilities are wonderful, and I would love to have a lvl25 unnamed perma!
809PcaV.png Introverted
Observant
Thinking
Judging
Assertive
floating_hearts_ace_by_awesomewaffle11-dczfieo.gif
#UnamedisValid
TrydZDi.png
WKtl2lb.png

pyAp3dI.png
HjfaxvA.png
I’ve spent some time checking whether having an unnamed dragon in the this myself with a friend who can code, and I’m putting this here for all the people who want to have the option to use an unnamed dragon in the Coliseum for role play and lore purposes to try and explain why it’s probably never going to be possible, so hopefully people can stop feeling hard done by about it. I feel bad about it too; I feel it’s sad that this can’t be an option. Part of this explanation was in another thread but I deleted that because there were errors in it.

The reason people have to name dragons for the coli is for speed. The system needs a name. It can’t use a dragon’s number, and it can’t register unnamed dragons. This will probably never change because the alternative is reduced speed and lag.

When a name is entered into the site’s name bar, it goes straight to the Coli program which is an internal feature of the site, but separate, like the games are. The Coli uses the name and the act of naming to register a dragon. It generates a unique identifier that’s part of the coliseum program’s data and is only for the coli to use, and it compiles data about a dragon like information it can use to display the dragon properly, and to tell which inventory to put the Coli loot. It uses this system because this way the coliseum only has to consider dragons who have names, which means it has less data to sort through, which speeds it up.

When a player brings the dragon into the coliseum, the Coli program doesn’t have to register the dragon again, it just has to check whether any attributes about the dragon have changed and only rewrites the parts of the data it has that might have changed, like apparel, or owner, for example, which is faster than creating a registration for a dragon every time it enters the Coliseum.

This is why players can't take nameless dragons into the coli. The dragon hasn’t been registered yet and has no placeholder the system can recognize.

It’s also why calling a dragon 'Unnamed' doesn't work. The dragon is already called 'Unnamed', so inputting ‘Unnamed’ again makes no changes, and the dragon is still unregistered and the system can’t identify it.

Using the dragon's unique number wouldn't work either, because the system already uses numbers. The players are identified by their numbers.

(Also, if a dragon was registered by its number the second it was hatched it, there would still be potentially unnecessary data in the Coliseum’s database, because the hatchling might never go to the Coliseum. The Coli program might also have to fetch data about whether or not a dragon has been exalted from the site, since all dragons have a number, even exalted ones, which would again make it slower. Much, much slower, because instead of having to sift through a small pool of ‘active’ dragons, it might have to chew through an ever growing database of 50,000,000 + plus bits of data just to find out if a dragon is eligible to be in the Coli. The way it is now, when a dragon is exalted, the site alerts the coli program to archive the data, and the coli program doesn’t have to perform the check when the player enters the coli.)

I asked my friend whether my idea of having a nameless scroll that adds a nameless state to individual dragons would work, and they said definitely not. I was partially right; the only thing that would work would to change site code for all dragons and add an attribute that allows a dragon to appear to have a nameless state, like an option to hide the dragon’s name, but the dragon would still have to have a name for the coliseum. It’s simply not possible for a dragon not to have a name and enter the coliseum.

None of this is ever going to change. It would mean gutting and rewriting most of the code for the site, and the only thing we’ll ever get for it is a slower Coliseum, because it already is as fast and efficient as possible. Shoutout to the devs; my friend admired how well the Coliseum program was integrated with the site and how nimble and quick it is.

For rp purposes, something that might work would be to add a drop down menu to the dragon’s name bar that besides containing a dragon’s real name would also have ‘Unnamed’ as one of the options. It could have a lock feature to hide the dragon’s real name. Some additional coding could be added so the displayed name appears in the parent’s offspring list, so the dragon’s ‘true’ name can be kept secret.

My friend said this might be much more likely to happen, because it doesn’t require any massive changes, only a little bit of additional code to the site, and no changes to the Coliseum. The neat thing about this is, there’s no reason why the options need to be limited to two, the ‘Unnamed’ option and the dragon’s Coliseum name. The dragon could have multiple names! It would probably negate the need for a rename scroll, but I bet people would still use those to change a dragon’s Coliseum name to something they like better.

I’ve spent some time checking whether having an unnamed dragon in the this myself with a friend who can code, and I’m putting this here for all the people who want to have the option to use an unnamed dragon in the Coliseum for role play and lore purposes to try and explain why it’s probably never going to be possible, so hopefully people can stop feeling hard done by about it. I feel bad about it too; I feel it’s sad that this can’t be an option. Part of this explanation was in another thread but I deleted that because there were errors in it.

The reason people have to name dragons for the coli is for speed. The system needs a name. It can’t use a dragon’s number, and it can’t register unnamed dragons. This will probably never change because the alternative is reduced speed and lag.

When a name is entered into the site’s name bar, it goes straight to the Coli program which is an internal feature of the site, but separate, like the games are. The Coli uses the name and the act of naming to register a dragon. It generates a unique identifier that’s part of the coliseum program’s data and is only for the coli to use, and it compiles data about a dragon like information it can use to display the dragon properly, and to tell which inventory to put the Coli loot. It uses this system because this way the coliseum only has to consider dragons who have names, which means it has less data to sort through, which speeds it up.

When a player brings the dragon into the coliseum, the Coli program doesn’t have to register the dragon again, it just has to check whether any attributes about the dragon have changed and only rewrites the parts of the data it has that might have changed, like apparel, or owner, for example, which is faster than creating a registration for a dragon every time it enters the Coliseum.

This is why players can't take nameless dragons into the coli. The dragon hasn’t been registered yet and has no placeholder the system can recognize.

It’s also why calling a dragon 'Unnamed' doesn't work. The dragon is already called 'Unnamed', so inputting ‘Unnamed’ again makes no changes, and the dragon is still unregistered and the system can’t identify it.

Using the dragon's unique number wouldn't work either, because the system already uses numbers. The players are identified by their numbers.

(Also, if a dragon was registered by its number the second it was hatched it, there would still be potentially unnecessary data in the Coliseum’s database, because the hatchling might never go to the Coliseum. The Coli program might also have to fetch data about whether or not a dragon has been exalted from the site, since all dragons have a number, even exalted ones, which would again make it slower. Much, much slower, because instead of having to sift through a small pool of ‘active’ dragons, it might have to chew through an ever growing database of 50,000,000 + plus bits of data just to find out if a dragon is eligible to be in the Coli. The way it is now, when a dragon is exalted, the site alerts the coli program to archive the data, and the coli program doesn’t have to perform the check when the player enters the coli.)

I asked my friend whether my idea of having a nameless scroll that adds a nameless state to individual dragons would work, and they said definitely not. I was partially right; the only thing that would work would to change site code for all dragons and add an attribute that allows a dragon to appear to have a nameless state, like an option to hide the dragon’s name, but the dragon would still have to have a name for the coliseum. It’s simply not possible for a dragon not to have a name and enter the coliseum.

None of this is ever going to change. It would mean gutting and rewriting most of the code for the site, and the only thing we’ll ever get for it is a slower Coliseum, because it already is as fast and efficient as possible. Shoutout to the devs; my friend admired how well the Coliseum program was integrated with the site and how nimble and quick it is.

For rp purposes, something that might work would be to add a drop down menu to the dragon’s name bar that besides containing a dragon’s real name would also have ‘Unnamed’ as one of the options. It could have a lock feature to hide the dragon’s real name. Some additional coding could be added so the displayed name appears in the parent’s offspring list, so the dragon’s ‘true’ name can be kept secret.

My friend said this might be much more likely to happen, because it doesn’t require any massive changes, only a little bit of additional code to the site, and no changes to the Coliseum. The neat thing about this is, there’s no reason why the options need to be limited to two, the ‘Unnamed’ option and the dragon’s Coliseum name. The dragon could have multiple names! It would probably negate the need for a rename scroll, but I bet people would still use those to change a dragon’s Coliseum name to something they like better.

tumblr_inline_o38xqzuDbi1ts73zp_540.pngGeoPFHZ.png__tDeKDnH.png__L5A1mcs.png
i definitely opposed this a while back but now i’m 100% on board for lore purposes and just simply that you should have full control (within reason of course) over your dragon.
i definitely opposed this a while back but now i’m 100% on board for lore purposes and just simply that you should have full control (within reason of course) over your dragon.
all of my hoards are located here! // free level twenty-four cauldron!
tumblr_inline_nfx4qkzLCB1r6zydg.png
[quote name="Tryvyal" date="2018-09-21 10:34:10" ] The reason people have to name dragons for the coli is for speed. The system needs a name. It can’t use a dragon’s number, and it can’t register unnamed dragons. This will probably never change because the alternative is reduced speed and lag. When a name is entered into the site’s name bar, it goes straight to the Coli program which is an internal feature of the site, but separate, like the games are. The Coli uses the name and the act of naming to register a dragon. It generates a unique identifier that’s part of the coliseum program’s data and is only for the coli to use, and it compiles data about a dragon like information it can use to display the dragon properly, and to tell which inventory to put the Coli loot. It uses this system because this way the coliseum only has to consider dragons who have names, which means it has less data to sort through, which speeds it up. [/quote] The simple solution, since we KNOW name doesn't matter, as you can take multiple dragons with the same name into the coliseum at the same time, is create a place where users can 'register' dragons. The mechanic simply checks for eligibility, and if the only reason the dragon isn't eligible is that it is unnamed, it ignores it and registers the dragon for the coliseum. BTW, the most likely reason why calling a dragon unnamed won't work is that it was banned to prevent people scamming others into thinking they have a free name change. Because other wise, we could name a dragon, which, according to you, registers it, then name it 'Unnamed', but the dragon was still registered, so it shouldn't 'unregister it' because once it is registered, name literally doesn't matter. In fact, thinking about this, if this were a new mechanic, then the code probably wouldn't even have to look at the naming field, just make sure it is eligible otherwise, and register the dragon. Because, again, since names don't have to be unique, it shouldn't matter what is in the naming field once the dragon is registered. All that should matter is that the dragon is registered for the coliseum.
Tryvyal wrote on 2018-09-21 10:34:10:
The reason people have to name dragons for the coli is for speed. The system needs a name. It can’t use a dragon’s number, and it can’t register unnamed dragons. This will probably never change because the alternative is reduced speed and lag.

When a name is entered into the site’s name bar, it goes straight to the Coli program which is an internal feature of the site, but separate, like the games are. The Coli uses the name and the act of naming to register a dragon. It generates a unique identifier that’s part of the coliseum program’s data and is only for the coli to use, and it compiles data about a dragon like information it can use to display the dragon properly, and to tell which inventory to put the Coli loot. It uses this system because this way the coliseum only has to consider dragons who have names, which means it has less data to sort through, which speeds it up.

The simple solution, since we KNOW name doesn't matter, as you can take multiple dragons with the same name into the coliseum at the same time, is create a place where users can 'register' dragons.

The mechanic simply checks for eligibility, and if the only reason the dragon isn't eligible is that it is unnamed, it ignores it and registers the dragon for the coliseum.

BTW, the most likely reason why calling a dragon unnamed won't work is that it was banned to prevent people scamming others into thinking they have a free name change.

Because other wise, we could name a dragon, which, according to you, registers it, then name it 'Unnamed', but the dragon was still registered, so it shouldn't 'unregister it' because once it is registered, name literally doesn't matter.

In fact, thinking about this, if this were a new mechanic, then the code probably wouldn't even have to look at the naming field, just make sure it is eligible otherwise, and register the dragon. Because, again, since names don't have to be unique, it shouldn't matter what is in the naming field once the dragon is registered. All that should matter is that the dragon is registered for the coliseum.

#UnnamedIsValid
Let them Fight
Let them Serve the Deities
Let them Exist in peace!
Dragons needed --->
58610356.png
Breed Characteristic Apparel!

Cuckoo Breed and Mutations!

Change Unnamed in YOUR dragon's profile!
14318365.png
[quote name="Jemadar" date="2018-09-21 10:50:45" ] [quote name="Tryvyal" date="2018-09-21 10:34:10" ] The reason people have to name dragons for the coli is for speed. The system needs a name. It can’t use a dragon’s number, and it can’t register unnamed dragons. This will probably never change because the alternative is reduced speed and lag. When a name is entered into the site’s name bar, it goes straight to the Coli program which is an internal feature of the site, but separate, like the games are. The Coli uses the name and the act of naming to register a dragon. It generates a unique identifier that’s part of the coliseum program’s data and is only for the coli to use, and it compiles data about a dragon like information it can use to display the dragon properly, and to tell which inventory to put the Coli loot. It uses this system because this way the coliseum only has to consider dragons who have names, which means it has less data to sort through, which speeds it up. [/quote] The simple solution, since we KNOW name doesn't matter, as you can take multiple dragons with the same name into the coliseum at the same time, is create a place where users can 'register' dragons. [...] In fact, thinking about this, if this were a new mechanic, then the code probably wouldn't even have to look at the naming field, just make sure it is eligible otherwise, and register the dragon. Because, again, since names don't have to be unique, it shouldn't matter what is in the naming field once the dragon is registered. All that should matter is that the dragon is registered for the coliseum. [/quote] The [i]name itself[/i] doesn't matter, but the [i]act[/i] of naming the dragon does matter because that's when the "register the dragon for the coliseum" event triggers. While your suggestion is parsimonious and logical, we [i]don't[/i] know how much implementation time would actually be required to create a second way to register unnamed dragons by clicking a button in the coliseum. Nor how much time it would take to make sure there are no double registrations if someone later names an Unnamed dragon that's been registered. Probably setting an IS_REGISTERED flag on a dragon is all that's needed, but without seeing their code, I don't know how many places would require changes implemented to take that into account. Adding branching structure to programs to prevent undesired behavior is sometimes not straightforward. Alternately, you could totally decouple naming from Coliseum registration by putting a "register for coliseum" button on the dragon's profile, but then that becomes another speedbump for people during exaltation pushes. :T So, yes, sure, you can change the code to accommodate Unnamed dragons without totally breaking things but it's a more involved process than "well just switch this around and add another button". @Tryvyal is there any reason why the above doesn't work? Also thank you to you & your friend for the extensive reverse-engineering job and great explanation!
Jemadar wrote on 2018-09-21 10:50:45:
Tryvyal wrote on 2018-09-21 10:34:10:
The reason people have to name dragons for the coli is for speed. The system needs a name. It can’t use a dragon’s number, and it can’t register unnamed dragons. This will probably never change because the alternative is reduced speed and lag.

When a name is entered into the site’s name bar, it goes straight to the Coli program which is an internal feature of the site, but separate, like the games are. The Coli uses the name and the act of naming to register a dragon. It generates a unique identifier that’s part of the coliseum program’s data and is only for the coli to use, and it compiles data about a dragon like information it can use to display the dragon properly, and to tell which inventory to put the Coli loot. It uses this system because this way the coliseum only has to consider dragons who have names, which means it has less data to sort through, which speeds it up.

The simple solution, since we KNOW name doesn't matter, as you can take multiple dragons with the same name into the coliseum at the same time, is create a place where users can 'register' dragons.

[...]

In fact, thinking about this, if this were a new mechanic, then the code probably wouldn't even have to look at the naming field, just make sure it is eligible otherwise, and register the dragon. Because, again, since names don't have to be unique, it shouldn't matter what is in the naming field once the dragon is registered. All that should matter is that the dragon is registered for the coliseum.

The name itself doesn't matter, but the act of naming the dragon does matter because that's when the "register the dragon for the coliseum" event triggers. While your suggestion is parsimonious and logical, we don't know how much implementation time would actually be required to create a second way to register unnamed dragons by clicking a button in the coliseum.

Nor how much time it would take to make sure there are no double registrations if someone later names an Unnamed dragon that's been registered. Probably setting an IS_REGISTERED flag on a dragon is all that's needed, but without seeing their code, I don't know how many places would require changes implemented to take that into account. Adding branching structure to programs to prevent undesired behavior is sometimes not straightforward.

Alternately, you could totally decouple naming from Coliseum registration by putting a "register for coliseum" button on the dragon's profile, but then that becomes another speedbump for people during exaltation pushes. :T

So, yes, sure, you can change the code to accommodate Unnamed dragons without totally breaking things but it's a more involved process than "well just switch this around and add another button".

@Tryvyal is there any reason why the above doesn't work? Also thank you to you & your friend for the extensive reverse-engineering job and great explanation!

LTuUX3R.png

everything happens so much
nrPzdF6.png

I'M GONNA DRINK IT LIKE A PERSON
[quote name="Plagueheart" date="2018-09-21 13:26:19" ] [quote name="Jemadar" date="2018-09-21 10:50:45" ] [quote name="Tryvyal" date="2018-09-21 10:34:10" ] The reason people have to name dragons for the coli is for speed. The system needs a name. It can’t use a dragon’s number, and it can’t register unnamed dragons. This will probably never change because the alternative is reduced speed and lag. When a name is entered into the site’s name bar, it goes straight to the Coli program which is an internal feature of the site, but separate, like the games are. The Coli uses the name and the act of naming to register a dragon. It generates a unique identifier that’s part of the coliseum program’s data and is only for the coli to use, and it compiles data about a dragon like information it can use to display the dragon properly, and to tell which inventory to put the Coli loot. It uses this system because this way the coliseum only has to consider dragons who have names, which means it has less data to sort through, which speeds it up. [/quote] The simple solution, since we KNOW name doesn't matter, as you can take multiple dragons with the same name into the coliseum at the same time, is create a place where users can 'register' dragons. [...] In fact, thinking about this, if this were a new mechanic, then the code probably wouldn't even have to look at the naming field, just make sure it is eligible otherwise, and register the dragon. Because, again, since names don't have to be unique, it shouldn't matter what is in the naming field once the dragon is registered. All that should matter is that the dragon is registered for the coliseum. [/quote] The [i]name itself[/i] doesn't matter, but the [i]act[/i] of naming the dragon does matter because that's when the "register the dragon for the coliseum" event triggers. While your suggestion is parsimonious and logical, we [i]don't[/i] know how much implementation time would actually be required to create a second way to register unnamed dragons by clicking a button in the coliseum. Nor how much time it would take to make sure there are no double registrations if someone later names an Unnamed dragon that's been registered. Probably setting an IS_REGISTERED flag on a dragon is all that's needed, but without seeing their code, I don't know how many places would require changes implemented to take that into account. Adding branching structure to programs to prevent undesired behavior is sometimes not straightforward. Alternately, you could totally decouple naming from Coliseum registration by putting a "register for coliseum" button on the dragon's profile, but then that becomes another speedbump for people during exaltation pushes. :T So, yes, sure, you can change the code to accommodate Unnamed dragons without totally breaking things but it's a more involved process than "well just switch this around and add another button". [/quote] As you said, have an Is registered flag to thing, which yeah, isn't always as easy as it seems, but since I don't know the coding, it might already be something that is done, to prevent too many checks on already registered dragons. Then again, instead of a flag, during the registration process, since it has to keep the unique ID somewhere, just have a check for that ID. If it is whatever the default for ineligible dragons is, (say -1), check to see if the only thing ineligible about the dragon is the name and then register it. While this would be another check, it is checking something that already exists, so no need to add new fields to anything. I wonder how the coliseum handles when a dragon becomes ineligible for the coliseum, by being too low on energy or whatever? Does the unique ID get wiped out? Then when the dragon is eligible again, it gets a new id, or does it get its old one back. I also thought of having all dragons need to be registered for the coliseum, but like you, I figured it would be too much of a hassle, especially for heavy trainers.
Plagueheart wrote on 2018-09-21 13:26:19:
Jemadar wrote on 2018-09-21 10:50:45:
Tryvyal wrote on 2018-09-21 10:34:10:
The reason people have to name dragons for the coli is for speed. The system needs a name. It can’t use a dragon’s number, and it can’t register unnamed dragons. This will probably never change because the alternative is reduced speed and lag.

When a name is entered into the site’s name bar, it goes straight to the Coli program which is an internal feature of the site, but separate, like the games are. The Coli uses the name and the act of naming to register a dragon. It generates a unique identifier that’s part of the coliseum program’s data and is only for the coli to use, and it compiles data about a dragon like information it can use to display the dragon properly, and to tell which inventory to put the Coli loot. It uses this system because this way the coliseum only has to consider dragons who have names, which means it has less data to sort through, which speeds it up.

The simple solution, since we KNOW name doesn't matter, as you can take multiple dragons with the same name into the coliseum at the same time, is create a place where users can 'register' dragons.

[...]

In fact, thinking about this, if this were a new mechanic, then the code probably wouldn't even have to look at the naming field, just make sure it is eligible otherwise, and register the dragon. Because, again, since names don't have to be unique, it shouldn't matter what is in the naming field once the dragon is registered. All that should matter is that the dragon is registered for the coliseum.

The name itself doesn't matter, but the act of naming the dragon does matter because that's when the "register the dragon for the coliseum" event triggers. While your suggestion is parsimonious and logical, we don't know how much implementation time would actually be required to create a second way to register unnamed dragons by clicking a button in the coliseum.

Nor how much time it would take to make sure there are no double registrations if someone later names an Unnamed dragon that's been registered. Probably setting an IS_REGISTERED flag on a dragon is all that's needed, but without seeing their code, I don't know how many places would require changes implemented to take that into account. Adding branching structure to programs to prevent undesired behavior is sometimes not straightforward.

Alternately, you could totally decouple naming from Coliseum registration by putting a "register for coliseum" button on the dragon's profile, but then that becomes another speedbump for people during exaltation pushes. :T

So, yes, sure, you can change the code to accommodate Unnamed dragons without totally breaking things but it's a more involved process than "well just switch this around and add another button".
As you said, have an Is registered flag to thing, which yeah, isn't always as easy as it seems, but since I don't know the coding, it might already be something that is done, to prevent too many checks on already registered dragons.

Then again, instead of a flag, during the registration process, since it has to keep the unique ID somewhere, just have a check for that ID. If it is whatever the default for ineligible dragons is, (say -1), check to see if the only thing ineligible about the dragon is the name and then register it.

While this would be another check, it is checking something that already exists, so no need to add new fields to anything.

I wonder how the coliseum handles when a dragon becomes ineligible for the coliseum, by being too low on energy or whatever? Does the unique ID get wiped out? Then when the dragon is eligible again, it gets a new id, or does it get its old one back.


I also thought of having all dragons need to be registered for the coliseum, but like you, I figured it would be too much of a hassle, especially for heavy trainers.

#UnnamedIsValid
Let them Fight
Let them Serve the Deities
Let them Exist in peace!
Dragons needed --->
58610356.png
Breed Characteristic Apparel!

Cuckoo Breed and Mutations!

Change Unnamed in YOUR dragon's profile!
14318365.png
@Plagueheart No, no reason, except for the programming and testing, which would be huge. There would be changes to the coli program, a complete change to how a dragon is registered and what information is used, plus changing all registries for every dragon already in the Colosseum so they're compatible, including the ones for every dragon that's been exalted for the last two weeks. Plus once the devs are done, the Coli program will be bigger and more unwieldy because of the extra attribute it has to consider, and therefore slower, but probably not by much. The devs will definitely save everything for the Coli revamp.

We wouldn't need a button in the coli, we'd only need a button on the dragon's page, one push and the registration process starts. The trick would be to only make it work once and have players accept that, and maybe give a 'deregister' option as a cosmetic. I can just visualize people pressing the button over and over again because it's a button and what it would do to the system to have even one dragon registered twice or over and over again. Even one dragon registered twice would make the coli program crash.

The way the system is now, the dragon is only registered once, and then its name becomes an attribute, so when it's changed, only a piece of the data in the coli program changes.

One reason why your way might not work is because it's faster than inputting a name, and the player knows they're doing it because they want to go into the coli. If there's a wait time, the player will notice. Bulk registration is a possibility, and it might overload the system depending on how many people would be doing it. I don't know how much activity the system can take.

Right now most players who name dragons don't know the dragon is being registered because they're rping. They might name the dragon and then do something completely different that has nothing to do with the Coliseum. Because of this the time it takes to register a dragon is hidden. Exalters aren't aware of it either, because they're doing something while it's happening, if only switching to the tab that has the party selection screen and reloading it, and also they already have to push a button and then give each dragon a tag manually and individually, which spaces out the registration process and gives the Coli program tons of time to create the initial data it needs. The registration process could be really slow, it might even take seconds, might be ongoing while the coli screen is loading, and the player wouldn't know because it's all hidden.

On the flip side, this might be beneficial to the Coliseum program. Besides exalts, I only regularly take 6 dragons into the Coliseum. The rest of my named dragons will probably never go. There's no reason for them to have data in the Coliseum at all, and given the option I might not register them. If everybody was like this, it might mean much less data for the Coliseum program to sort through, which would make the program load faster.



@Plagueheart No, no reason, except for the programming and testing, which would be huge. There would be changes to the coli program, a complete change to how a dragon is registered and what information is used, plus changing all registries for every dragon already in the Colosseum so they're compatible, including the ones for every dragon that's been exalted for the last two weeks. Plus once the devs are done, the Coli program will be bigger and more unwieldy because of the extra attribute it has to consider, and therefore slower, but probably not by much. The devs will definitely save everything for the Coli revamp.

We wouldn't need a button in the coli, we'd only need a button on the dragon's page, one push and the registration process starts. The trick would be to only make it work once and have players accept that, and maybe give a 'deregister' option as a cosmetic. I can just visualize people pressing the button over and over again because it's a button and what it would do to the system to have even one dragon registered twice or over and over again. Even one dragon registered twice would make the coli program crash.

The way the system is now, the dragon is only registered once, and then its name becomes an attribute, so when it's changed, only a piece of the data in the coli program changes.

One reason why your way might not work is because it's faster than inputting a name, and the player knows they're doing it because they want to go into the coli. If there's a wait time, the player will notice. Bulk registration is a possibility, and it might overload the system depending on how many people would be doing it. I don't know how much activity the system can take.

Right now most players who name dragons don't know the dragon is being registered because they're rping. They might name the dragon and then do something completely different that has nothing to do with the Coliseum. Because of this the time it takes to register a dragon is hidden. Exalters aren't aware of it either, because they're doing something while it's happening, if only switching to the tab that has the party selection screen and reloading it, and also they already have to push a button and then give each dragon a tag manually and individually, which spaces out the registration process and gives the Coli program tons of time to create the initial data it needs. The registration process could be really slow, it might even take seconds, might be ongoing while the coli screen is loading, and the player wouldn't know because it's all hidden.

On the flip side, this might be beneficial to the Coliseum program. Besides exalts, I only regularly take 6 dragons into the Coliseum. The rest of my named dragons will probably never go. There's no reason for them to have data in the Coliseum at all, and given the option I might not register them. If everybody was like this, it might mean much less data for the Coliseum program to sort through, which would make the program load faster.



tumblr_inline_o38xqzuDbi1ts73zp_540.pngGeoPFHZ.png__tDeKDnH.png__L5A1mcs.png
The speculation about the coding of the coliseum is not necessarily accurate, only the site coders could tell us the exact nitty gritty of what is going on. Some of what is suggested doesn’t make sense to me as Unnamed dragons and hatchings already load in the coliseum, they just can’t be pulled into a team so it’s not that the coliseum can’t pull Unnamed dragons into a party. Before the coliseum revamp neither hatchlings nor Unnamed dragons show on the list of dragons they added the ability in the revamp. When you click on an Unnamed dragon or a hatchling, all the stats and stones can be viewed so that is not something that is generated when ‘registering’ the dragon. So it’s not going to increase load by having Unnamed dragons eligible as that information already exists
The speculation about the coding of the coliseum is not necessarily accurate, only the site coders could tell us the exact nitty gritty of what is going on. Some of what is suggested doesn’t make sense to me as Unnamed dragons and hatchings already load in the coliseum, they just can’t be pulled into a team so it’s not that the coliseum can’t pull Unnamed dragons into a party. Before the coliseum revamp neither hatchlings nor Unnamed dragons show on the list of dragons they added the ability in the revamp. When you click on an Unnamed dragon or a hatchling, all the stats and stones can be viewed so that is not something that is generated when ‘registering’ the dragon. So it’s not going to increase load by having Unnamed dragons eligible as that information already exists
3DS Friend Code: 5300-9941-4980
#UnnamedIsValid .:. Nature Sales Thread .:. Strider Subspecies
1 2 ... 60 61 62 63 64 ... 162 163