How modded items are handled ?

If not actually the case, Would it be possible to dynamically handle them so they get a default color corresponding to the type of items (ex: power poles, walls ...) and maybe apply specific cases for specific modded items (transport belts ...)

Currently, I've hard-coded support for only two modded items (big wooden power pole and wooden floors). All other mod items will use whatever color the mod defines for them (or will default to that dark blue).

While I can write code which dynamically adds colors to modded items, I can NOT make it add colors which are appropriate. I can make fancy routines all day to try to guess which color to use (eg., check for keywords in the name of the item), but there's no way to make something sufficient for every case.

Another approach would be to ask other mods to include tags or something so I can know what colors to make their items, but not every mod author will care to do so, putting us back at square one.

As far as I'm aware, the best I could do would be to make a new color for each item type, eg. "mod-added transport belts are green", but that would mean that every new belt would be green on the map regardless of what color the item actually is.

In every one of those cases you'll end up with mod items with identical colors, which defeats the purpose of being able to identify things by minimap color. I'm not a veteran of Factorio's code, so there's a chance I may have missed a possibility. As always, I'm open to suggestions.

Hi Taehl, what about giving the user of your mod the chance to add items according to categories? - E.g. having a configuration file which allows to add items to a category? Thus neither you nor any mod-creator will have to take care about adding stuff... Just an idea :-)

What if the mod let you add colors with a list like this?

{ "electric-pole", "big-wooden-pole", {r=.9, g=.8, b=.7, a = part} },
{ "tile, "wood-floor", {r=.5, g=.3, b=.2, a = full} },

("part", "full", and "slight" are standardized alpha values)
I'm also considering adding support for HSL color as an alternative to RGB.

What I meant was like this: You have "categories" (like "Tiles", "PowerPoles", "Solar Panels", "Factories" etc.), which you assign a color and alpha to.
Then, you assign items to that category. Like this:

[PowerPoles]
{r=.9, g=.8, b=.7, a = part}
"big-wooden-pole" << vanilla
"big-electric-pole" << vanilla
"big-electric-pole-mk3" << mod "Factorio Extended - Power", which I can add myself

[Tiles]
{r=.5, g=.3, b=.2, a = full}
"wood-floor"
"concrete"

...etc...

Similar to this (don't know which kind of brackets is best to use...).
So all items within a category have the same settings.

And the best: you can - if you like - still come up with some settings for mods which YOU like to have in your mod by default :-)

Edit: of course "big-wooden-pole" is not vanilla :-)

The problem with that approach is that I don't have categories of items which all share the same color - every item's color is hand-picked for optimal recognition, consistency, and visibility.

Thanks for your reply.
OK, understood. Makes sense, that's fine, so - your suggestion from above, like
{ "electric-pole", "big-wooden-pole", {r=.9, g=.8, b=.7, a = part} }
is perfectly fine.
My only q about this is: if there's no categories, and I have to add a "full specification" for every item, what is the the specification "electric pole" used for? Is the item-name "big-wooden-pole" with colors and alpha not sufficient? Or - asked "from the opposite direction" - can I place there what ever I like or does it have to match the group/subgroup definition of the mod to be added?

Thanks.

In Factorio's data, all entities have a specific class and a unique name. For instance, a mod adds the entity data.raw["electric-pole"]["big-wooden-pole"]. The "electric-pole" part is defined by Factorio, the last part is named by the mod-maker. Thus, both parts need to be listed so I can change the right entity.

There's no reason you couldn't set new items to all have the same color, if so desired. I'll also let you list vanilla entities in your config so you can override my color choices.

I could do the list in a slightly different form to group them by class, but I think it would be more confusing to non-programmers:

{ ["electric-pole"] = {
"big-wooden-pole", {r=.9, g=.8, b=.7, a = part},
"some-other-pole", {r=.8, g=.7, b=.6, a = part},
},
tile = {
"wood-floor", {r=.5, g=.3, b=.2, a = full},
"lava-floor", {r=.8, g=.4, b=0, a = full},
},
}

Thanks for the explanation :-) Something learned again :-)
For me personally both options sound nice, though I'd prefer your new, recent suggestion above (looks "cleaner" to me...). But the choice of the format is in best hands to your experience/decision and of course you have to think of ALL potential users...

So any configurable option is well appreciated, if you like to add that :-)

BTW: another Q:
In your example, you have
["electric-pole"] = ...
and
tile = ...

Is the (consistent) use of [] and "", like
["tile"] =
also correct?

Those square brackets are needed to let Lua know that you have hyphenated strings (text) for a table index. Square brackets are also used to let Lua know you're talking about a numeric index (the number 14 isn't the same as the string "14"!). And don't forget Lua is case-sensitive: "MyNewThing" doesn't equal "myNewThing".

Valid:
data.tile.astroturf = "a string"
data["tile"]["astroturf"] = "works the same as above"
data["tile"].astroturf = "mixing styles is okay, just make sure there aren't hyphens"
data["power-pole"].uberpole = { [15] = "a table containing a string at numerical index 15" }

Invalid:
data.power-pole.uberpole = "needs square brackets; Lua interpreter will throw an error"
data[tile].myFloor = "missing quote marks around 'tile' - Lua will use a variable named tile instead of string 'tile'"
data.tile"myFloor" = "'myFloor' missing brackets - Lua tries to run data.tile as a function with arg 'myFloor'"
data.tile.myFloor = ["Lua will throw an error - the square brackets shouldn't be over here"]

Also, there are other valid ways to express strings in case you really hate quote marks, or if you need a string to contain quote marks:
quoteString = 'contains "quote" symbols'
literalString = [[This string has it all: hyphens, "quotes", 'apostrophes', /slashes\,
and even a new-line!]]

Such use of symbols may seem strange, but they're needed so you can express yourself completely literally and not confuse the computer. Fortunately, Lua is much nicer-looking and less heavily reliant on symbols than most other computer languages.

Thanks :-)

Hi Taehl, tested the new version and added some items; works fine for me, thanks very much!