|
Notes |
|
|
(0003149)
|
|
Maikel
|
|
2014-10-18 09:36
|
|
Indeed, sand could also be used to produce loam. However implementing this option in the producer library presents us with some non-trivial design decisions.
A solution would be to allow different materials, like sand and earth and let the loam give back this:
public func GetMaterialNeed() { return ["Earth", "Sand", 25]; }
And adapt the producer library accordingly, to also for example accept 10 sand and 15 earth.
However, personally I'd rather see a solution without the bucket. |
|
|
|
(0003155)
|
|
Pyrit
|
|
2014-10-18 15:08
|
|
Maybe the bucket could be a passive item. It gets filled when you have it in your inventory and dig around with the shovel...
Or have a (dry) clay material that can be mined like everything else... |
|
|
|
(0003986)
|
|
Zapper
|
|
2015-10-23 16:58
|
|
|
The bucket now indeed DOES simply collect earth objects. So maybe this can be fixed easier now? |
|
|
|
(0003987)
|
|
Sven2
|
2015-10-23 19:15
(Last edited: 2015-10-23 19:16) |
|
Generally, a cool option would be if required components could be given as properties or callback functions instead of IDs. So you could write stuff like func GetComponents() { return [["IsEarth", 1], [Water, 1]]; }
It would either require to move the component logic to script or add that as an engine feature, both of which might be a bit of work.
|
|
|
|
(0003990)
|
|
Zapper
|
|
2015-10-23 19:31
|
|
The producer logic is completely in script already. We currently allow producing stuff from e.g. water + [id] already, even though water is not a definition.
So, implementing alternatives wouldn't really be too much effort I guess? |
|
|
|
(0003991)
|
|
Sven2
|
|
2015-10-23 19:36
|
|
Moving GetComponents to script also means the engine has to use that for things like SplitComponents. Also, which message to you display when IsEarth is needed?
An alternative would be to have a callback on definitions if they can be used as a replacement for other definitions. So Sand would have
func IsAlternateComponent(id product, id component) { return component == Earth; }
That would be simpler to implement and we'd still have the primary definition for a component for things like SplitComponent, required material messages, etc. If something is really a "generic" requirement (such as "any liquid"), we can make an "any liquid" definition with proper name, symbol, etc. |
|
|
|
|
|
(Split2Components is already in script, System.ocg/Object.c) |
|
|
|
(0004000)
|
|
Zapper
|
2015-10-24 17:36
(Last edited: 2015-10-24 17:37) |
|
Why wouldn't sand just have GetAlternativeComponents() { return [Earth]; }?
Do I misunderstand how you want to use that callback?
PS: and the ideal solution would somehow streamline material requirements (water / acid) and alternative object requirements.
|
|
|
|
(0004003)
|
|
Sven2
|
2015-10-24 18:20
(Last edited: 2015-10-24 18:22) |
|
Passing the product and the component would allow very generic materials like "allow as replacement for every component that weighs less than X" or "allow as replacement to build any vehicle". I don't know if that's a scenario we want.
It's also easier to use because you can do FindObject(Find_Or(Find_ID(wanted_component), Find_Func("IsAlternateComponent", product, wanted_component))) to look for components. With your suggestion, you need to do array cross-checks for every potential component object.
Your suggestions sounds better if it were reversed (GetAlternativeComponents() { return [Sand]; } in the script of the earth object). That would be easier to use for the producer library. It just has to ask each component for alternatives and search for them, but it wouldn't allow third party packs to insert themselves as alternative objects without modifying the script of the base object.
The scenario I have in mind is the Clonk Rage Western pack. There we had alternate fur and bone objects from all kinds of animals which had to be used as alternate components. I think the solution was to ChangeDef to the main object and do SetGraphics for the custom appearance (which is a hack that has problems).
|
|
|
|
(0004004)
|
|
Zapper
|
|
2015-10-24 22:00
|
|
Ah, okay. I misunderstood you, I thought the function was supposed to be in the definition that is to be replaced (like you described).
Do you have any idea how alternative components could be communicated to the player with your proposal?
For example, the loam should ideally show all allowed components in the "material requirements" section in the production menu. If the loam (and earth) do not even KNOW all possible components, this will be a bit harder. |
|
|
|
(0004006)
|
|
Sven2
|
|
2015-10-24 23:16
|
|
I can't think of a solution that isn't unnecessarily confusing. So for the sake of simplicity, I wouldn't show it at all.
Resolution of alternate IDs from the main ID (in this case: Earth) is a problem. But if the producer needs it, it could be done in the Definition() callback of the producer library by iterating over all loaded definitions. Anyway, if we don't show the alternate IDs we also don't need to resolve them. |
|
|
|
(0004008)
|
|
Zapper
|
|
2015-10-25 07:06
|
|
I really would like to show them, though. Stuff like that is what can make the game frustrating to play.
The scenarios should be hard, because they challenge the player in some way. But not because you have to figure out first that you can build loam from sand, too.
And especially when the foundry insists that "YOU ARE MISSING EARTH!!!" it's not really intuitive that you just try out whether sand works, too. Aaand we don't have a comprehensive wiki like Terraria where you can look up everything. |
|
|
|
(0004009)
|
|
Sven2
|
|
2015-10-25 14:38
|
|
> Stuff like that is what can make the game frustrating to play.
Only if a scenario has sand but not earth. Not understanding the component message has a lot more potential to be frustrating.
Maybe it can go into the description field or into a large box when there's enough space for words (Components: Earth {{Earth}} (or Sand {{Sand}}) and Water {{Water}}}). |
|
|
|
(0004010)
|
|
Zapper
|
|
2015-10-25 15:05
|
|
>Only if a scenario has sand but not earth.
Which isn't too unrealistic :)
The required materials are currently displayed in the description box. So, yeah, that's where it would go! |
|
|
|
(0004573)
|
|
Armin
|
|
2016-01-13 07:16
|
|
I haven't read the discussion but just an idea:
We could create a sand loam object. That would be easy and has also the advantage that you can build sand walls with it. I know that item wouldn't be used so often but I don't see a problem with that, its more variety. |
|
|
|
(0004574)
|
|
Maikel
|
|
2016-01-13 07:51
|
|
|
I am against having two similar objects with the same functionality. |
|
|
|
|
|
Reminder sent to: Maikel, Zapper I uploaded a possible way to display substitions in the production menu. Any thoughts? |
|
|
|
(0005858)
|
|
Clonkonaut
|
2017-10-26 15:16
(Last edited: 2017-10-26 15:18) |
|
This is the interface, simple but enough for our usecases:
public func GetSubstituteComponent(id component) // Can be made from earth or sand
{
if (component == Earth)
return Sand;
}
You can also return an array, so the teleglove could be made from rubies, amethysts or diamonds. And yes, I know this could make the list kind of long. One just has to be careful what the production costs for an item will be. Even know you can easily make a very long list and make it look ugly.
|
|
|
|
|
|
alternative.jpg is more compact version, but less easier to read. |
|
|
|
|
|
Actually, this wasn't too hard to do. |
|
|
|
(0005867)
|
|
occ
|
|
2017-10-27 11:26
|
|
|
|
|
|
|
I took the liberty of pushing this. Removing the feature will be dead easy (remove that one function from loam, edit the description). |
|
|
|
(0005901)
|
|
Maikel
|
|
2017-11-11 08:36
|
|
|
I am happy with this change, checked that it works and see no reason to keep the bug report open. |
|
earthorsand.jpg (244,480) 2017-10-26 15:12