fuzzball-muck
Penny generation with object/link creation primitives
NEWOBJECT creates objects with a value of 1, rather than 0.
You can just create an object, and then recycle it to collect a penny.
This already can be exploited on numerous MUCKs, including my own, which have ways for ordinary users or low-level MUCKER bit users to create objects that they own from MUF code.
They could repeatedly create and recycle the object and endow themselves with as many pennies as they want.
Yeah, newobject (and probably newroom, etc.) doesn't deduct pennies to create but will set a value. Most quota libraries that I've seen will deduct pennies and then set the penny value on the object according to the exorbitently complex way 'help @ create' describes (though I think @wyld-sw and I simplified that logic a good bit recently). It would probably be a good idea to have these all calls not set an intrinsic value ... while that differs from how the commands work, the man pages don't hint that a value is being set and I think most programmers are not aware of this.
Sadly there's no workaround for this either. Trying to eliminate the object's value with ADDPENNIES (in addition to requiring a wizbit on your script) gives you an error if you try to reduce the value below 1.
So no matter what, if a MUF program is creating an object for whatever reason, it's adding surprise pennies to your economy that most MUCK admins are probably not aware of, and may be confused about where they're coming from.
This is another really easy one. Would you like to take a shot or you want @wyld-sw or myself to do it? Trying to cultivate new FB contributors ya see, though I'm happy to do it if you're not comfortable.
@dbenoy awesome! Feel free to ping me if you have any questions, I am happy to help.
Reposting this here. As mentioned in #461, Unfortunately, yes, newexit, newroom, setlink, and setlink_array do still have the same problem.
But unlike thing objects, they don't store their penny value on an object-by-object basis in the database :( So there really is no straightforward way to prevent @recycle from giving you free pennies for them, in the same way as for thing objects.
Not sure what can be done about it.
Yeah, I tend to forget that rooms and exits are special snowflakes. I still think we should be able to make a code-path through so that MUF doesn't deduct pennies for those things, though its certainly a higher level of effort.
NEWROOM and NEWEXIT seem to require M3. There are a lot of shenanigans you can do with an M3, so maybe this isn't as big of a deal as it was with thing objects (which only requires M3 if you want to override certain limits/permissions).
Since if you have M3, you're already in a position to do damage, then this lazy solution may be sufficient--put a note in the man pages for those primitives that says:
Remember that recycling [rooms/exits] will refund pennies to users, so if you use these primitives to create [rooms/exits] for regular users, you should charge them an amount of pennies matching your MUCK's [room_cost/exit_cost] value. (see SYSPARM) Otherwise they may be able to recycle the resulting [room/exit] to generate pennies.
As for creating links... I'm trying to sort out whether that requires M3 as well in all cases, but the logic is a bit more complicated. (Edit: Looks like it does not require M3)