Reclaiming Broken Locks

[SekoETC]

There are already loads of old unusable keys lying around. Automatically turning a key into iron when the lock is broken would give people a long distance method for detecting when their lock is broken. It's unnatural and ridiculous. But I see that you already realize that.

What ProgD should do is figure out project cancellation so that you get resources back, and in the case of keys (or notes) being destroyed, the essential data should be restored when the item is rescued from the project. Currently projects for destroying items with data attached cannot be done because once you add it to a project, it's gone in an instant. Repair projects give an item back when they're finished, one might argue could you not take the code from repair finishing and attach it to the cancel button? But maybe it's not the same item that you get back, maybe it's a new item, since there was this problem with navigational device losing their coordinates when repaired. It's hard to believe how preserving an item and a link to it can be so hard.

Another thing that could be done to reduce the amount of useless keys is modifying a key into a copy of any other key the character has seen. (Not to ones they haven't seen because that might lead into people making copies of keys in places they've never been to, but what their other character has lived in / visited, and then just waltzing in to rob the place.)

[Missy]

What if you are in a different town?

If you have one key, I suppose this is a possibility. But if you have 300 keys in your inventory, I doubt you would notice. Maybe it's just me that thinks it's odd but do you really look in your inventory and say "Wow, I've got an extra ten grams of something, how did it get there and where did it come from?"

[Solfius]

I think if it has the potential for abuse, we should assume it will be abused and design any implementation so such abuse is not possible

[Tiamo]

Reclaiming useless keys has been implemented, so the only problem is knowing whether a key is obsolete.

My character has an administration of all his keys in a personal note. So, if he notices that a lock of which he owns a key has been broken he immediately knows which key it concerns. Works well and is realistic i think.
Unknown keys are worthless anyway, unless your character travels to all kinds of different places, and has the opportunity to test the keys.

Reclaiming the iron in a broken lock should, in my opinion, be done in a more generic way, like creating a recycling machine/building that accepts any kind of item. Assuming the (broken) item can be picked up or dragged, of course.
Recycling a broken lock can be accomplished by making a useless item called 'broken lock' the result of a successful lock picking project, and by making this the input to a recycling project. The same could be done with rotten/broken tools.

[SekoETC]

Whether a key is useless or not is a find out in-game issue. If someone is stupid enough to give keys to someone who'd rather destroy them than give them back then that's their loss.

[ornithopter]

What about having a new resource called "Scrap Metal" (or "Scrap Iron", if we want to recycle other metals too) rather than a broken lock item. It keeps the melting down process that people seem to like, and it makes the generalization of recycling iron easier, since they don't have to program hundreds of different broken items. (Similar to what happened with bowstrings.)

[marginoferror]

I like this idea. There are still specifics that need to be hammered out, but this proposal strikes a good balance between being a fairly general solution and not requiring a radical redesign.

[Solfius]

i think "Scrap metal" is not very useful, because if you wanted to extend it from locks to all things, each thing you wanted to break down would require a different project to turn it into scrap metal, and all would need to be manually added to the database and would further clutter the menus of the machines involved.

I think for now, a broken lock object is best.

(perhaps in the future, they could be a general process for turning objects back into resources by adding the object you want to reclaim to a project, whether that object is a broken lock or a sword)

[SekoETC]

No, don't you get it, there wouldn't be a need for a broken lock object because the scrap iron would be produced by the lock breaking project. Likewise hammering keys could produce scrap iron, and smelters could have a project for melting scrap iron that would produce regular iron. Scrap iron would be a general product of any demolishing project on an iron object and it would be the same resource for any number of broken objects, thus taking much less space in the database.

[Solfius]

No, don't you get it, there wouldn't be a need for a broken lock object because the scrap iron would be produced by the lock breaking project. Likewise hammering keys could produce scrap iron, and smelters could have a project for melting scrap iron that would produce regular iron. Scrap iron would be a general product of any demolishing project on an iron object and it would be the same resource for any number of broken objects, thus taking much less space in the database.

That wasn't really what I was getting at.

My objection is based on what would happen if we extended that approach to more objects within Cantr.

I agree, for keys and locks, breaking them into scrap iron is fine.

We can have a lock breaking project for locks.

We can have a key hammering project for keys.

Fine, until we want to break more things down, because until there is a generalised mechanism for destroying and reclaiming tools and things, we are forced to create a reclaiming project for each thing we want to destroy

(and ultimately, don't we want to have the option to destroy everything? Which would mean creating a project for every object, on every machine that you want to be able to use for demolishing/reclaiming: number of objects you want to have reclaiming option x number of machines that you can use for reclaiming = number of new projects that need adding to database)

The better way is to have destroying things coded into the objects themselves (perhaps a "dismantle" button) so that the projects are created automatically without the need to have add all these additional machine projects, such as when a burying or repair project is created.


As a stop gap, workaround measure, it does the job, but in the long term its inelegant and will cause considerable program bloat