Party Buffs (Boosts) Don't Last A Day (skill buffs and cosmetic buffs like snowball)

[deilann]

Unless everyone's cron is synced up, party boosts don't last at all. I imagine it would be terribly difficult to make them last 24 hours, rather than go away upon cron, but it seems kind of frustrating to spend MP on something and then have it only affect your party members for a short period of time.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[ghost]

I agree. I've had instances where I receive no benefit at all from spells cast after I'm done for the day. When I log in a new day starts and the spell ends before I even get any use of it.

[meganstrickland]

I've only tried a party boost once (Healer - Protective Aura), but I'm pretty sure it didn't end up benefiting my party at all because it expired. It would be good to at least get some explanation of how long they last or what triggers them to expire so we can use our MP more wisely.

[deilann]

They last until the player's cron. So with Protective Aura, it doesn't matter when you cast it. Because it lasts until it's wiped out by cron, it will still do its job and buff their CON when it's important.

The problem is with buffs like Tools of the Trade, which are only useful if they are active while the player is checking off tasks and whatnot.

On Sun, Jan 26, 2014 at 12:01 AM, meganstrickland notifications@github.comwrote:

I've only tried a party boost once (Healer - Protective Aura), but I'm pretty sure it didn't end up benefiting my party at all because it expired. It would be good to at least get some explanation of how long they last or what triggers them to expire so we can use our MP more wisely.

— Reply to this email directly or view it on GitHubhttps://github.com/HabitRPG/habitrpg/issues/2523#issuecomment-33311679 .

[DanielTheBard]

Spells ending at cron was the most convenient way to code them, I believe. Ideally, we wanted them to last 24 hours. Otherwise, you'd have to cast spells early on in the day for everyone to really get any benefit out of them. This along with some people having custom day starts causes some obvious problems. Ideally, I hope this is something that can be fixed in the future because it hurts playing more selflessly.

@deilann - Also, not necessarily true. CON boosts also help with minus habits. So it'd be more convenient for your party if you cast it early in the day.

[deilann]

Even if it wasn't for custom day starts, it would be an issue due to time zones.

But having them last for 24 hours... they'd have to keep checking with the server, wouldn't they? Wouldn't be fun.

On Sun, Jan 26, 2014 at 12:09 AM, Daniel the Bard notifications@github.comwrote:

Spells ending at cron was the most convenient way to code them, I believe. Ideally, we wanted them to last 24 hours. Otherwise, you'd have to cast spells early on in the day for everyone to really get any benefit out of them. This along with some people having custom day starts causes some obvious problems. Ideally, I hope this is something that can be fixed in the future because it hurts playing more selflessly.

— Reply to this email directly or view it on GitHubhttps://github.com/HabitRPG/habitrpg/issues/2523#issuecomment-33311784 .

[colegleason]

We could modify the buffs attribute to contain more information, including time that the buff was cast. Every time we access the buffs object, we check if we need to remove the buff.

A lot of work. Eh.

[ghost]

What if spells lasted two crons instead of disappearing on the first? It would be 48 hours for the spell caster, but less for the others while at least providing a 24 hour window where all of the party is buffed. Would that make the spells too powerful? Maybe not a permanent solution but would it work as an interim solution?

[deilann]

Or what if we added a buff attribute and when cron is triggered, it checks to see if the buff is less than 12 hours old? If it is, keep the buff. If it isn't, remove the buff.

On Sun, Jan 26, 2014 at 1:22 PM, Anysia notifications@github.com wrote:

What if spells lasted two crons instead of disappearing on the first? It would be 48 hours for the spell caster, but less for the others while at least providing a 24 hour window where all of the party is buffed. Would that make the spells too powerful?

— Reply to this email directly or view it on GitHubhttps://github.com/HabitRPG/habitrpg/issues/2523#issuecomment-33330867 .

[meganstrickland]

However the devs decide to take it in the future (♥ you, devs!) it would be great to get a little more clarity about how it works now.

@deilann says that spells last until each player's cron, but does that mean the "end of day" time (midnight or custom day start) or when cron actually runs (which could be any time after that)?

