Please, make your mod support https://mods.factorio.com/mod/cb-science
Thank you in advance

I'll check it out

I am already using CB Science with this mod, it works fine.

It does, but the labs flash purple only.

I hadn't noticed, but you're absolutely right. Good catch.

May I suggest adding an API for this so that mods can specify these colours themselves?

@Hornwitser I would love to do that. Can you think of any examples where someone has done this sort of thing? I was thinking of asking the developers to allow items to specify fuel colour even if they aren’t fuel. That would be almost perfect.

The only way I've seen in the data stage is using global variables/tables/functions. So basically you'd have something like DiscoScience = { itemsColors = { ... }} in data.lua, and then mods could do something like following in their data-updates.lua:

if DiscoScience and DiscoScience.itemColors then
    DiscoScience.itemColors["__cb-science__/graphics/red.png"] = {r = 1.0, g = 0.1, b = 0.1}
    ...
end

Ok here is what I've got at the moment (sorry Dragonling for hijacking this thread but my hope is that it will lead to more compatibility with mods such as CB Science)

Mods need an optional dependency on DiscoScience. If they're just registering new ingredient colours it looks like this in control:

script.on_configuration_changed(
    function ()
        if remote.interfaces["Disco Science"] and remote.interfaces["Disco Science"]["setIngredientColor"] then
            remote.call("Disco Science", "setIngredientColor", "automation-science-pack", {r = 1.0, g = 0.1, b = 0.1})
            remote.call("Disco Science", "setIngredientColor", "logistic-science-pack",   {r = 0.1, g = 1.0, b = 0.1})
            remote.call("Disco Science", "setIngredientColor", "chemical-science-pack",   {r = 0.1, g = 1.0, b = 1.0})
            remote.call("Disco Science", "setIngredientColor", "military-science-pack",   {r = 1.0, g = 0.6, b = 1.0})
            remote.call("Disco Science", "setIngredientColor", "production-science-pack", {r = 1.0, g = 0.1, b = 1.0})
            remote.call("Disco Science", "setIngredientColor", "utility-science-pack",    {r = 1.0, g = 1.0, b = 0.1})
            remote.call("Disco Science", "setIngredientColor", "space-science-pack",      {r = 1.0, g = 1.0, b = 1.0})
        end
    end
)

If they're registering new labs that use the standard lab graphics then they need to be prepared in the data stage:

if DiscoScience and DiscoScience.prepareLab then
    DiscoScience.prepareLab(data.raw["lab"]["lab"])
    DiscoScience.prepareLab(data.raw["lab"]["sct-lab-t2"])
    DiscoScience.prepareLab(data.raw["lab"]["sct-lab-t3"])
    DiscoScience.prepareLab(data.raw["lab"]["sct-lab-t4"])
end

...and something like this in control:

script.on_configuration_changed(
    function ()
        if remote.interfaces["Disco Science"] and remote.interfaces["Disco Science"]["setLabScale"] then
            remote.call("Disco Science", "setLabScale", "sct-lab-t2", 1)
            remote.call("Disco Science", "setLabScale", "sct-lab-t3", 1)
            remote.call("Disco Science", "setLabScale", "sct-lab-t4", 1)
        end
    end
)

What do you think?

Drop the space in the remote interface name.

The setIngredientColor interface doesn't look right to me. cb-science changes the graphics of the vanilla science packs, but cb-science doesn't really know if the graphics where changed or not, another mod might change it to something else after cb-science did. If there are multiple mods changing the graphics for the vanilla science packs how would the setIngredientColor know which one is the right one? The last mod to call it is not necessarily the mod who's change to the graphics stuck. I guess it wouldn't be much of a problem in practice if the colors are based on the item names instead of graphics, cb-science doesn't modify the colors, few mods do, so it wouldn't need to set the ingredient colors in the first place.

I guess that’s the thing: if two mods change the same ingredient colours and are compatible with one another, then at least one of the mod authors has considered how to resolve the conflicts. If they choose to make their mod compatible with Disco Science, then they should already have the information I need.

1.0.0 is now out with the new API, and the FAQ updated with instructions. Please let me know how it goes!