I use "simple" and "explicit" a lot here, so to clarify:
Code: Select all
local simple_box = {{-2, -3}, {5, 8}}
local explicit_box = {left_top = {-2, -3}, right_bottom = {5, 8}}
[quote="Bilka"]This example doesn't make much sense. Result has an entirely different format compared with results and products. Making it possible to use both formats with just one property is more confusing, not less.[/quote]
".result" has an
additional formating option available. Doesn't .results also support "simple" format? Other than that results is just a table of result('s), so a singular result would simply need additional nesting: {result} instead of result. (Also i'm really bad at examples in general :P)
Also that sort of simple/explicit dual formatting exists for a number of things and i see it as more of a general concept that is just required to be learned. (Yes, it does make cross-mod changes in data stage pretty annoying if you don't know if you're looking for .x or [1] (i.e. coordinates), so i wouldn't be against unifying those away (==enforce explicit format), but that is imho a different topic. Thinking along that line i personally would also like if normal= was the default ingredient node for recipes. I see at least one or two people a week that ask why their recipe changes don't work that stem from the fact that there's three possible positions (direct, normal, expensive) for ingredients, and even i don't know what would happen if someone specified both direct
and normal.
[quote="Bilka"]I like the idea in general, but issues might also pop up if things are formatted differently between stages.[/quote] The general behavior of the (
control stage) API is that for writing operations you can use simple or explicit format, while
reading always results in explicit format (positions, bounding boxes etc) so i don't think that any
additional confusion would come from this.
[quote="Bilka"]This will confuse users that will assume that they can use the same formate between stages, because it has the same name, right? One example of that are properties using BoundingBox. In the control phase, you can get left_top and right_bottom specifically.[/quote]
Bounding_box is already named equally between both stages with it's current behavior. So i don't see how unifying other things would cause additional confusion. It's the same simple/explicit write/read situation as above.
[quote="Bilka"]Writing to those specifically is NOT possible in the data phase, the first position in the table is assumed to be left_top, regardsless of whether you wrote right_bottom = in front of it.[/quote] Not quite following you there. An explicitly defined bounding box (i.e. {left_top = {-2, -3}, right_bottom = {5, 8}}) does not have a "first position". Thinking about this while typing... the main problem here is that
reading in data stage does not return the explicit definition. Though fixing this would be pretty ugly i presume. You'd have to check every write a mod makes to the data table and convert it to explicit if it was simple (though it would save lots of work on the modders end
if it would be fixed).
[quote="Bilka"]Do you prefer using the name of the thing in the data stage instead of the name from the control phase, the other way around, or does it depend on the property?[/quote]Personally? I prefer the
better fitting name, and if unclear the one that is easier to use or is cheaper to migrate to, though that choice should not be based on my opinion :P. I.e. A recipe is a way to
produce and item from ingredients. Thus "product" fits better, but "result/s" is shorter and more widely used so it causes less migration cost (=code writing and re-learning). Either way i don't think it matters as long as their both the same.