If I know I've had a bad day and missed a lot of dailies, how and when should I cast Protective Aura to most effectively shield my party? It seems that I have to do it before my custom day start (otherwise lastcron would run and the damage would get dealt before I had a chance to cast anything), but if I cast it the night before and then my party members log in before I do the next day, the spell ends for them and doesn't help when I log in later and my lastcron runs? If that is all correct, the only way I can be sure to protect my party is if I log in first the next day (with the understanding that what constitutes "the next day" is actually rather complicated when you're talking about different time zones and custom day starts).

Not exactly sure what my question is, but if someone could confirm or correct my understanding of how this works now, that would be much appreciated.

Thank you!

[deilann]

With Protective Aura, it's not going to matter because it will last until that player's cron, when damage is tallied. So they will be protected no matter when you cast it. The buffs last for each player until cron. So you could cast Protective Aura 5 minutes before your cron, be protected, and then it will continue for your party until they reset.

Does that help?

On Sun, Jan 26, 2014 at 5:26 PM, meganstrickland notifications@github.comwrote:

However the devs decide to take it in the future (♥ you, devs!) it would be great to get a little more clarity about how it works now.

@deilann https://github.com/deilann says that spells last until each player's cron, but does that mean the "end of day" time (midnight or custom day start) or when cron actually runs (which could be any time after that)?

If I know I've had a bad day and missed a lot of dailies, how and when should I cast Protective Aura to most effectively shield my party? It seems that I have to do it before my custom day start (otherwise lastcron would run and the damage would get dealt before I had a chance to cast anything), but if I cast it the night before and then my party members log in before I do the next day, the spell ends for them and doesn't help when I log in later and my lastcron runs? If that is all correct, the only way I can be sure to protect my party is if I log in first the next day (with the understanding that what constitutes "the next day" is actually rather complicated when you're talking about different time zones and custom day starts).

Not exactly sure what my question is, but if someone could confirm or correct my understanding of how this works now, that would be much appreciated.

Thank you!

— Reply to this email directly or view it on GitHubhttps://github.com/HabitRPG/habitrpg/issues/2523#issuecomment-33336894 .

[meganstrickland]

@deilann Maybe my confusion is more about when damage from boss battles occur. It appears that there is an interaction with Trapper Santa at each player's cron, so in our 3-person party, Trapper Santa attacks us 3 times each day, and the timing of those attacks depends on when we each log in (and trigger our own cron). Thus, it would be possible for a teammate to log in, trigger her cron, be protected from some damage, and end the spell for herself, before I log in and trigger my cron and the resulting damage. Does that make sense?

[DanielTheBard]

@deilann - As I said before, that's still not true. Protective Aura does matter when you cast it. CON doesn't only affect the damage you take from dailies/bosses at cron. It also affects your "- habits". So to cast it at the very end of the day, prevents your party from getting the advantage of less damage from habits during the day. It will still help with dailies/bosses (or should) but it won't be helping with habits like it could be.

@deilann - AND as you've said that, I realize you might be right. Boss dmg isn't calculated until your party member logs back in. If I don't log in and check out the party until 10pm that day, the boss won't take the dmg I dealt until then, and my party won't take the dmg the boss dealt until then. If no protective aura is up on this new day, it'll deal the normal dmg it should have. The last day's protective aura will have no effect on it. So yeah, protective aura would also appear to not really be doing it's job here. :/

Regardless, we definitely need some kind of fix for this. Too many party spells become useless unless we can have them last a full 24 hours, at least.

[deilann]

Oh man, that's a good point.

On Sun, Jan 26, 2014 at 5:46 PM, meganstrickland notifications@github.comwrote:

@deilann https://github.com/deilann Maybe my confusion is more about when damage from boss battles occur. It appears that there is an interaction with Trapper Santa at each player's cron, so in our 3-person party, Trapper Santa attacks us 3 times each day, and the timing of those attacks depends on when we each log in (and trigger our own cron). Thus, it would be possible for a teammate to log in, trigger her cron, be protected from some damage, and end the spell for herself, before I log in and trigger my cron and the resulting damage. Does that make sense?

— Reply to this email directly or view it on GitHubhttps://github.com/HabitRPG/habitrpg/issues/2523#issuecomment-33337393 .

[deilann]

S'a good point, Daniel. I don't remember you saying that before, but I have such a nasty headache right now, that it could just be my brain isn't functioning.

Either way, this definitely needs to be looked at. I think either having boosts last cron +1 or more than 12 hours would be the least annoying, but I haven't really touched cron because... it's something all right.

On Sun, Jan 26, 2014 at 5:48 PM, Daniel the Bard notifications@github.comwrote:

@deilann https://github.com/deilann - As I said before, that's still not true. Protective Aura does matter when you cast it. CON doesn't only affect the damage you take from dailies/bosses at cron. It also affects your "- habits". So to cast it at the very end of the day, prevents your party from getting the advantage of less damage from habits during the day. It will still help with dailies/bosses (or should) but it won't be helping with habits like it could be.

— Reply to this email directly or view it on GitHubhttps://github.com/HabitRPG/habitrpg/issues/2523#issuecomment-33337441 .

[meganstrickland]

So I just realized that my previous statements don't really make sense given that CON is irrelevant for boss damage. But I still think it would be good to tweak how party buffs work, because it is currently really hard to predict how long they will last or when to cast them to do the most good.

[Ulugbeg]

Hi! Just to get this bug back onto the agenda, I today also ran into this issue :) It was a pity, as I cast a new buff, then after that a partymember logged in, cron-ed, and thereby removed the buff.

Is this by any chance on a shortlist of things which will be fixed in the near future?

[deilann]

No, this is not on the short list. It is sub-optimal but not game breaking On Jul 31, 2014 5:58 AM, "Ulugbeg" notifications@github.com wrote:

Hi! Just to get this bug back onto the agenda, I today also ran into this issue :) It was a pity, as I cast a new buff, then after that a partymember logged in, cron-ed, and thereby removed the buff.

