Page 1 of 1
minable.result(s) with difficulties
Posted: Thu Feb 20, 2020 11:52 pm
by lovely_santa
Not sure how though it is to implement, but here is the idea:
We have a recipe to create an item, then we can place that entity, once we mine the entity, we get some product(s) back.
Now, when the products that return when you mine the entity, depends on the recipe, there is not realy a way to reflect this.
The recipe supports normal and expensive ingredients/results. My request is for the entity as well: minable.normal.result(s) and minable.expensive.result(s), similarly like the recipes operate.
Kind regards
lovely_santa
Re: minable.result(s) with difficulties
Posted: Fri Feb 21, 2020 8:19 am
by darkfrei
+1
I have the same problem and idea of possible solution while modding of
Recycling Deconstruction.
Right now the solutions are:
1. Ignore expensive recipes
2. Exclude recipes with normal/expensive.
Re: minable.result(s) with difficulties
Posted: Fri Feb 21, 2020 8:29 am
by Deadlock989
darkfrei wrote: ↑Fri Feb 21, 2020 8:19 am
1. Ignore expensive recipes
This. The system is a nightmare. It's really awkwardly specified, causing horrible confusion and complication in code, and the feature adds very little to the game in my view. I would rather not have to deal with this all over again in another property.
-1.
What's to stop you manipulating the returned results with on_player_mined_entity? It's a pain to get to the recipe from the entity, but not impossible. Probably about equal to the pain of everyone having to refactor their code if they also take broad actions on minable.results.
Re: minable.result(s) with difficulties
Posted: Fri Feb 21, 2020 5:11 pm
by lovely_santa
darkfrei wrote: ↑Fri Feb 21, 2020 8:19 am
+1
I have the same problem and idea of possible solution while modding of
Recycling Deconstruction.
Right now the solutions are:
1. Ignore expensive recipes
2. Exclude recipes with normal/expensive.
Yeah that's indeed not a good solution.. (-1 on that one)
The only real work around I found is having 2 entities and 2 items for each:
- Have in normal and expensive mode a different result items
- Those items place the same building (but with a different name), one for normal, and one for expensive
- Each building has their own minable.result(s), and that way you can link it backwards to normal and expensive mode.
BUT
I want to do this in angels mods, but having to duplicate every building (entity + item), for every tier of the building, it starts to become quite a hassle and will increase the amount of prototypes by a lot (and such loading times). Hence my request.
Re: minable.result(s) with difficulties
Posted: Sat Feb 22, 2020 4:21 pm
by eradicator
Deadlock989 wrote: ↑Fri Feb 21, 2020 8:29 am
darkfrei wrote: ↑Fri Feb 21, 2020 8:19 am
1. Ignore expensive recipes
This. The system is a nightmare. It's really awkwardly specified, causing horrible confusion and complication in code, and the feature adds very little to the game in my view. I would rather not have to deal with this all over again in another property.
-1.
Agreed. -1 too.
The "grown" legacy headache that is recipe prototypes is alreaday not fully understood by most modders. So unless someone at wube decides that breaking all existing mods is suddenly ok and removes all the legacy variations - which is never gonna happen - i'm against this too.
Re: minable.result(s) with difficulties
Posted: Sat Feb 22, 2020 10:14 pm
by Rseding91
eradicator wrote: ↑Sat Feb 22, 2020 4:21 pm
Agreed. -1 too.
The "grown" legacy headache that is recipe prototypes is alreaday not fully understood by most modders. So unless someone at wube decides that breaking all existing mods is suddenly ok and removes all the legacy variations - which is never gonna happen - i'm against this too.
The thing is, they aren't "legacy", they are just "variations". Every way to define them is there for a reason and aren't going to be removed ever as far as I know.
Re: minable.result(s) with difficulties
Posted: Sun Feb 23, 2020 8:30 am
by eradicator
Rseding91 wrote: ↑Sat Feb 22, 2020 10:14 pm
eradicator wrote: ↑Sat Feb 22, 2020 4:21 pm
Agreed. -1 too.
The "grown" legacy headache that is recipe prototypes is alreaday not fully understood by most modders. So unless someone at wube decides that breaking all existing mods is suddenly ok and removes all the legacy variations - which is never gonna happen - i'm against this too.
The thing is, they aren't "legacy", they are just "variations". Every way to define them is there for a reason
The format has grown over the years to include fluids, difficulties, probabilities, etc.. And the only reason for all the "variations" as far as i can tell is "to not break old (mod-)code". Thus i call it legacy. Unless you want to explain to me the technical benefits of allowing "result/result_count" as a variation of just "results" etcpp. As at runtime those "variations" are apparently not nessecary anymore?
Rseding91 wrote: ↑Sat Feb 22, 2020 10:14 pm
aren't going to be removed ever as far as I know.
Never assumed they would.
Re: minable.result(s) with difficulties
Posted: Sun Feb 23, 2020 12:27 pm
by Rseding91
result/result_count are far simpler versions of "produce 1 item type, with this amount." Without needing to add in extra brackets, newlines, or manage indentation.
The majority of the base-game recipes use those definitions even as we add in more recipes over time because... they're far simpler to define.
They all go into the same complex definition runtime because that's just how you store them.
Re: minable.result(s) with difficulties
Posted: Sun Feb 23, 2020 4:19 pm
by eradicator
Rseding91 wrote: ↑Sun Feb 23, 2020 12:27 pm
result/result_count are far simpler versions of "produce 1 item type, with this amount." Without needing to add in extra brackets, newlines, or manage indentation.
At the cost of forcing every modder to look in 9 different places to even find the result/-count.
Re: minable.result(s) with difficulties
Posted: Sun Feb 23, 2020 6:06 pm
by eradicator
Basically it boils down to this: If you're just creating new recipes (like base mod) you don't need to care about variations. But if you ever want to read a recipe (not even speaking of changing it) you need to deal with the annoyingly large set of "all possible variation combinations". And every modder needs to reinvent the wheel for that.
Re: minable.result(s) with difficulties
Posted: Sun Feb 23, 2020 6:29 pm
by Optera
eradicator wrote: ↑Sun Feb 23, 2020 6:06 pm
Basically it boils down to this: If you're just creating new recipes (like base mod) you don't need to care about variations. But if you ever want to read a recipe (not even speaking of changing it) you need to deal with the annoyingly large set of "all possible variation combinations". And every modder needs to reinvent the wheel for that.
That's the problem.
Recipes won't change, so we need an easy to use recipe reader and writer, preferably in core or base.
Re: minable.result(s) with difficulties
Posted: Sun Feb 23, 2020 9:24 pm
by Rseding91
eradicator wrote: ↑Sun Feb 23, 2020 4:19 pm
Rseding91 wrote: ↑Sun Feb 23, 2020 12:27 pm
result/result_count are far simpler versions of "produce 1 item type, with this amount." Without needing to add in extra brackets, newlines, or manage indentation.
At the cost of forcing every modder to look in 9 different places to even find the result/-count.
Yes, but mostly I don't care about that. The places to look are fixed and known. The game parses them without issue and mods can to if they want to do that.
Mod developers that want to change these values are the minority and so the 'ease of use' goes to the majority.
Re: minable.result(s) with difficulties
Posted: Sun Feb 23, 2020 10:14 pm
by lovely_santa
Rseding91 wrote: ↑Sun Feb 23, 2020 9:24 pm
Mod developers that want to change these values are the minority and so the 'ease of use' goes to the majority.
I agree that it is known and not that though to figure out... And now more on topic: How about my request?
lovely_santa wrote: ↑Thu Feb 20, 2020 11:52 pm
My request is for the entity as well: minable.normal.result(s) and minable.expensive.result(s), similarly like the recipes operate.
lovely_santa wrote: ↑Fri Feb 21, 2020 5:11 pm
The only real work around I found is having 2 entities and 2 items for each:
- Have in normal and expensive mode a different result items
- Those items place the same building (looks the same, same functionality, but with a different name), one for normal, and one for expensive
- Each building has their own minable.result(s), due o the different buildings in normal/expensive, it links itself backwards to normal and expensive mode, to obtain different minable.result(s) in each mode
BUT
I want to do this in angels mods, but having to duplicate every building (entity + item), for every tier of the building, it starts to become quite a hassle and will increase the amount of prototypes by a lot (and such loading times). Hence my request.
Re: minable.result(s) with difficulties
Posted: Sun Feb 23, 2020 10:36 pm
by Deadlock989
I don't understand why you even want this. Why do you need a different item that is functionally identical to the other item back from mining an assembler because the recipe that made it was a different difficulty level?
Re: minable.result(s) with difficulties
Posted: Mon Feb 24, 2020 6:20 am
by darkfrei
Deadlock989 wrote: ↑Sun Feb 23, 2020 10:36 pm
I don't understand why you even want this. Why do you need a different item that is functionally identical to the other item back from mining an assembler because the recipe that made it was a different difficulty level?
While you get no entity item, but ingredients for this entity.
Re: minable.result(s) with difficulties
Posted: Mon Feb 24, 2020 10:17 am
by Deadlock989
darkfrei wrote: ↑Mon Feb 24, 2020 6:20 am
Deadlock989 wrote: ↑Sun Feb 23, 2020 10:36 pm
I don't understand why you even want this. Why do you need a different item that is functionally identical to the other item back from mining an assembler because the recipe that made it was a different difficulty level?
While you get no entity item, but ingredients for this entity.
I was asking santa, but in your case, like I said, you can script that. It's a fringe case that changes base gameplay assumptions so you can handle it with entity mined events, it's not a good enough reason to force a load of extra work on everyone else.
In santa's case, from what he's said, his case is handing out items with different names from different recipe difficulties, said items building two identical identies with the same properties but a different name. I mean, what.
I mean, we're already doing ugly crap like this just to parse through ingredients and results in recipes:
Code: Select all
local root = recipe.normal and {recipe.normal,recipe.expensive} or {recipe}
for _,r in pairs(root) do
if r then ..
I don't want that to be a thing for anything else. I don't even want it to be a thing for recipes.
Re: minable.result(s) with difficulties
Posted: Mon Feb 24, 2020 10:39 am
by Rseding91
Unless the base game ends up wanting to do this (not likely) I don't see this ever happening.
The normal vs expensive recipe system is meant to alter the ingredients not the result(s).
If you want different results, you're meant to use different recipes and just enable/disable them on_init or with a mod setting.
To put it simply: what you're trying to do is outside the base-game built in logic system.