Back

Suggestions

Make Flight Rising better by sharing your ideas!
TOPIC | Option to Remove/Disable BoE eyes
1 2 3 4 5
I think it would be doable to be able to toggle eyes on an individual basis.

For the dragon image in the Lair, I believe it is constructed like the scrying workshop, and dressing room, then 'flattened' into one single image. This allows things to be changed on the dragon, without players having to update whereever that dragon is displayed.

So, it wouldn't need to unflatten an image, just do the check before the image is flattened.

I have always supported things like this to allow players to curate their own experiences. This is a game, and something players use to relax.
I think it would be doable to be able to toggle eyes on an individual basis.

For the dragon image in the Lair, I believe it is constructed like the scrying workshop, and dressing room, then 'flattened' into one single image. This allows things to be changed on the dragon, without players having to update whereever that dragon is displayed.

So, it wouldn't need to unflatten an image, just do the check before the image is flattened.

I have always supported things like this to allow players to curate their own experiences. This is a game, and something players use to relax.

#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
@Almedha I legit cannot tell what I'm supposed to be looking at here?
@Almedha I legit cannot tell what I'm supposed to be looking at here?
(Please don't ping me in the Suggestions Forum).
Trix But, in the dragon lair, if you do a view image on a dragon, the url ends in basically the Dragon ID even if the dragon is naked and doesn't have a skin. However, if you do that on a dragon in the Scrying workshop, even one of the dragons you own, the URL reflects the sex, genes, breed, colors and even whether or not it is a hatchling. The first dragon Almedha posted was from the lair, so it ended wit hthe dragon ID. The second dragon was from the scrying workshop, so the url was broken up into the compoent parts. [code]https://www1.flightrising.com/rendern/350/573197/57319656_350.png[/code] [code]https://www1.flightrising.com/dgen/preview/dragon?age=1&body=52&bodygene=13&breed=2&element=3&eyetype=0&gender=1&tert=113&tertgene=10&winggene=16&wings=78&auth=0ca30f9dbc861a96bdab973cca21834cba2daba2&dummyext=prev.png[/code] There are the links to the two dragons.
Trix

But, in the dragon lair, if you do a view image on a dragon, the url ends in basically the Dragon ID even if the dragon is naked and doesn't have a skin.

However, if you do that on a dragon in the Scrying workshop, even one of the dragons you own, the URL reflects the sex, genes, breed, colors and even whether or not it is a hatchling.

The first dragon Almedha posted was from the lair, so it ended wit hthe dragon ID.

The second dragon was from the scrying workshop, so the url was broken up into the compoent parts.
Code:
https://www1.flightrising.com/rendern/350/573197/57319656_350.png
Code:
https://www1.flightrising.com/dgen/preview/dragon?age=1&body=52&bodygene=13&breed=2&element=3&eyetype=0&gender=1&tert=113&tertgene=10&winggene=16&wings=78&auth=0ca30f9dbc861a96bdab973cca21834cba2daba2&dummyext=prev.png

There are the links to the two dragons.

#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
Support. I believe FR could implement a trigger tag system where certain eye types (+ possibly genes? Idk if people are uncomfy with those) are blocked if chosen. I don't think it should automatically switch to common though, I think you should be met with a blocked image and an option to click on anyways
Support. I believe FR could implement a trigger tag system where certain eye types (+ possibly genes? Idk if people are uncomfy with those) are blocked if chosen. I don't think it should automatically switch to common though, I think you should be met with a blocked image and an option to click on anyways


micah | he/him | FR+3
mneBrSJ.png
[quote name="Almedha" date="2020-12-04 06:03:11" ] [quote name="RedWillia" date="2020-12-04 01:17:14" ] I don't think that changing to common is feasible, mostly due to the same concerns as Almedha. However, perhaps it could work as blocking, where if the image contains one of the blocked elements, then it's replaced by a static image "this dragon contains blocked element: X eyes. Click to view". You could make all eyes common in your own lair and would be able to choose which dragons to view in other lairs or in widgets. Weak spot: AH, where I'm leaning to this blocking to not work for performance issues because you can curate what you see in AH by choosing to show only common-eyed dragons anyway. [/quote] You don't think it's the checking (untangling the flat image to check whether a specific gene is present for every dragon image encountered) that would be the most lag-heavy? Because that seems to make the most sense to me. I agree that this isn't really needed in the AH either way, though. [/quote] No, because the dragon database also has the genes/eye types as separate data points - how else would the dragon profiles show which genes each dragon has? So I imagine it would just be a matter of checking the flat database and then using an IF logic to show either the base blocked image or the full dragon. EDIT: and I know that the database has separate data points for each gene because I had reported a bug where Keel text in the dragon genetics was shown in size 11 (iirc), as opposed to most other modern genes in size 12 - which in my opinion means that the dragon profiles are generated from a database that takes dragon features and applies certain formatting to the text depending on the data. Most ancient genes, which are long, are also formatted in the smaller text size.
Almedha wrote on 2020-12-04 06:03:11:
RedWillia wrote on 2020-12-04 01:17:14:
I don't think that changing to common is feasible, mostly due to the same concerns as Almedha.

However, perhaps it could work as blocking, where if the image contains one of the blocked elements, then it's replaced by a static image "this dragon contains blocked element: X eyes. Click to view". You could make all eyes common in your own lair and would be able to choose which dragons to view in other lairs or in widgets. Weak spot: AH, where I'm leaning to this blocking to not work for performance issues because you can curate what you see in AH by choosing to show only common-eyed dragons anyway.
You don't think it's the checking (untangling the flat image to check whether a specific gene is present for every dragon image encountered) that would be the most lag-heavy? Because that seems to make the most sense to me.

I agree that this isn't really needed in the AH either way, though.

No, because the dragon database also has the genes/eye types as separate data points - how else would the dragon profiles show which genes each dragon has? So I imagine it would just be a matter of checking the flat database and then using an IF logic to show either the base blocked image or the full dragon.

EDIT: and I know that the database has separate data points for each gene because I had reported a bug where Keel text in the dragon genetics was shown in size 11 (iirc), as opposed to most other modern genes in size 12 - which in my opinion means that the dragon profiles are generated from a database that takes dragon features and applies certain formatting to the text depending on the data. Most ancient genes, which are long, are also formatted in the smaller text size.
JQQ3Fjt.png
I support a blocking system similar to blocking users. Let there be a toggle for any eye type, and let the user select what they don't want to see. For dragons that match the criteria, they get replaced with a graphic similar to this: [img]https://i.gyazo.com/b800ce8c8b548787bc88486d044dff6c.png[/img] If you go to the dragon's profile, you'll be able to view the dragon's full image. Nothing gets censored — the dragon only gets blocked until you agree to view it on that page. Similar to the maturity feature on deviantART. There are two reasons why I don't support a "revert to common" feature: [list=1][*]People's dragons should look how they want them to. Maybe someone put a lot of effort into their Shadow Primal Gen 1 and displays them in the first lair slot on their profile. Their efforts should not be compromised. [*]The attributes section on a dragon's profile is very small. If an artist has Shadow Primal blocked, they may not realize that the dragon actually has Shadow Primal, and then draw the dragon with common eyes by mistake.[/list] Could make the feature available with all genes, too.
I support a blocking system similar to blocking users.

Let there be a toggle for any eye type, and let the user select what they don't want to see. For dragons that match the criteria, they get replaced with a graphic similar to this:
b800ce8c8b548787bc88486d044dff6c.png

If you go to the dragon's profile, you'll be able to view the dragon's full image. Nothing gets censored — the dragon only gets blocked until you agree to view it on that page. Similar to the maturity feature on deviantART.

There are two reasons why I don't support a "revert to common" feature:
  1. People's dragons should look how they want them to. Maybe someone put a lot of effort into their Shadow Primal Gen 1 and displays them in the first lair slot on their profile. Their efforts should not be compromised.
  2. The attributes section on a dragon's profile is very small. If an artist has Shadow Primal blocked, they may not realize that the dragon actually has Shadow Primal, and then draw the dragon with common eyes by mistake.

Could make the feature available with all genes, too.
fo11Vhp.png
My understanding is that new eye types were introduced so that colours would be standardized across breeds, something the old eyes lacked. No support for bringing them back because of this. However, I can support a toggle to opt out of breeding special eye types.
My understanding is that new eye types were introduced so that colours would be standardized across breeds, something the old eyes lacked. No support for bringing them back because of this. However, I can support a toggle to opt out of breeding special eye types.
6ntc1cC.jpg
@Trix So sorry; Jemadar got it and I updated my post. I forgot that code was a thing and that would have been a great thing to include... The point is that the image addresses are very different. The one from the lair (the one that gets posted to threads more often than not) is a single image that doesn't distinguish the parts making it up. ------ [quote=RedWillia]No, because the dragon database also has the genes/eye types as separate data points - how else would the dragon profiles show which genes each dragon has? So I imagine it would just be a matter of checking the flat database and then using an IF logic to show either the base blocked image or the full dragon.[/quote] That's a good point, but it seems a leap to me to assume that the two are related in one direction or another (that is, the profile is based on the dragon's image or the dragon's image is based on the profile). And I don't honestly know if it matters from a potential lag perspective because regardless of what is checked, the check has to happen.
@Trix
So sorry; Jemadar got it and I updated my post. I forgot that code was a thing and that would have been a great thing to include... The point is that the image addresses are very different. The one from the lair (the one that gets posted to threads more often than not) is a single image that doesn't distinguish the parts making it up.


RedWillia wrote:
No, because the dragon database also has the genes/eye types as separate data points - how else would the dragon profiles show which genes each dragon has? So I imagine it would just be a matter of checking the flat database and then using an IF logic to show either the base blocked image or the full dragon.
That's a good point, but it seems a leap to me to assume that the two are related in one direction or another (that is, the profile is based on the dragon's image or the dragon's image is based on the profile). And I don't honestly know if it matters from a potential lag perspective because regardless of what is checked, the check has to happen.
Cheerful Chime Almedha | share project
Fandragons
Lore Starts Here (WIP)
I collect Pulsing Relics!
candle-smol.png ____
47432632.png
[quote name="Almedha" date="2020-12-04 09:57:08" ] Trix So sorry; Jemadar got it and I updated my post. I forgot that code was a thing and that would have been a great thing to include... The point is that the image addresses are very different. The one from the lair (the one that gets posted to threads more often than not) is a single image that doesn't distinguish the parts making it up. ------ [quote=RedWillia]No, because the dragon database also has the genes/eye types as separate data points - how else would the dragon profiles show which genes each dragon has? So I imagine it would just be a matter of checking the flat database and then using an IF logic to show either the base blocked image or the full dragon.[/quote] That's a good point, but it seems a leap to me to assume that the two are related in one direction or another (that is, the profile is based on the dragon's image or the dragon's image is based on the profile). And I don't honestly know if it matters from a potential lag perspective because regardless of what is checked, the check has to happen. [/quote] I believe that the lair image IS constructed like the scrying image, but because it has to take into account skins and apparel, it gets 'rendered' down to a single url. It is also the easiest for players to use around the site. But, before the image is displayed, it uses something on the order of the scrying workshop url. I will have to look at the dressing room image, as I haven't used it that often and don't know how that is handled. Edit: I just took a look at the dressing room, and looking at that, if the lair image is 'built' like I think, it might even be possible to block apparel images from showing up as well, as the dressing room just lists the apparel ID. (I had previously thought that it might be pretty much impossible to block apparel images because of them having multiple ones. But it might not be as impossible as I thought) I don't know if they do build the dragon image the way Ithink they do, then render it down to a simple, easy to use/remember url, but if they do, I think something like this, while possibly not easy to code, might at least be feasible.
Almedha wrote on 2020-12-04 09:57:08:
Trix
So sorry; Jemadar got it and I updated my post. I forgot that code was a thing and that would have been a great thing to include... The point is that the image addresses are very different. The one from the lair (the one that gets posted to threads more often than not) is a single image that doesn't distinguish the parts making it up.


RedWillia wrote:
No, because the dragon database also has the genes/eye types as separate data points - how else would the dragon profiles show which genes each dragon has? So I imagine it would just be a matter of checking the flat database and then using an IF logic to show either the base blocked image or the full dragon.
That's a good point, but it seems a leap to me to assume that the two are related in one direction or another (that is, the profile is based on the dragon's image or the dragon's image is based on the profile). And I don't honestly know if it matters from a potential lag perspective because regardless of what is checked, the check has to happen.
I believe that the lair image IS constructed like the scrying image, but because it has to take into account skins and apparel, it gets 'rendered' down to a single url. It is also the easiest for players to use around the site. But, before the image is displayed, it uses something on the order of the scrying workshop url.

I will have to look at the dressing room image, as I haven't used it that often and don't know how that is handled.

Edit: I just took a look at the dressing room, and looking at that, if the lair image is 'built' like I think, it might even be possible to block apparel images from showing up as well, as the dressing room just lists the apparel ID. (I had previously thought that it might be pretty much impossible to block apparel images because of them having multiple ones. But it might not be as impossible as I thought)

I don't know if they do build the dragon image the way Ithink they do, then render it down to a simple, easy to use/remember url, but if they do, I think something like this, while possibly not easy to code, might at least be feasible.

#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="Almedha" date="2020-12-04 09:57:08" ] [quote=RedWillia]No, because the dragon database also has the genes/eye types as separate data points - how else would the dragon profiles show which genes each dragon has? So I imagine it would just be a matter of checking the flat database and then using an IF logic to show either the base blocked image or the full dragon.[/quote] That's a good point, but it seems a leap to me to assume that the two are related in one direction or another (that is, the profile is based on the dragon's image or the dragon's image is based on the profile). And I don't honestly know if it matters from a potential lag perspective because regardless of what is checked, the check has to happen. [/quote] It is not a leap because I'm not saying that - what I'm saying is that dragon image and dragon profile must be related in the way that they both have to [u]point to the same database[/u]. It's inefficient (and prone to accidents) to have two separate databases when one database with two different views is a far simpler solution because you have to maintain only one true dataset. Therefore my (obviously simplified) view is as this Current happenings: access database > fetch data > create dragon (similarly, access database > fetch data > choose correct text formatting > create dragon profile) Updated happening: access database > fetch data > check if the player has [u]any[/u] blocked elements > NO: create dragon ; YES: fetch the static image The check is basically a toggle if no "conversion to common" needs to happen. Either way, I really don't think that a block-like feature for dragons would be a truly impossible feature or create much lag.
Almedha wrote on 2020-12-04 09:57:08:
RedWillia wrote:
No, because the dragon database also has the genes/eye types as separate data points - how else would the dragon profiles show which genes each dragon has? So I imagine it would just be a matter of checking the flat database and then using an IF logic to show either the base blocked image or the full dragon.
That's a good point, but it seems a leap to me to assume that the two are related in one direction or another (that is, the profile is based on the dragon's image or the dragon's image is based on the profile). And I don't honestly know if it matters from a potential lag perspective because regardless of what is checked, the check has to happen.

It is not a leap because I'm not saying that - what I'm saying is that dragon image and dragon profile must be related in the way that they both have to point to the same database. It's inefficient (and prone to accidents) to have two separate databases when one database with two different views is a far simpler solution because you have to maintain only one true dataset. Therefore my (obviously simplified) view is as this

Current happenings:
access database > fetch data > create dragon
(similarly, access database > fetch data > choose correct text formatting > create dragon profile)

Updated happening:
access database > fetch data > check if the player has any blocked elements > NO: create dragon ; YES: fetch the static image

The check is basically a toggle if no "conversion to common" needs to happen. Either way, I really don't think that a block-like feature for dragons would be a truly impossible feature or create much lag.
JQQ3Fjt.png
1 2 3 4 5