Is this by any chance on a shortlist of things which will be fixed in the near future?

— Reply to this email directly or view it on GitHub https://github.com/HabitRPG/habitrpg/issues/2523#issuecomment-50754859.

[Alys]

See also the points in https://github.com/HabitRPG/habitrpg/issues/3071 (e.g., buffs that last exactly 24 hours have disadvantages)

[Alys]

I think it would be easy to make attribute buffs last through two crons instead of one.

At the moment, the user.stats object has buffs.per, buffs.con, etc. When a skill is cast, the appropriate buff is increased. When cron runs, all buffs are set to zero.

Instead of that, we can have buffs.lastsThroughToday.per, buffs.lastsThroughTomorrow.per, etc. The code that calculates your current attributes counts both of them. When a skill is cast, the buff is added to buffs.lastsThroughTomorrow.... (so it takes effect for today and tomorrow). When cron runs, it deletes the buffs in buffs.lastsThroughToday and then moves the buffs from buffs.lastsThroughTomorrow into buffs.lastsThroughToday (leaving buffs.lastsThroughTomorrow set to zero). This results in every attribute buff lasting until the second cron after it is cast.

A Perfect Day buff would go straight into buffs.lastsThroughToday because there's no need for it to last through two crons (it starts at one cron and finishes at the next).

Something similar could be done with the avatar appearance buffs. The antidotes would remove both today and tomorrow buffs.

The Stealth and Chilling Frost buffs wouldn't change (buffs.stealth and buffs.streaks).

There wouldn't need to be many code changes for this. I think the biggest burden would be adjusting the tests. :P ;)

[Timoteo32]

That's not a bad solution. You still have the problem that people are going to get very different lengths of benefits but culturally we're all expecting 1 day so it's really delivering more than promised even if it's still unpredictable or not fair.

Another idea I had was switching to a manual cron. Instead of a set time (which is already somewhat meaningless in this context) you could have a link that says "end my day". And then cron would happen right then. That way people with erratic bedtimes or who get up at different times in the morning would still have control over their routine.

I think the biggest problem is still that it doesn't cron at the time it's supposed to. If I have it set for 2AM after I go to bed, it still doesn't happen until I get up in the morning. That creates like 8 hours of buffs that are guaranteed to be nullified no matter what I do. If I get up late and don't use my computer, it doesn't happen until I get home from work.

If the server can't sync accounts in real time, cron needs to be put on the stack of updates to be applied to the account in order they happen. Since cron time is a user defined value, it's not like the server would have to constantly check the account for updates, it just needs to manually sync at the defined time.

[veeeeeee]

Suggestion: Have a "pot" that aggregates party buffs, each with the 24 hr period of viability from time of casting + Users can drink from the pot once a day and have those buffs apply until cron time. The drink from the pot-o-buffs would act like an invisible piece of equipment with variable attributes depending on what was in the pot.

The pot itself would display currently available buffs (maybe even with expiration times?), so if you needed, say, extra Tools of the Trade, you could hunt down your party's rogue and request that they contribute to the pot.

