Right now recipes are stored via upgrade paths (just items) tagged to an item. The ingredients always use the repair material and unit cost associated with the result itself. This data is also what's serialized to the client to reproduce recipes in EMI.
Realistically, we should probably start using something resembling an actual recipe - with a recipe serializer, per upgrade path, instead of one singular special recipe. This would enable upgrade overrides.
Secondarily, an individual recipe for each repairable item is probably also a reasonable idea - considering we can actually match against valid repair units instead of running the whole code every time (i assume match doesn't have to be perfect?)
sisby-folk
commented
9 months ago
Right now recipes are stored via upgrade paths (just items) tagged to an item. The ingredients always use the repair material and unit cost associated with the result itself. This data is also what's serialized to the client to reproduce recipes in EMI.
Realistically, we should probably start using something resembling an actual recipe - with a recipe serializer, per upgrade path, instead of one singular special recipe. This would enable upgrade overrides.
Secondarily, an individual recipe for each repairable item is probably also a reasonable idea - considering we can actually match against valid repair units instead of running the whole code every time (i assume match doesn't have to be perfect?)