minable.result(s) with difficulties

[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

[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.

[Deadlock989]

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.

[lovely_santa]

+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.

[eradicator]

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.

[Rseding91]

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.

[eradicator]

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?

aren't going to be removed ever as far as I know.

Never assumed they would.

[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.

[eradicator]

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.

[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.

[Optera]

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.

[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.

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.

[lovely_santa]

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?

My request is for the entity as well: minable.normal.result(s) and minable.expensive.result(s), similarly like the recipes operate.

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.

[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?

[darkfrei]

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.

[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?

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.

[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.