Benefits: Buffs are less likely to get "wasted" on team members with drastically different cron times. It acts as a non-passive login incentive (cc: @lemoness) requiring actual interaction with the site. Also, the list of currently-available buffs as a visible party feature might be a nice signifier of team effort based on purely positive accrual, balancing out the potentially negative/mixed one you get from bosses and boss damage.

I'm not married to the pot metaphor--in fact I first discussed this with @Alys by describing users jumping into the pot--but it was the first thing that came to mind.

[lemoness]

Elaborating on the idea of using it as a log-in incentive... what if you got a pop-up at the beginning of the day saying "these buffs are waiting for you! Click to apply" or something along those lines. That way, it would be more obvious. However, I would find such a pop-up annoying throughout the day.

However, I do have some concerns with this. I assume that this would only apply to buffs, not healing? Otherwise, we lose the ability to save players before they log in, which I think is a great feature. And what about transformation items? I don't think that those should have an opt-in, as it ruins the excitement.

In short, I'm a little worried that it adds too much complexity from a user perspective, without a significant gain.

On Thu, Oct 22, 2015 at 4:30 AM, veeeeeee notifications@github.com wrote:

Suggestion: Have a "pot" that aggregates party buffs, each with the 24 hr period of viability from time of casting + Users can drink from the pot once a day and have those buffs apply until cron time. The drink from the pot-o-buffs would act like an invisible piece of equipment with variable attributes depending on what was in the pot.

The pot itself would display currently available buffs (maybe even with expiration times?), so if you needed, say, extra Tools of the Trade, you could hunt down your party's rogue and request that they contribute to the pot.

Benefits: Buffs are less likely to get "wasted" on team members with drastically different cron times. It acts as a non-passive login incentive (cc: @lemoness https://github.com/lemoness) requiring actual interaction with the site. Also, the list of currently-available buffs as a visible party feature might be a nice signifier of team effort based on purely positive accrual, balancing out the potentially negative/mixed one you get from bosses and boss damage.

I'm not married to the pot metaphor--in fact I first discussed this with @Alys https://github.com/Alys by describing users jumping into the pot--but it was the first thing that came to mind.

— Reply to this email directly or view it on GitHub https://github.com/HabitRPG/habitrpg/issues/2523#issuecomment-150188948.

[crookedneighbor]

So, currently, if someone cast a buff at 11pm, it would be applied immediately and disappeared after the user's next cron. So the user could only get the benefit in the hour before their cron, and if they didn't log in at all, they wouldn't get it at all.

What if instead, someone casts a buff at 11pm, if the user logs in before 11, it acts as normal. Lasts till the next cron. If they didn't log in until the next day, it would last till their next cron after that.

[veeeeeee]

@lemoness I imagined that healing behavior would remain the same, as we haven't had complaints on those and they already act differently from buffs. Not sure about transformation items--if we were to convert transformation items to this system as well, I'd imagine it would be less "spell casting" and more "someone left a magical spell-bomb just for you".

As for login-incentive, maybe the option to set the little bubble notification to remind you to check up on the party buff-pot when first logging in.

[Alys]

For avatar transformation buffs, when I cast them, I want to see them take effect immediately. Usually I'm transforming the whole party at once for a consistent effect. My party mates often do the same thing.

[veeeeeee]

@Alys Yes, that makes sense.

In any case, my proposed solution was specifically responding to the problem of buffs wearing off at cron. I'm not sure how many parties out of the total population have this issue. Also, I imagine that the buff-pot solution would get very annoying for solo partiers, unless they tend to mostly stick to individual and not party buffs.

[lemoness]

Personally, I'm drawn more to Blade's idea - it seems much more intuitive. Also, now the more I'm thinking about it, I'm worried about too many notifications requiring actions right when you open the site, especially considering login incentives.

On Thu, Oct 29, 2015 at 2:02 AM, veeeeeee notifications@github.com wrote:

@Alys https://github.com/Alys Yes, that makes sense.

In any case, my proposed solution was specifically responding to the problem of buffs wearing off at cron. I'm not sure how many parties out of the total population have this issue. Also, I imagine that the buff-pot solution would get very annoying for solo partiers, unless they tend to mostly stick to individual and not party buffs.

— Reply to this email directly or view it on GitHub https://github.com/HabitRPG/habitrpg/issues/2523#issuecomment-152118388.

[Alys]

We'd have to define "log in" in this context in a sense that was more useful to the user than normal. If it had the normal meaning (i.e., any action taken by their account), then if they'd left their browser open while they slept and the website's automatic reload happened before cron, or if a mobile app widget refreshed itself, or Beeminder counted their To-Dos (which it does at midnight), then that would count as an action and the buff would be applied, even though the user wasn't benefiting from it.

We could put new buffs into a holding pen, and then apply them to the user only when the user ticked off a task (apply them just before the task action was processed).

But we might want to make an exception for CON buffs, because the user might want them to be applied before cron even if the user wasn't using the site then. That would be especially relevant if the user had asked the party's Healer for a Protective Aura but the Healer didn't see the message until the user had gone to bed.

We could change the cron process to remove the previous day's buffs at the start of cron (instead of the end where it's currently done), and then apply all pending buffs immediately after that (before calculating damage from Dailies) and that would cover the case of a Healer buffing CON after the user had gone to bed, but that would mean that a Healer wouldn't be able to buff themself for that night's Dailies.

