Closed nixnoxus closed 3 years ago
I think that the HV digiline cable is not much more powerful than 2 separate cables
Digimese recipe was more about balance when digistuff is used as digicable allows more functionality while being cheaper even with just 8 digilines, I did not however look much into it when digistuff is not available. However item costs are not actually balanced much within digistuff mod either and less so when many mods from different developers are mixed together, this is not something that can be fixed within single mod anyway.
Include a configuration option like 'enable_new_digiline_cable_recipes' (default: no) to switch between "old" and "new" recipes
Configuration could be it but please do not use words like "new" in configuration, it will be old later and usually naming like that will cause just confusion in future.
However I think that either server customization mod or fully configurable recipe should really be used for recipe overrides.
I've not actually seen fully configurable recipes so far in any mod and it might not be good idea, however it is fairly simple to implement for example by adding config option technic_digiline_cable_recipe = digilines:wire_std_00000000, technic:hv_cable, digilines:wire_std_00000000
and converting that to table using standard pattern matching function.
Example code that should work:
local m = technic.config:get("digiline_cable_recipe"):gmatch("([^%s,]+)[%s,]*")
recipe = {{m(),m(),m()},{m(),m(),m()},{m(),m(),m()}}
maybe 'alloy' instead of 'craft'?
I'd like idea of alloying, it would be a lot more interesting recipe in my opinion.
Btw, again mineunit test are not actually failing but posting coverage status comment failed again. Should probably do something about that...
If my comment was too unclear (like I think they might often be):
technic.config:get_recipe("technic:hv_digi_cable")
, actual code for parsing should not be added anywhere near recipe registrations.thank you for your feedback. I add now the option to overwrite all 'technic:' craft recipes in the configuration.
.. maybe it would be a better idea to outsource the overwriting of recipes in a separate mod 🤔
.. maybe it would be a better idea to outsource the overwriting of recipes in a separate mod 🤔
Also I should have mentioned that while it would possibly allow way more flexible and simpler recipe collection it will also be most complicated way to actually do it well enough...
Server specific customization mod would be simplest solution as that allows overriding recipes without changing anything in mods where recipes are originally defined.
Adding functionality to manage configurable recipes in technic mod would be good but would not anymore be about changing cable recipes, it would be about introducing new better way to manage recipes for everything in technic mod. Basically that mean rewriting all recipe definitions within technic mod.
Because of that I would only recommend going there if: 1. you're willing to put extended amounts of time into it. 2. you're willing to test it very well. 3. it will reduce lines of code and possibly even lua files in technic mod instead of increasing those.
If looking for simple and fast throw-in-solution then I would recommend either server specific customization mod or going through no-config recipe change option.
My code already allows you to configure all craft recipes in technic mod. According to the following scheme:
<OUTPUT-ITEM>_recipe = <ITEM>[,ITEM]..
In order to support other types of recipes as well, the configuration could be done as follows (TODO):
alloy_<QUANTITY>_<OUTPUT-ITEM> = <INPUT-ITEM1>[,INPUT-ITEM2]
craft_<QUANTITY>_<OUTPUT-ITEM> = <INPUT-ITEM1>[,INPUT-ITEM2]..
compressing_<QUANTITY>_<INPUT-ITEM> = <OUTPUT-ITEM1>[,OUTPUT-ITEM2]..
cooking_<QUANTITY>_<INPUT-ITEM> = <OUTPUT-ITEM1>[,OUTPUT-ITEM2]..
extracting_<QUANTITY>_<INPUT-ITEM> = <OUTPUT-ITEM1>[,OUTPUT-ITEM2]..
freezing_<QUANTITY>_<INPUT-ITEM> = <OUTPUT-ITEM1>[,OUTPUT-ITEM2]..
grinding_<QUANTITY>_<INPUT-ITEM> = <OUTPUT-ITEM1>[,OUTPUT-ITEM2]..
separating_<QUANTITY>_<INPUT-ITEM> = <OUTPUT-ITEM1>[,OUTPUT-ITEM2]..
using the example of cables it could look like this:
alloy_1_hv_digi_cable = technic:hv_cable, digilines:wire_std_00000000, digilines:wire_std_00000000
craft_1_hv_digi_cable = digilines:wire_std_00000000, technic:hv_cable, digilines:wire_std_00000000
The existing code for recipes does not have to be touched for this.
Originally i had another suggestion: add alloy reciepes as an alternative. For example:
--- a/technic/machines/register/alloy_recipes.lua
+++ b/technic/machines/register/alloy_recipes.lua
@@ -31,6 +31,12 @@ local recipes = {
{"technic:raw_latex 4", "technic:coal_dust 2", "technic:rubber 6", 2},
{"default:ice", "bucket:bucket_empty", "bucket:bucket_water", 1 },
{"default:obsidian", "bucket:bucket_empty", "bucket:bucket_lava", 1 },
+ {"technic:lv_digi_cable", "technic:lv_cable", "digilines:wire_std_00000000 2" },
+ {"technic:lv_digi_cable_plate_1", "technic:lv_cable_plate_1" "digilines:wire_std_00000000 2" },
+ {"technic:mv_digi_cable", "technic:mv_cable", "digilines:wire_std_00000000 2" },
+ {"technic:mv_digi_cable_plate_1", "technic:mv_cable_plate_1" "digilines:wire_std_00000000 2" },
+ {"technic:hv_digi_cable", "technic:hv_cable", "digilines:wire_std_00000000 2" },
+ {"technic:hv_digi_cable_plate_1", "technic:hv_cable_plate_1", "digilines:wire_std_00000000 2" },
}
if minetest.get_modpath("ethereal") then
Would that be a better solution?
My code already allows you to configure all craft recipes in technic mod.
Code in this pull request allows overriding recipes instead of configuring recipe registrations. Configuration itself looks good but under the hood it overrides recipes and because of that goes through alternate path which unnecessarily increases amount of code and increases cases that needs to be tested (and taken into account when doing other changes).
In order to support other types of recipes as well, the configuration could be done as follows (TODO):
That looks good.
The existing code for recipes does not have to be touched for this.
Doing it without touching existing code for recipes will complicate system a lot, make testing way harder and introduces many possible invisible corner case problems and increases amount of code and possible execution paths unnecessarily. It also makes using recipes internally unreliable during initialization. Exact reason why I mentioned that it will be most complicated way to do it well (not through dirty hacks on top of existing code).
Originally i had another suggestion: add alloy reciepes as an alternative. For example:
Recipes that are added or changed without configuration options will be simple change in terms of updated lines of code.
I like this now, adding slow but cheaper alloying recipes 👍
@S-S-X ping :wink: any objections with the last state?
@S-S-X ping 😉 any objections with the last state?
Compared to digimese recipe it will be significantly cheaper when digistuff is enabled, I've been thinking if recipe should be bit closer to original when digistuff mod is available possibly dropping just mese block from recipe or some wires too.
I think alloying is very good idea and can have a lot cheaper recipe but dropping it from 1 mese and 8 wires to 0 mese 2 wires when digistuff is available might be too big difference between alloying and crafting recipe. When digistuff is not available it is just from 8 wires to 2 wires.
I could still see few possible changes:
Note: bronze alloying time (cycle time) is 2x default and silicon_wafer uses default. edit. I think removal of crafting recipes would be more important change while increasing alloying time would be more about good to require larger factory for producing luxury stuff (which digi cables basically is, required only for some nuclear functionality).
Compared to digimese recipe it will be significantly cheaper when digistuff is enabled, I've been thinking if recipe should be bit closer to original when digistuff mod is available possibly dropping just mese block from recipe or some wires too.
I think alloying is very good idea and can have a lot cheaper recipe but dropping it from 1 mese and 8 wires to 0 mese 2 wires when digistuff is available might be too big difference between alloying and crafting recipe. When digistuff is not available it is just from 8 wires to 2 wires.
i think the digistuff recipe is way too expensive. i don't see any added value except the space saving (compared to digi wire and technic cable side by side)
I could still see few possible changes:
- Possibly longer alloying time than default 6 (possibly 2x - 4x?) requiring either large factory or a lot more time to manufacture cables.
- Possibly removal of normal crafting recipes in favor of alloying making digi cables available only through alloying.
Note: bronze alloying time (cycle time) is 2x default and silicon_wafer uses default.
i would prefer option 2 (remove normal crafting recipes). i think merging digi wire with technic cable should not take longer. it is a comparatively simple and not so energy consuming process.
edit. I think removal of crafting recipes would be more important change while increasing alloying time would be more about good to require larger factory for producing luxury stuff (which digi cables basically is, required only for some nuclear functionality).
i see much more use cases. examples:
are there any other opinions? ;)
Previous comment as TLDR, changes I'd still request for this:
Any comments on complete crafting recipe removal? It changes a way how things are done, in my opinion to better direction for technic mod.
Only thing I have against removing current crafting recipes is that crafting is a bit more realistic than alloying... I mean, you wouldn't melt a cable with wire to combine them, you would join them together.
Only thing I have against removing current crafting recipes is that crafting is a bit more realistic than alloying... I mean, you wouldn't melt a cable with wire to combine them, you would join them together.
I see this bit differently as you actually would melt a cable with wire and insulation, that's how it can be made in real life and depending on product requirements it is often done that way. Power cables combined with signal cables like that probably is not exactly most common thing in real life but there's some examples and most I've seen have multiple insulation layers and common insulation. Extra shielding could be added for realism but that would probably get too complicated...
True that actual alloying is not what you do and you would not use actual alloy furnaces to make cables but high temperatures are still needed and I think alloy furnace is closest what technic currently has, compressor could be other option but it cannot handle multiple inputs.
Hmm... It does make more sense when you think of it like that, I was thinking more like combining two already manufactured wires together.
Hmm... It does make more sense when you think of it like that, I was thinking more like combining two already manufactured wires together.
I aggree. New suggestion:
Hmm... It does make more sense when you think of it like that, I was thinking more like combining two already manufactured wires together.
I aggree. New suggestion:
- remove alloy recipe
- change crafting recipe: technic:hv_cable + mesecons_materials:glue + digilines:wire_std_00000000 > technic:hv_digi_cable
Recipe materials sounds very good, for simple crafting this however would still go a bit against why digimese was originally selected for crafting if digistuff is available: relative cost of end product that provides all same functionality and more. (see original PR for basic math).
Then for alloy recipe why I'd keep it instead of crafting: it utilizes technic machines adding another use case for actual machines.
Actually for a moment I had idea about reviving LV machinery through this by requiring low power LV alloying to make cables, this idea while it would bring LV machines back to life it also has problems as for automation LV would then still need pipeworks support and preferably also CLU upgrade support.
Recipe materials sounds very good, for simple crafting this however would still go a bit against why digimese was originally selected for crafting if digistuff is available: relative cost of end product that provides all same functionality and more. (see original PR for basic math).
I read https://github.com/mt-mods/technic/issues/14#issuecomment-619727118
.. maybe the digistuff:digimese
is also too expensive :thinking:
"digimese (connects in all directions)"
nothing more? digistuff:vertical_bottom
does it too. Cost: 3x digistuff:vertical_bottom
= 3x digilines:wire_std_00000000
sorry, digistuff:vertical_bottom
connects only in 5 directions. digistuff:digimese
connects one more (and is much more expensive).
sorry,
digistuff:vertical_bottom
connects only in 5 directions.digistuff:digimese
connects one more (and is much more expensive).
Yes, also regular digiline wire connects to 12 directions.
I'll add here basic reason why I originally selected digimese for crafting even while I did like digiline wire recipe a lot more:
sorry,
digistuff:vertical_bottom
connects only in 5 directions.digistuff:digimese
connects one more (and is much more expensive).Yes, also regular digiline wire connects to 12 directions.
I am a little confused. Does digimese offer more directions than digiline wire? I assumed a maximum of 6 directions.
I'll add here basic reason why I originally selected digimese for crafting even while I did like digiline wire recipe a lot more:
- Digimese provides different connection and digi cable provides what digimese provides + technic network connection.
- Digiline cables provide exact same connectivity that digimese provides.
- Similar digiline conductivity what digimese provides would have been a lot cheaper if recipe would have skipped digimese.
your focus is on the target product, my focus is on the starting materials ...
Where is the added value of digimese compared to digiline? I am trying to understand why you always refer to digimese block instead of digiline wire:)
I am a little confused. Does digimese offer more directions than digiline wire? I assumed a maximum of 6 directions.
No, wire allows 12 and digimese allows 6 directions. My point is that cost is not based on how many connection you can make. Cost is based on what functionality is provided and attempt to keep cost similar when functionality is very similar.
your focus is on the target product, my focus is on the starting materials ...
My focus is on what actual functionality player will get for materials he uses.
Where is the added value of digimese compared to digiline?
Different connections than wires but that gets bit offtopic here, this is not about value of some other stuff but about balanced cost for crafting items that provide very similar functionality.
I am trying to understand why you always refer to digimese block instead of digiline wire:)
Because I've been talking about alternate digi cable recipes that use digimese when digistuff mod is enabled instead of digiline wires when digistuff mod is not available. I already noted on first comment that "I did not however look much into it when digistuff is not available.".
For additional clarification on my responses:
Alloying idea in my opinion was so good for adding more content / things to do in game that I think it should be still considered, does not have to be done here but I believe it could allow many very good future improvements and should not be ignored.
It might require some more discussion too if it seems to be controversial but for that another issue or pull request can be opened.
- Then about alloying, my opinion is pretty clear in that it would be best option to actually reduce cost also when digistuff is available: that is because it utilizes other game mechanisms, adds another use for technic machines and possibly allows more improvements that would actually add something into game unlike simple crafting.
- Change request for that was to remove regular crafting recipes to reduce code and to remove recipe variations for different mod combinations and rethink balancing by including actual additional work instead of having simple raw material based based cost.
done, i hope
- It seems however that author disagreed with that, just my impression based on next suggestion.
yes, i'm not really happy with alloying cables together
Might have to revisit alloying time, been thinking about it and now thinking that I was probably wrong about time required for production. Been a bit back and forth changes (probably a bit because of my unclear comments... sorry about that) but I think I'll merge this unless there's objections or additional requests @nixnoxus @OgelGames @BuckarooBanzay
Also heads up @nixnoxus if you want to rewrite commits (squash) yourself to allow clean merge, not needed just option to do so as commits should be squashed anyway. Also rebase is needed anyway...
For mineunit everything is just fine: 57 successes / 0 failures / 0 errors / 1 pending : 0.147632 seconds 22 successes / 0 failures / 0 errors / 0 pending : 0.156737 seconds
currently 8 meters digiline cables required for 1 meter of LV, MV or HV digiline cables. that seems illogical to me. there are only 2 cables which are glued or twisted together.
I read the discussion in https://github.com/mt-mods/technic/issues/14 about game balance in (and with) digistuff mod. However, I think that the HV digiline cable is not much more powerful than 2 separate cables (for example digiline cables next to an HV cable). it just saves space. Furthermore would be a cheaper and more realistic recipe increase the fun in survival mode.
My pull request reduces the necessary digiline cables (and plates) from 8 to 2 for a LV, MV and HV digiline cable.
To maintain compatibility, I could:
What do you think?