Alternative Paycheck-Dispensing Mechanism

[CLDawes]

Hello all,

Is there a mechanism for acquiring a paycheck if you're the sort who is always connected to a PennMUSH server? If not, should there be one?

I briefly searched for any other issues and looked for any comments related to this at the paycheck-giving code (the current master's src/player.c:667), but couldn't find anything explaining the current behavior.

Currently, the mechanism for dispensing paychecks is based on the user's LAST attribute (the first 10 bytes of it, anyway). Any solution for this would likely need to use a different (possibly new) attribute. I am going to refer to this attribute as LASTPAYCHECK.

My gut says that this could be solved by adding a switch to the SCORE command (or changing its default behavior) to cause it to check LASTPAYCHECK and pay the user either their paycheck times the difference in days between LASTPAYCHECK and the current time, or a single paycheck (requiring them to use SCORE daily, preventing people from simply idling their way to riches).

I am planning on implementing something to fulfill this need for my own projects, but, in hopes of maybe having a pull request accepted, would appreciate any guidance on how this sort of change could be made in a manner consistent with PennMUSH's philosophy.

Thank you!

[talvo]

There are tickets open with regard to removing the OOC uses of pennies (queuing, etc) and leaving them purely as an IC money system (#425, #436) which are, if not directly relatded, of some relevance.

I'm not sure I like the idea of forcing people to use 'score' to get the paycheck myself, but the alternative of repeatedly checking if they've been paid today and doing so if not is equally meh. It could potentially be done with a socket flag (set on new connections where the current check is done, and then for existing connections, on de-idle, if the flag is not there, pay and add the flag) so we're not constantly date-checking in the attribute, at least, but...

[CLDawes]

I took a brief look at some of the earlier issues (I searched for 'money', so I didn't catch #436) before opening this issue, but didn't see anything that felt directly related to the paycheck mechanism.

The current mechanism is sufficient for delivering a paycheck at login, but it forces players to either create a new connection and log in temporarily or perform a LOGOUT/connect to receive one, even if they are active on a MUSH over a multitude of days.

I'm equally unsure about the particulars of how this could be resolved cleanly. I only suggested score because I don't expect that injecting code there would lead to too much overhead. The fact that the paycheck-dispensing code currently relies on the LAST attribute means that the functionality can't simply be duplicated elsewhere, since LAST has a meaning outside of paychecks and shouldn't be changed outside of new connections.

Admittedly not knowing anything about PennMUSH's socket flags, I'm not sure if they could do the trick easily, since multiple sockets can be logged into the same character. There would likely have to be a mechanism to prevent paychecks from being received twice if a solution like this were used.

Maybe a timed event could go through the currently-connected players every twenty-four hours and distribute paychecks to them if their LAST is not equal to the current date? Of course, this would still have to set something to indicate that each of those players had been paid, or else they could simply log in and have the LAST-based mechanism give them a second paycheck.

[mrsenile]

&PAYCHECK object=@wait 86400=@dolist [search(all,type,player)]=@swi [lte(money(##),v(paymax))]=1,{give ##=[v(pay)];@tr/quiet me/paycheck}
&PAY object=10
&PAYMAX object=10000

[CLDawes]

This softcode solution (nearly) works if the intent is to provide paychecks to all players regardless of their online/connected status. I believe the compound action list needs to be around the argument to the @wait command, though, rather than the argument of the @switch command, as the attribute should not be re-@triggered for every player that satisfies the lte check.

The primary reason I opened this issue is to determine whether or not the hardcoded paycheck system is working in a way that is philosophically consistent with the reason for its existence. As it works right now, people are paid for creating new connections to MUSHes. Even if they are the most active member on a MUSH, a player cannot acquire more pennies if they do not re-connect, and they have to re-connect every single day in order to not miss a paycheck. If the current system is working as intended, it is easy enough for me to write a program or script that automatically connects to every MUSH I have an account on, performs a connect/LOGOUT on all of my accounts, then finally QUITs. I would have done this already, but I don't like the idea of automatically spamming connect/disconnect messages. If the current system should work differently, then the philosophy behind it needs to be explained.

[talvo]

Apologies for the massive delay in replying again - you're right, the tickets don't directly relate to what you requested, but I was trying to point out that our intention is to get rid of the hardcoded purpose of the money system (which is to prevent massive spam/flooding of the command queue to lag the MUSH via a simple in-game DoS attack), replacing that with something totally different, and leave pennies to be used as an in-game monetary system (which there is also massive support for, through GIVE, BUY, etc, made kinda useless by the fact that a softcode typo - or deliberate loop/complex code - can wipe out your cash supply in a matter of seconds). At which point automatic hardcoded paychecks may well disappear entirely anyway, to be replaced with the softcoded method of choice for providing money.