Do we want to apply pending buffs at the start of cron, and then remove the previous day's buffs at the end of cron, while keeping the buffs that had been pending? A buff could then potentially last through two cron events, but through only one day of user actions.

[KristianTashkov]

Okay so I have been thinking about this and propose this:

• If you receive a buff and you have no pending cron to be ran on your next interaction, the buff is applied directly. This will cover the normal buffing scenario throughout the day and also you can cast CON on someone when they are away and still work for their next cron.
• If a user has a pending cron, store the buff in a pending buffs field to be applied after his cron. This is where it gets kinda tricky. We can either go the lazy route, where when the user logs in, all the buffs for all the missed days he had since his last ran cron, get applied for a single day. Or the more normal route where we also store a timestamp for each buff modification, and only apply buffs that are after his last scheduled cron time and drop the others.

For UI: since we will want to give feedback for the buff caster, we should probably have a "Pending buffs" field for the attribute which is to be buffed when the user logs in.

Logic for stealth/freeze and avatar transformations should probably stay the same.

Whatever we decide on implementing I'm really interested in coding it :smile:

[Alys]

@KristianTashkov Can you give some details about what you mean by "you have no pending cron to be ran on your next interaction"? Does that mean if the buff is cast before your Custom Day Start time?

[KristianTashkov]

Yes :) I used pending cron to mean, on your next interaction, a cron will be triggered before it.

On Sat, Jan 30, 2016, 11:50 Alys notifications@github.com wrote:

@KristianTashkov https://github.com/KristianTashkov Can you give some details about what you mean by "you have no pending cron to be ran on your next interaction"? Does that mean if the buff is cast before your Custom Day Start time?

— Reply to this email directly or view it on GitHub https://github.com/HabitRPG/habitrpg/issues/2523#issuecomment-177133969.

[Alys]

@KristianTashkov : These are just my initial thoughts. If any of it sounds negative, that doesn't mean it's a "no" vote - I'm just describing possible problems for consideration. :)

"you can cast CON on someone when they are away and still work for their next cron." -- So that would apply only if you cast it before their CDS time? If you knew that a player was going to be damaged by their Dailies on their next cron, you couldn't help to protect them if their CDS had already passed?

