RECYCLE primitive returns pennies

[dbenoy]

Perhaps the penny-return logic should be in the @recycle command instead of in the recycle function itself, because that also affects the MUF primitive, creating an unexpected donation of pennies if you use a program that recycles objects.

[tanabi]

I haven't seen the code for MUF's recycle prim yet but I'd bet pennies that it uses a separate codebase from @ recycle :)

I'm not sure I agree with this, because this is altering very long-standing behavior (I think ... we should double check on an FB5 / FB6 series MUCK to be sure). It is, arguably, "expected behavior" and doing this change could theoretically break existing custom @ recycle programs. Well, not break, but change their behavior in an unintended fashion.

However, we could provide a MUF primitive that doesn't give pennies or make it a pragma sort of feature.

[dbenoy]

Yes that is a good point about perhaps tackling it with a prgama or a separate prim.

I actually looked myself. do_recycle in create.c and the primitive both call the recycle function in move.c and that function handles the business of returning the pennies.

It should probably be moved out of there and into a different function, like refund_object or something, and then called from do_recycle, and optionally from the primitive as well to maintain compatibility.

[wyld-sw]

My first instinct is to use $pragma. If you two agree, we could move pragmas inside the program object (as opposed to a frame variable as in comment handling), and add a $pragma recycle_refund or somesuch. Then in prim_recycle, do something like:

if (pragma_defined(program, 'recycle_refund')) refund_object(thing);

Would that do it?

[tanabi]

This sounds like a good way to do it to me. Make sure we update 'man recycle' to note the pragma feature :)

[dbenoy]

I'm looking through the recycle routine and it has some more logic in there that's news to me. Like for example, it will recursively remove exits, and I think it sends players and other things to their homes.

In my opinion, these things might come as a surprise to somebody writing MUF, as well. Maybe instead of a pragma, we should have a separate prim called 'destroy' that does nothing except remove an object from the database and clean up any references to it, and if it encounters any objects inside it, it'll just throw an error, and it won't mess with pennies, or do anything else.

[tanabi]

@dbenoy these things are what you might call a "safety concern". The exits and removal of things are mostly because something can't exist "nowhere" in the DB.

I'm not opposed to a DESTROY prim, though I don't see a use case where I would prefer that over RECYCLE. 99% of the time, if I'm calling RECYCLE, it's either because I'm writing something for a quota program and the default behavior is fine, or I'm recycling "things" and the default behavior is fine.

To me, the pragma still makes sense, though if you desire a DESTROY prim (which is kind of an ironic name for an arguably "gentler" recycle) then I'd say make a separate GIT issue for it and one of us can make it.

[dbenoy]

My thought was that if you are making programs that create and remove objects and rooms and such, it should default not be deleting more than you explicitly request and you should be expected to ensure the object is empty, etc, yourself.

Another use case besides quota libraries is for ephemeral rooms that exist to take users on a little tour or for players to tuck themselves into for some brief RP. In those cases accidentally removing or moving objects can potentially be bad and you may wish it just threw an error instead so you could catch the problem in development.