Individual print runs will be unaffected by the proposed rule change since you only have to ping 10 people at a time - the real problem is GASP. There’s a lot of good discussion about that in the
GASP suggestion thread.
A dedicated
skin/accent shop would solve a lot of problems, but is a separate thread.
Individual print runs will be unaffected by the proposed rule change since you only have to ping 10 people at a time - the real problem is GASP. There’s a lot of good discussion about that in the
GASP suggestion thread.
A dedicated
skin/accent shop would solve a lot of problems, but is a separate thread.
[quote name="Aequorin" date="2023-10-27 16:07:59" ]
As for approved co-owners, one of the issues we have to consider is how that works with blocking. What happens if a player has blocked the originator of the co-owned pinglist after subscribing? Should the co-owners be able to ping that individual with the list? What if the originator blocks a player, should the co-owners still be able to ping that player with the pinglist?
[/quote]
to go along with the different tiers of pinglists listed in the first post i feel like you could have something like a toggle/setting for blocking behavior? for public pinglists, or any pinglist that can be pinged by multiple people, you pick whether or not blocked players can join the pinglist, and whose blocklists it takes into account.
for something smaller like a shared hatchery or shop pinglist, you would still want it to [i]not[/i] allow blocked players on, because that's a private business sort of interaction and you don't want blocked players there at all. ideally there would be an option to take into account co-owners' blocklists for the pinglist permissions, too.
but for something mostly-public like a dom pinglist or one of the big public sales related ones (g1s, gasp, etc.) you probably wouldn't want to block players from participating. they can't interact with any of the organizers who've got them blocked but they can go through others since its.. a public thing. like someone else mentioned earlier its like giving up the "ownership" of it, and in this case also the blocking ability, for the more public lists. you still own it in technicality because you made it, but its a public list that anyone can join and use.
i definitely don't think this blocking.. feature? should overwrite the blocklist of the person pinging no matter if they're the owner, co-owner, or a community member. (for example, if there's a blocked player on the public list you're pinging they would not receive a ping. or if someone on the pinglist has the pinger blocked, they would not receive a ping) if someone has a player blocked they shouldn't have to compromise their own security for the sake of a public pinglist. i just think that the owner of the pinglist, in the case of a partially or fully public pinglist, should be able to make it public without taking their own blocklist into account! like how public offsite pinglists work currently
different sorts of pinglists have different uses so there's no one-size solution for the blocking issue, i feel. what works for one won't work for all.
Aequorin wrote on 2023-10-27 16:07:59:
As for approved co-owners, one of the issues we have to consider is how that works with blocking. What happens if a player has blocked the originator of the co-owned pinglist after subscribing? Should the co-owners be able to ping that individual with the list? What if the originator blocks a player, should the co-owners still be able to ping that player with the pinglist?
to go along with the different tiers of pinglists listed in the first post i feel like you could have something like a toggle/setting for blocking behavior? for public pinglists, or any pinglist that can be pinged by multiple people, you pick whether or not blocked players can join the pinglist, and whose blocklists it takes into account.
for something smaller like a shared hatchery or shop pinglist, you would still want it to
not allow blocked players on, because that's a private business sort of interaction and you don't want blocked players there at all. ideally there would be an option to take into account co-owners' blocklists for the pinglist permissions, too.
but for something mostly-public like a dom pinglist or one of the big public sales related ones (g1s, gasp, etc.) you probably wouldn't want to block players from participating. they can't interact with any of the organizers who've got them blocked but they can go through others since its.. a public thing. like someone else mentioned earlier its like giving up the "ownership" of it, and in this case also the blocking ability, for the more public lists. you still own it in technicality because you made it, but its a public list that anyone can join and use.
i definitely don't think this blocking.. feature? should overwrite the blocklist of the person pinging no matter if they're the owner, co-owner, or a community member. (for example, if there's a blocked player on the public list you're pinging they would not receive a ping. or if someone on the pinglist has the pinger blocked, they would not receive a ping) if someone has a player blocked they shouldn't have to compromise their own security for the sake of a public pinglist. i just think that the owner of the pinglist, in the case of a partially or fully public pinglist, should be able to make it public without taking their own blocklist into account! like how public offsite pinglists work currently
different sorts of pinglists have different uses so there's no one-size solution for the blocking issue, i feel. what works for one won't work for all.
Hello again, I hope everyone had a lovely weekend! This is going to be a long read.
First, to set the frame for today's response on this topic, which also applies to last week's reply as well. We understand many of you may know this, and if that's you, that's great! We want to make sure everyone reading—not just those posting to this thread or other threads—is aware that our replies on this subject are not intended to be confirmation, rejection, or invalidation of any given or specific player suggestion. Our goal with these responses (surrounding what we knew going in would be a complicated and nuanced development cycle) is to share with you the concerns, laws and regulations, needs, and considerations we always have to keep in mind as we continue to develop this system. And honestly, not just this system, but all features and functions of the game and website, Flight Rising. Development isn't just about content and fun; it's also about identifying problems or needs, asking questions, following potential paths to their worst case scenario, accounting for intentional bad actors, ultimately addressing the problem or need, as well as making sure legal is happy.
We've also seen discussions suggesting the people who were targeted by malicious third-parties via offsite data-sets/spreadsheets are to blame for the current and upcoming changes. And if you are not doing this, this section doesn't apply to you. To be clear: The victims of targeted harassment are not to blame, and if they are now being harassed for reporting previous harassment that needs to stop. What shifted our priorities was the realization—and sometimes, confirmation—that not all spreadsheet owners were going to implement the security settings under their control in order to protect their spreadsheets. That's their right, they should not be harassed for it as this is a game, not a job for our players, and it's simply a reality we have to account for.
This brings us to suggested systems or arguments in favor of not capping mass raw pings which are ultimately dependent upon all players involved maintaining amiable relationships and trust with each other. In other words, these are requests asking us to develop features or not make changes that only work if the honor system is, well, honored. We are aware that many of the larger coalitions of players have taken the necessary steps and are dedicated to maintaining these spreadsheets—we don’t want to discount or even appear to dismiss what is clearly a labor of love, creativity, and skill! It’s legitimately impressive, and you have every right to be proud of yourselves for the detailed systems you created. As developers and as the mis-use of spreadsheets has lead directly to onsite harassment, we have to account for multiple types of spreadsheets, different levels of player dedication to maintaining them, different playstyles, and different player choices.
For offsite spreadsheets in general, we also have to keep in mind that these spreadsheets in many cases have reached the point where they are in fact massive third-party hosted databases of player information. Databases that we are fully unable to protect because they are not ours. We can't stop players from moving offsite for transaction negotiations. We can only ask you to exercise discretion and skepticism if you make this choice, as Flight Rising Support will not be able to help you. This has always been our policy and that has not stopped reports demanding that we take action or moderate situations based off discussions and/or comments on third-party platforms. If we can't validate and verify the data reported to us, our hands are tied. Actioning accounts based on reports utilizing third-party screenshots is a metaphorical can of worms that we cannot open.
Pinglist ownership remains complicated. Equal co-owners without a designated owner also presents liability for you, the player. We need to account for people using pinglist names to make a point, lash out, or just break the rules for the lulz. Having a primary owner simplifies all potential player conflicts. The pinglist owner is the ultimate decider of who can be added or removed as a co-manager, what the pinglist is named, etc. While we're confident that the Dominance and other established groups would not have this issue, we still have to consider every player—including those who might have less noble intentions.
We also have to be in compliance with GDPR, CCPA, and other similar legislation and regulations surrounding data privacy. Pinglists have to have a designated owner because the person who creates it is creating personal content that falls under these laws and regulations. While these requests are rare, when a valid request comes in, we must comply, which means we must account for this specific scenario in all areas of site and game development.
We must be mindful that outside of Dominance and skins and accents, we do not provide site/staff sanction for any one particular style of player-driven gameplay. If someone prefers a specific type of dragon to collect, that's fully valid and we encourage you on your acquisition journey! But what are the implications and how would it backfire if we give official site-supported nods to player-driven gameplay styles? Especially if the playstyle involves monitoring for dragons hatched by players who did not consent to participate in the group? Is what amounts to monitoring other players' hatches something we can officially condone by crafting a system to specifically support that playstyle? These are just some of the questions we have to ask, discuss, and eventually answer when it comes to player-driven playstyles.
And regarding the player-driven groups, a question we're already discussing internally:
How many of these groups utilizing mass raw pings would ultimately be better served by actual site supported features and filters that anyone can use, regardless of playstyle preference? Because some of these groups utilizing mass raw pings and offsite datasets may in fact be filling in the gap for a need we’ve yet to adequately meet. And that should be explored further: By us, as we collect data and feedback, and by you as you discuss this with each other and share your feedback.
On the technical side, mass raw pings will eventually be sunset for pretty much the same reason we prohibit extreme amounts of texts in biography and broadcast fields: It simply isn't scalable. In needing to address the offsite-to-onsite harassment issue, it's required a closer look at how pings are handled. It's easier to address an overflow or flooding issue when everything is in a formal container as opposed to not. In this case, the official pinglist system is the container, designed to be a mass ping container. If something goes sideways, an engineer just needs to address the container, not the entire thread.
Very little is set in stone at this time, outside of compliance with GDPR/similar legislation and sunsetting the ability to send hundreds of raw pings all at once in a forum reply. Maybe the cap is 12, maybe we can adjust it within reason. Regardless of where we land, the raw ping cap itself will be one of the last things determined. In the meantime, please continue to discuss amongst yourselves, and we encourage you to think outside the spreadsheet. Could improved site features negate the need for the spreadsheet/mass raw ping? Where do you feel improvements can be made in the existing system? Thank you for reading, and thank you for being a part of Flight Rising!
Hello again, I hope everyone had a lovely weekend! This is going to be a long read.
First, to set the frame for today's response on this topic, which also applies to last week's reply as well. We understand many of you may know this, and if that's you, that's great! We want to make sure everyone reading—not just those posting to this thread or other threads—is aware that our replies on this subject are not intended to be confirmation, rejection, or invalidation of any given or specific player suggestion. Our goal with these responses (surrounding what we knew going in would be a complicated and nuanced development cycle) is to share with you the concerns, laws and regulations, needs, and considerations we always have to keep in mind as we continue to develop this system. And honestly, not just this system, but all features and functions of the game and website, Flight Rising. Development isn't just about content and fun; it's also about identifying problems or needs, asking questions, following potential paths to their worst case scenario, accounting for intentional bad actors, ultimately addressing the problem or need, as well as making sure legal is happy.
We've also seen discussions suggesting the people who were targeted by malicious third-parties via offsite data-sets/spreadsheets are to blame for the current and upcoming changes. And if you are not doing this, this section doesn't apply to you. To be clear: The victims of targeted harassment are not to blame, and if they are now being harassed for reporting previous harassment that needs to stop. What shifted our priorities was the realization—and sometimes, confirmation—that not all spreadsheet owners were going to implement the security settings under their control in order to protect their spreadsheets. That's their right, they should not be harassed for it as this is a game, not a job for our players, and it's simply a reality we have to account for.
This brings us to suggested systems or arguments in favor of not capping mass raw pings which are ultimately dependent upon all players involved maintaining amiable relationships and trust with each other. In other words, these are requests asking us to develop features or not make changes that only work if the honor system is, well, honored. We are aware that many of the larger coalitions of players have taken the necessary steps and are dedicated to maintaining these spreadsheets—we don’t want to discount or even appear to dismiss what is clearly a labor of love, creativity, and skill! It’s legitimately impressive, and you have every right to be proud of yourselves for the detailed systems you created. As developers and as the mis-use of spreadsheets has lead directly to onsite harassment, we have to account for multiple types of spreadsheets, different levels of player dedication to maintaining them, different playstyles, and different player choices.
For offsite spreadsheets in general, we also have to keep in mind that these spreadsheets in many cases have reached the point where they are in fact massive third-party hosted databases of player information. Databases that we are fully unable to protect because they are not ours. We can't stop players from moving offsite for transaction negotiations. We can only ask you to exercise discretion and skepticism if you make this choice, as Flight Rising Support will not be able to help you. This has always been our policy and that has not stopped reports demanding that we take action or moderate situations based off discussions and/or comments on third-party platforms. If we can't validate and verify the data reported to us, our hands are tied. Actioning accounts based on reports utilizing third-party screenshots is a metaphorical can of worms that we cannot open.
Pinglist ownership remains complicated. Equal co-owners without a designated owner also presents liability for you, the player. We need to account for people using pinglist names to make a point, lash out, or just break the rules for the lulz. Having a primary owner simplifies all potential player conflicts. The pinglist owner is the ultimate decider of who can be added or removed as a co-manager, what the pinglist is named, etc. While we're confident that the Dominance and other established groups would not have this issue, we still have to consider every player—including those who might have less noble intentions.
We also have to be in compliance with GDPR, CCPA, and other similar legislation and regulations surrounding data privacy. Pinglists have to have a designated owner because the person who creates it is creating personal content that falls under these laws and regulations. While these requests are rare, when a valid request comes in, we must comply, which means we must account for this specific scenario in all areas of site and game development.
We must be mindful that outside of Dominance and skins and accents, we do not provide site/staff sanction for any one particular style of player-driven gameplay. If someone prefers a specific type of dragon to collect, that's fully valid and we encourage you on your acquisition journey! But what are the implications and how would it backfire if we give official site-supported nods to player-driven gameplay styles? Especially if the playstyle involves monitoring for dragons hatched by players who did not consent to participate in the group? Is what amounts to monitoring other players' hatches something we can officially condone by crafting a system to specifically support that playstyle? These are just some of the questions we have to ask, discuss, and eventually answer when it comes to player-driven playstyles.
And regarding the player-driven groups, a question we're already discussing internally:
How many of these groups utilizing mass raw pings would ultimately be better served by actual site supported features and filters that anyone can use, regardless of playstyle preference? Because some of these groups utilizing mass raw pings and offsite datasets may in fact be filling in the gap for a need we’ve yet to adequately meet. And that should be explored further: By us, as we collect data and feedback, and by you as you discuss this with each other and share your feedback.
On the technical side, mass raw pings will eventually be sunset for pretty much the same reason we prohibit extreme amounts of texts in biography and broadcast fields: It simply isn't scalable. In needing to address the offsite-to-onsite harassment issue, it's required a closer look at how pings are handled. It's easier to address an overflow or flooding issue when everything is in a formal container as opposed to not. In this case, the official pinglist system is the container, designed to be a mass ping container. If something goes sideways, an engineer just needs to address the container, not the entire thread.
Very little is set in stone at this time, outside of compliance with GDPR/similar legislation and sunsetting the ability to send hundreds of raw pings all at once in a forum reply. Maybe the cap is 12, maybe we can adjust it within reason. Regardless of where we land, the raw ping cap itself will be one of the last things determined. In the meantime, please continue to discuss amongst yourselves, and we encourage you to think outside the spreadsheet. Could improved site features negate the need for the spreadsheet/mass raw ping? Where do you feel improvements can be made in the existing system? Thank you for reading, and thank you for being a part of Flight Rising!
Woof! A super long post, but really informative. There's a lot I hadn't considered like mass pings apparently (but not unsurprisingly) not being scalable. Thank you Aequorin for keeping us in the loop.
Thank you for responding! Yeah, I’m mostly talking here because I would like the feature to be tweaked to support as many use cases as possible. I would like to see the site-supported features be flexible as a baseline exactly so many different playstyles can use it without special nods (I personally worry that a restrictive system could promote a specific playstyle by making others impossible without moving offsite to coordinate it - ie, Dom, choosing to play certain forum games), that pinglists can replace any genuine uses of mass pings that do not have other solutions or be usable (not perfect) in the meantime to full solutions, and so that the sunsetting goes smoothly, given how much money some groups of users put into the site and how many communities have developed that could easily end up going offsite (and creating harassment potential that you cannot handle…).The onsite pinglist helps prevent harassment, so I’d love if that prevention of harassment could be extended to other use cases so people don’t try to get around it.
‘Might it be possible to give co-owners nearly full admin perms but have the final decision on implementing them fall to pinglist originators (something like suggesting a name change and then the original owner can choose whether it’s okay and there is a confirmation screen), and make the ability to transfer who is the originator? The original originator would have to sign off on a transfer. This would keep the single true owner, though I’m not certain how legally feasible it is? Please so correct me.
Thank you for responding! Yeah, I’m mostly talking here because I would like the feature to be tweaked to support as many use cases as possible. I would like to see the site-supported features be flexible as a baseline exactly so many different playstyles can use it without special nods (I personally worry that a restrictive system could promote a specific playstyle by making others impossible without moving offsite to coordinate it - ie, Dom, choosing to play certain forum games), that pinglists can replace any genuine uses of mass pings that do not have other solutions or be usable (not perfect) in the meantime to full solutions, and so that the sunsetting goes smoothly, given how much money some groups of users put into the site and how many communities have developed that could easily end up going offsite (and creating harassment potential that you cannot handle…).The onsite pinglist helps prevent harassment, so I’d love if that prevention of harassment could be extended to other use cases so people don’t try to get around it.
‘Might it be possible to give co-owners nearly full admin perms but have the final decision on implementing them fall to pinglist originators (something like suggesting a name change and then the original owner can choose whether it’s okay and there is a confirmation screen), and make the ability to transfer who is the originator? The original originator would have to sign off on a transfer. This would keep the single true owner, though I’m not certain how legally feasible it is? Please so correct me.
@
Reshiramu
i just want to say i think that, if we truly do have to have a single owner with subsidiary authorized users, i think the ability to transfer ownership without having to fully remake the pinglist is 100% necessary. something like the 2-way-cr system, where either player can initiate but both have to individually confirm and either can cancel would be ideal, i think.
on a larger note, i'm incredibly excited by this part of aequorin's update:
Quote:
And regarding the player-driven groups, a question we're already discussing internally:
How many of these groups utilizing mass raw pings would ultimately be better served by actual site supported features and filters that anyone can use, regardless of playstyle preference? Because some of these groups utilizing mass raw pings and offsite datasets may in fact be filling in the gap for a need we’ve yet to adequately meet. And that should be explored further: By us, as we collect data and feedback, and by you as you discuss this with each other and share your feedback.
even just something like updating dragon search to include a specific age filter – whether something that could allow you to search for an age range based on the digit(s) an id starts with (or any id containing particular number strings, for special id hunters!), define a specific hatch year, or just being able to select from 0-10 years the way we do for the other dropdowns – would be huge for those of us who collect oldies! i can also see something like gasp becoming site-native being a huge boon to the uma community, and i would be excited to see the coders behind that perhaps being invited (temporarily or not!) onto the staff team the way skin artists like osiem and pesticide wound up joining the site art team!
edit: fixed a missing period, and scrolled up to see someone mentioning nest rentals, which is a whole new element (har har) of things that might potentially become site-native – the ability to nest outside of your element! perhaps without having to cede full ownership of your dragons! i believe the suggestion has come up in the past of being able to list an empty nest on the ah for someone to purchase and use, as well as the ability to purchase additional nests in different elements the way that we purchase additional nests in our own elements – there are lots of ways that could be streamlined not to need pinglists at all, which would be huge!
@
Reshiramu
i just want to say i think that, if we truly do have to have a single owner with subsidiary authorized users, i think the ability to transfer ownership without having to fully remake the pinglist is 100% necessary. something like the 2-way-cr system, where either player can initiate but both have to individually confirm and either can cancel would be ideal, i think.
on a larger note, i'm incredibly excited by this part of aequorin's update:
Quote:
And regarding the player-driven groups, a question we're already discussing internally:
How many of these groups utilizing mass raw pings would ultimately be better served by actual site supported features and filters that anyone can use, regardless of playstyle preference? Because some of these groups utilizing mass raw pings and offsite datasets may in fact be filling in the gap for a need we’ve yet to adequately meet. And that should be explored further: By us, as we collect data and feedback, and by you as you discuss this with each other and share your feedback.
even just something like updating dragon search to include a specific age filter – whether something that could allow you to search for an age range based on the digit(s) an id starts with (or any id containing particular number strings, for special id hunters!), define a specific hatch year, or just being able to select from 0-10 years the way we do for the other dropdowns – would be huge for those of us who collect oldies! i can also see something like gasp becoming site-native being a huge boon to the uma community, and i would be excited to see the coders behind that perhaps being invited (temporarily or not!) onto the staff team the way skin artists like osiem and pesticide wound up joining the site art team!
edit: fixed a missing period, and scrolled up to see someone mentioning nest rentals, which is a whole new element (har har) of things that might potentially become site-native – the ability to nest outside of your element! perhaps without having to cede full ownership of your dragons! i believe the suggestion has come up in the past of being able to list an empty nest on the ah for someone to purchase and use, as well as the ability to purchase additional nests in different elements the way that we purchase additional nests in our own elements – there are lots of ways that could be streamlined not to need pinglists at all, which would be huge!
they/them || if you're pinging me, there's only one 'i' in my username!
@
hatesprit I agree, I actually did include a mention of an ownership transfer in my post! Bolded to show where:
Quote:
Might it be possible to give co-owners nearly full admin perms but have the final decision on implementing them fall to pinglist originators (something like suggesting a name change and then the original owner can choose whether it’s okay and there is a confirmation screen), and make the ability to transfer who is the originator?
I mentioned it the way I did because I noted devs were focused on having a single originator for liability reasons. Do agree on confirming being necessary. In a game I play with guild systems, owner transfer is done wholly on the owner’s end, perhaps a middle ground where old owner must initiate but new owner must accept if staff would rather not have all co-owners bd able to request?
@
hatesprit I agree, I actually did include a mention of an ownership transfer in my post! Bolded to show where:
Quote:
Might it be possible to give co-owners nearly full admin perms but have the final decision on implementing them fall to pinglist originators (something like suggesting a name change and then the original owner can choose whether it’s okay and there is a confirmation screen), and make the ability to transfer who is the originator?
I mentioned it the way I did because I noted devs were focused on having a single originator for liability reasons. Do agree on confirming being necessary. In a game I play with guild systems, owner transfer is done wholly on the owner’s end, perhaps a middle ground where old owner must initiate but new owner must accept if staff would rather not have all co-owners bd able to request?
@Aequorin
[quote name="Aequorin" date="2023-10-30 14:14:20" ]We must be mindful that outside of Dominance and skins and accents, we do not provide site/staff sanction for any one particular style of player-driven gameplay. If someone prefers a specific type of dragon to collect, that's fully valid and we encourage you on your acquisition journey! But what are the implications and how would it backfire if we give official site-supported nods to player-driven gameplay styles? Especially if the playstyle involves monitoring for dragons hatched by players who did not consent to participate in the group? Is what amounts to monitoring other players' hatches something we can officially condone by crafting a system to specifically support that playstyle? These are just some of the questions we have to ask, discuss, and eventually answer when it comes to player-driven playstyles.
And regarding the player-driven groups, a question we're already discussing internally:
How many of these groups utilizing mass raw pings would ultimately be better served by actual site supported features and filters that anyone can use, regardless of playstyle preference? Because some of these groups utilizing mass raw pings and offsite datasets may in fact be filling in the gap for a need we’ve yet to adequately meet. And that should be explored further: By us, as we collect data and feedback, and by you as you discuss this with each other and share your feedback.
[/quote]
Responding to this section specifically as it pertains to gen1 collectors as searching for newly hatched dragons is something that we mentioned in the suggestion post coming from the team who run the gen1 hoarders pinglist.
The concern we have about removing the option for collectors groups, such as g1, to collate users specific preferences for dragons they want to by would result in an [b]increase in unsolicited messages[/b] through dragon search due to there being no other way for users to be contacted for specific dragons that they are looking for and instead having to go look for them by themselves.
[b]These pinglists are used to sell, not to buy[/b]
The way these lists operate is firmly putting the decision whether or not to sell in the sellers hand. Yes, you will always still get people who send unsolicited pms when you have a feature like dragons search (and no, it wouldn't be a solution to simply remove it because you will just invite an increase in offsite bots that compile this information anyway). However, having the option of being specifically notified when something you're interested in actually goes up for sale [b]does reduce the number of unsolicited messages[/b].
There is already a filter within the AH and within dragon search that allows for the filtering of gen1 dragons. Adding in a site embedded feature for pings specifically designated for notifying users when somebody has marked for sale a dragon that matches user input criteria and having gen1/not g1 as a feature of this would not be catering to a specific group more than there is already the precedent to do so.
Granted, there is already the option for saved searches in the AH however this only caters to users who definitely want to sell a dragon for a flat price and does not consider auctions or offers or even interest/price checks which are an important factor. An option would need to be added to indicate a dragon is open for offers without having to actually be listed for sale
It should not be the only option for players to have to list their dragons on the AH to get attention to their sales.
@
Aequorin
Aequorin wrote on 2023-10-30 14:14:20:
We must be mindful that outside of Dominance and skins and accents, we do not provide site/staff sanction for any one particular style of player-driven gameplay. If someone prefers a specific type of dragon to collect, that's fully valid and we encourage you on your acquisition journey! But what are the implications and how would it backfire if we give official site-supported nods to player-driven gameplay styles? Especially if the playstyle involves monitoring for dragons hatched by players who did not consent to participate in the group? Is what amounts to monitoring other players' hatches something we can officially condone by crafting a system to specifically support that playstyle? These are just some of the questions we have to ask, discuss, and eventually answer when it comes to player-driven playstyles.
And regarding the player-driven groups, a question we're already discussing internally:
How many of these groups utilizing mass raw pings would ultimately be better served by actual site supported features and filters that anyone can use, regardless of playstyle preference? Because some of these groups utilizing mass raw pings and offsite datasets may in fact be filling in the gap for a need we’ve yet to adequately meet. And that should be explored further: By us, as we collect data and feedback, and by you as you discuss this with each other and share your feedback.
Responding to this section specifically as it pertains to gen1 collectors as searching for newly hatched dragons is something that we mentioned in the suggestion post coming from the team who run the gen1 hoarders pinglist.
The concern we have about removing the option for collectors groups, such as g1, to collate users specific preferences for dragons they want to by would result in an
increase in unsolicited messages through dragon search due to there being no other way for users to be contacted for specific dragons that they are looking for and instead having to go look for them by themselves.
These pinglists are used to sell, not to buy
The way these lists operate is firmly putting the decision whether or not to sell in the sellers hand. Yes, you will always still get people who send unsolicited pms when you have a feature like dragons search (and no, it wouldn't be a solution to simply remove it because you will just invite an increase in offsite bots that compile this information anyway). However, having the option of being specifically notified when something you're interested in actually goes up for sale
does reduce the number of unsolicited messages.
There is already a filter within the AH and within dragon search that allows for the filtering of gen1 dragons. Adding in a site embedded feature for pings specifically designated for notifying users when somebody has marked for sale a dragon that matches user input criteria and having gen1/not g1 as a feature of this would not be catering to a specific group more than there is already the precedent to do so.
Granted, there is already the option for saved searches in the AH however this only caters to users who definitely want to sell a dragon for a flat price and does not consider auctions or offers or even interest/price checks which are an important factor. An option would need to be added to indicate a dragon is open for offers without having to actually be listed for sale
It should not be the only option for players to have to list their dragons on the AH to get attention to their sales.
@
Reshiramu
ah sorry! what i more meant was to agree with you saying that, the '100% necessary' part was directed towards aequorin/staff more than you. my bad that that wasn't clear!
@
Reshiramu
ah sorry! what i more meant was to agree with you saying that, the '100% necessary' part was directed towards aequorin/staff more than you. my bad that that wasn't clear!
they/them || if you're pinging me, there's only one 'i' in my username!
@
hatesprit oh! So sorry about that, I have some tone difficulties. But yes I totally agree with you too, having some way to transfer is absolutely necessary. Maybe a don lead steps down, for example, or a nest network changes ownership… all kibds of different situations that all kinds of different playstyles could have. (The latter bit is to staff too, for clarity! I think that making in house pinglists flexible actually avoids favouring playstyles like staff is concerned about, because a simple public or collab pinglist can be used for so many different things. There are several things that could use in house features, but I will save that for another couple posts because I have another thing in mind….)
@
hatesprit oh! So sorry about that, I have some tone difficulties. But yes I totally agree with you too, having some way to transfer is absolutely necessary. Maybe a don lead steps down, for example, or a nest network changes ownership… all kibds of different situations that all kinds of different playstyles could have. (The latter bit is to staff too, for clarity! I think that making in house pinglists flexible actually avoids favouring playstyles like staff is concerned about, because a simple public or collab pinglist can be used for so many different things. There are several things that could use in house features, but I will save that for another couple posts because I have another thing in mind….)