"we also store a timestamp for each buff modification, and only apply buffs that are after his last scheduled cron time and drop the others." -- We'd have to go with this route, rather than the the lazy route, because otherwise a player who didn't log in for days could have a huge buff, which would unbalance the game for them until their next cron (we'd definitely get complaints if that happened, especially from new, low-level players). This would affect how the "Pending buffs" feature worked -- ideally we'd want to display only the buffs that wouldn't be dropped.

We'd want to put some thought into load issues. Currently, when a buff is cast, it's applied equally to all party members, with little calculation being done, whereas for this change, we'd need to read the CDS and timezone and lastCron date for each party member to determine how the buff would be applied, and do that every time a buff was cast. That could add some serious load and I'm not sure the site could handle it. We could cache that data for a period to reduce load, but that could result in inaccurate buff behaviour occasionally (probably very rare though).

I believe we'd want to wait until after APIv3 was released before adding this code.

[KristianTashkov]

@Alys

So that would apply only if you cast it before their CDS time? If you knew that a player was going to be damaged by their Dailies on their next cron, you couldn't help to protect them if their CDS had already passed?

From my understanding the fact that cron is ran when the user is logged in is because of optimization reasons. In a perfect world you will get the cron the second your CDS comes. Looking it from that point, the ability to save someone from damage even though their cron should have ran by now is gaming the system. I can see why it could be useful, but my personal opinion is that is an unintended feature of the design and not a feature. If the team disagrees I can try to think of something else, but it seems like a solution will require a lot of special casing to cover all these cases where once you want the buff before cron calculations, and once you want it after for the next day.

We'd have to go with this route, rather than the the lazy route, because otherwise a player who didn't log in for days could have a huge buff, which would unbalance the game for them until their next cron (we'd definitely get complaints if that happened, especially from new, low-level players). This would affect how the "Pending buffs" feature worked -- ideally we'd want to display only the buffs that wouldn't be dropped.

I agree, I like the harder route better. Also whenever someone requests a user's stats (opens his profile, the user interacts with the website) we can go through the pending buffs list and remove the expired ones and then return the correct value.

We'd want to put some thought into load issues. Currently, when a buff is cast, it's applied equally to all party members, with little calculation being done, whereas for this change, we'd need to read the CDS and timezone and lastCron date for each party member to determine how the buff would be applied, and do that every time a buff was cast. That could add some serious load and I'm not sure the site could handle it. We could cache that data for a period to reduce load, but that could result in inaccurate buff behaviour occasionally (probably very rare though).

I'm not sure I think the load is gonna be significantly bigger. All the values you mentioned can be calculated once and saved on the user as a single timestamp, so buffs after that timestamp should be added to pending. It's basically a single if branch to check if you should put it in buffs or pendingBuffs. I could be missing something, but parsing the pending buffs list will probably be a bigger CPU problem than buffing,

I believe we'd want to wait until after APIv3 was released before adding this code.

I think most of this code will be in common and will have nothing to do with API v2 or v3. Am I missing something?

Thanks for taking the time to answer :)

[Alys]

From my understanding the fact that cron is ran when the user is logged in is because of optimization reasons. In a perfect world you will get the cron the second your CDS comes.

I can see how it might look like that, but it is intentional that cron runs only when the user interacts with Habitica, and future changes to the site will increase reliance on that.

the ability to save someone from damage even though their cron should have ran by now is gaming the system. I can see why it could be useful, but my personal opinion is that is an unintended feature of the design and not a feature.

But see Lemoness's comment above, "... the ability to save players before they log in, which I think is a great feature." ;) Admittedly she was talking about healing, but buffing CON is similar. Also if a user had asked a Healer for a CON buff but the Healer didn't see the message until the user had gone to bed, it would be good if the CON buff could still be applied in time.

a solution will require a lot of special casing to cover all these cases where once you want the buff before cron calculations, and once you want it after for the next day.

Agreed, although I'm wondering if we could do both. Every time a buff was cast, it would always be applied to the user's stats immediately AND if it were cast between the user's last use of the site and cron it would also be re-applied after cron. It would mean that CON buffs would sometimes have a double effect compared to other buffs, but I don't think that's really a bad thing. I can go into more detail about the advantages I see to this, if desired (some of it's already in my comment from Oct 31, 2015).

whenever someone requests a user's stats (opens his profile, the user interacts with the website) we can go through the pending buffs list and remove the expired ones and then return the correct value.

That's a good idea. For the case where another player requests the user's stats, we might not want to save the changes back to the database because that would change the current read-only process to a read-write in some cases (extra load) but it could use the same calculation code.

I'm not sure I think the load is gonna be significantly bigger. All the values you mentioned can be calculated once and saved on the user as a single timestamp...

Yes, but it's not the calculation I'm concerned about, it's the extra database actions. At the moment, when a buff is cast, we don't read anything from the party members' accounts, we just write to them. This change would require reading as well. Admittedly reading is less intensive than writing but it's still extra load, and the site is already pretty heavily loaded.

I think most of this code will be in common and will have nothing to do with API v2 or v3.

It's not so much the code I'm concerned about, it's the site load and the temporary change in development focus. A lot of our current code is inefficient but that will improve with v3, so load from other sources will hopefully decrease, meaning that extra load from buffs might be less of a problem. Also changes to how buffs work will require code reviews, testing... effort from our senior devs, which will take time away from developing v3 (and the sooner v3 is released, the better, since it will improve many thing and open up opportunities for further improvements). We do want to do something about buffs but I think it's not urgent enough that the code should be changed before v3. However I definitely want us to continue discussing your idea - I think it has promise, and Lemoness has already expressed some approval for this approach in her comment above about Blade's idea.

[KristianTashkov]

But see Lemoness's comment above, "... the ability to save players before they log in, which I think is a great feature." ;) Admittedly she was talking about healing, but buffing CON is similar. Also if a user had asked a Healer for a CON buff but the Healer didn't see the message until the user had gone to bed, it would be good if the CON buff could still be applied in time.

This still applies if you manage to buff him before his CDS, otherwise you were too late :stuck_out_tongue: . I'm going from experience in my party, but buffing is mostly a problem in the morning where you have to wait for everyone before you buff. The proposed fix deals with this issue and you won't have to wait when you log in first in the morning. Personally I don't like the solution where you get 2 CON buffs, just because we can't figure out a better solution where everyone is happy. That's why I opted for doing it by timestamp. If you managed to save him in time, good for you! All buffs are applied to the current day of the buffed user (regarding his CDS).

Yes, but it's not the calculation I'm concerned about, it's the extra database actions. At the moment, when a buff is cast, we don't read anything from the party members' accounts, we just write to them. This change would require reading as well. Admittedly reading is less intensive than writing but it's still extra load, and the site is already pretty heavily loaded.

What do you mean we are not reading anything? We read a lot of stuff..

As for waiting for API-v3: From a user who has contributed a bit to api-v3 tasks in the past weeks and who has gone bored of it, I would really prefer writing this for a week (and testing it) before I write more api-v3 tasks. Me writing this will only slow down the core team with a review they can do to rest from coding :stuck_out_tongue:. And if I manage to merge that and make my group happy, I will rejoin writing api-v3 with renewed powers, while now I'm burned out from porting and writing tests.

I understand your points for API-v3 in general and if you guys want to wait, I'll wait. I just really want to fix this since it annoys me every morning :stuck_out_tongue:

[Alys]

This still applies if you manage to buff him before his CDS, otherwise you were too late

That might be more of an inconvenience for some parties than others. For some timezone pairings, one player's work day hours could cover the entire period between CDS and cron for another player. I'm not saying that special handling for CON buffs is essential, just that it's worth discussing to see if we can come up with the best solution for a wide variety of cases.

What do you mean we are not reading anything? We read a lot of stuff..

Ah, you're right, of course, the extra data could easily be added there. No significant extra load. :)

I'm thinking that this might not be a small change that would be quick to review, but if the senior devs are happy to look at it, that's fine.

[KristianTashkov]

Yeah I really haven't given parties with very different timezones that much thought. I will try to think what's the best way to handle it.

Random idea that popped in my head (not that fleshed out), that may or may not be related to this issue. What if we have a button that says "Okay I'm done for today", which triggers your cron? I guess we can enable it 6/12 hours before your CDS or something like that for easy protection against multiple crons in a single day (if you keep editing your CDS you can do a cron every hour now right?). If you don't press it it will trigger with the same logic as before. If the whole party uses it then you can buff whenever you want and you will know this is a valid day for them.

Probably some problems will arise from this that will need a solution thought out, but I'm really liking it now. Thoughts?

[crookedneighbor]

You're free to work on whatever you want, but no changes to cron in v2 will be reviewed and merged right now. Cron is one of the most essential pieces of the site and requires particular care that nothing breaks.

[Alys]

@KristianTashkov Here's why I believe it's worth doing special handling for CON buffs:

CON doesn't suffer from this issue as much as the other attributes do because CON buffs applied after CDS can still protect you from your own Dailies. If we changed all buffs so that those cast after CDS don't take effect until after cron, then CON buffs actually become weaker for those players who suffer from Dailies more than Habits. Healers are already seen as a weak class by many and so anything that further weakens them is undesirable. In fact, if CON had a special ability to be applied between CDS and cron as well as after cron, it would make Healers stronger than other classes in that respect, which I think would be good.

In the future, it's possible that we'll be giving Healers the ability to protect you from boss damage (there's been talk about that elsewhere) and then it will become even more important that a Healer casting a skill after your CDS can still protect you on your next cron.

Of course the code wouldn't need special handling for CON buffs. It could allow all buffs cast after CDS to take effect both immediately and after cron, and the non-CON buffs would just naturally have no effect before cron.

[Alys]

After discussion with Lemoness, I'm closing this. It's more of a feature request than a bug report, and while we might want this done in future, it's not ready to be worked on at the moment. It can be reopened when appropriate.