If using both this mod and Multiple Unit Train Control, it appears that the quality locomotives get replaced by this mod and not MUTC. From my understanding, the ideal situation would be that the combination of the mods would result in the locomotive first getting replaced by this mod, to leverage the quality scaling, and then further replaced by MUTC to tie the locomotives together.

But it appears that the 2nd replacement does not occur. I'm unsure which mod causes this, as from my understanding, MUTC should be compatible with any modded locomotive. The Quality locomotives from this mod should effectively just be a modded locomotive entity that just replaces the regular quality locomotive. So I think the replacement effect from MUTC is somehow getting cancelled or just not happening for some reason.

I made a post on the other mod's page, but have not seen a response so far. I figured I would also post here in case a resolution can be found.

Fixing this from my side would be cumbersome - to set up its entity maps, MUTC uses hidden recipes for each original/mu-clone pair. This requires each "original" to have an item with the same name, otherwise the recipe would be invalid.
While it seems to me to be possible to create all the required recipes and items (and add them to the list inside the hidden technology), I'm not sure if this would cause some side effects with MUTC or other mods.

I wouldn't want to implement this in the MQS mod natively (code bloat, risk of later incompatibilities, ...), though perhaps a "MQS/MUTC compat mod" could attempt to create the compatibility between the mods this way...

The easiest option would probably still be if MUTC a) added a final-fixes script which, if MQS is installed, adds the hidden items/recipes it requires for all the quality variants (requires optional or hidden dependency on MQS to be sure to run afterwards, when the variants actually exist) OR b) changed the replacement logic to be aware of the added quality suffix (I'd be happy to add a mod data entry for that - eg. a map from qualitized variants to the "normal" one, list of used suffixes, maybe even a collaborative suffix priority and decongestion system if necessary).

A variant of option b) would be to generally replace the "hidden technology effects, recipes and items" construct with a MUTC-specific mod data entry, where I could add entries without risk of side effects (or I added my own mod data for MUTC to look at - there are many ways to organize compatibility with mod data entries).

Ahh, I see. I went ahead and added your response to my post on MUTC's page. I still haven't gotten a response there yet, but perhaps with your input, I might.

In the meantime though, maybe we could look into some of the options on this side (or in a compat mod you mentioned)? If you were to add the required recipes and items to satisfy MUTC's current logic, would it still be possible to keep them hidden to the player? Or must they be visible? If they can exist while hidden, then I am not sure I see what side effects this might cause.

I threw together something that might or might not work: https://mods.factorio.com/mod/mqs-compat

One possible side effect I have to worry about is that some future change in MUTC might create a hard incompatibility with the items I would add, and crashing on startup (possibly with an error message that doesn't even mention MUTC) would be worse than just having some missing functionality at the intersection of two mods.
Another possible issue would be other mods adding items with those names (either before or after I do), which could also result in hard to debug crashes - and finally some mods might assume those items belong to the entities with the same name (eg. entity "locomotive-legendary" -> item "locomotive-legendary"), even though all quality entities of MQS are still linked to the original vanilla item ("locomotive") - this could result in script crashes, loss of items, or generally undefined behavior.

Even without these issues, I don't want to include complicated compatibility logic specific to some other mod in MQS to keep the mod maintainable.

Please report back whether everything works as expected, when you get the chance.

Hey, sorry I've been a bit busy recently and so haven't had a chance to play and check it out yet. But I'll definitely let you know how it goes when I do.

Hey sorry for the much delayed response. I finally got around to trying the mqs-compat mod you created, but it doesn't appear to like being loaded alongside Multiple Unit Train Control.

I can have More Quality Scaling + mqs-compat or More Quality Scaling + Multiple Unit Train Control. But I cannot have More Quality Scaling + mqs-compat + Multiple Unit Train Control.

Get the following error while loading mods:

Failed to load mods: __mqs-compat__/data-final-fixes.lua:24: attempt to index field '?' (a nil value)
stack traceback:
    __mqs-compat__/data-final-fixes.lua:24: in main chunk

It seems this initial issue was relatively straightforward to fix. It looked like there were some zero-indexed arrays that just need to be changed to a 1. And then towards the bottom, it looked like we were assigning newR rather than just rec inside the loop. That allowed the mods to at least load together.

But it still didn't fully function, as if you tried to start a new game or load an existing save, you would get the following error:

The mod Multiple Unit Train Control (1.0.5) caused a non-recoverable error.
Please report this error to the mod author.

Error while running event MultipleUnitTrainControl::on_init()
__MultipleUnitTrainControl__/control.lua:106: attempt to index field '?' (a nil value)
stack traceback:
    __MultipleUnitTrainControl__/control.lua:106: in function 'InitEntityMaps'
    __MultipleUnitTrainControl__/control.lua:745: in function <__MultipleUnitTrainControl__/control.lua:739>

It looks like MUTC expects a valid entity prototype that is missing?

Thanks for taking a look. I think I used the wrong format for the entity names - try 0.0.2.

So I loaded up 0.0.2, but alongside the updated More Quality Scaling mod, the locomotives no longer appear to be getting replaced. I tried removing Multiple Unit Train Control and the compat mod and kept only More Quality Scaling. And it seems with the latest update, it appears that the quality locomotive entities are no longer getting replaced. Placing down a normal quality locomotive and a legendary quality locomotive results in both having the same top-speed and acceleration, even with locomotive quality settings enabled and even pushed up to "OP".

I just tested 1.5.4 in my current modlist, and the locomotive replacement works as intended. Are you playing with other mods enabled that might interfere with the replacement? Can you check if in the factoriopedia, there is a group of "item-group-name.mqs-qualitized-entities" (I should probably localize that) that (among other things) contains locomotive clones with modified top speeds?

Hmm, indeed it must have been another mod interfering after all. I did have the item-group-name.mqs-qualitized-entities group in the Factoriopedia with the modified locomotives originally, but it just hadn't been performing the replacement. Which is odd, because with the modlist that I had been testing with previously, the replacement used to occur with the extra mods.

But if I do isolate to exactly the required mods, it does appear to work, yeah. I'll do some more testing and see if I can track down what other mod suddenly started interfering with the replacement.

Ahh, I found the conflict. Which surprisingly wasn't a conflict with the presence of the mod, but just a single configuration for the mod. Which was Adjustable Quality. Was using it for minor adjustments for things like quality name. But between my last testing and this time, I was doing some other tests with Adjustable Quality, so my configs were different. I had forgotten to change them back.

From my testing, Adjustable Quality is almost completely compatible. But apparently, specifically the base quality level setting breaks your mod, somehow. By default, Normal Quality has a quality level of zero (which makes sense). If that is set to anything other than zero, then the locomotive replacement no longer occurs.

The quality level of the other qualities can be changed perfectly fine, and as far as I can tell, everything else about Adjustable Quality can be used with no issues. But not that specific configuration, which is interesting.

Thanks for tracking it down that far.

The issue really confused me at first - in my control script, I was caching the first non-zero quality level in the table ("normal", if that was changed to >= 0) to check if any qualitized variants of an entity exist. But since I don't create clones for "normal" quality level, the script then assumes no quality variants exist, and skips all further processing.

I did make my code safe for other mods that might remove all the vanilla qualities, but didn't expect there to be mods that change normal.level :D

Since I currently don't make clones for "normal" even if it has a level >= 0, I can just change that check to name ~= "normal" to fix this compatibility issue - though I am tempted to just add a setting override for Adjustable Quality instead :D

For full compatibility, I could make clones for "normal" as well if level / default_multiplier are changed instead, but surely, that way lies madness...

Hahaha, that way probably does lie madness. But to be fair, this is modded Factorio. We left madness behind a few hundred hours ago, if not even longer. XD

Adding Adjustable Quality to the compat mod might be doable without madness? But considering that even the names of the qualities can be changed, I dunno if using the name as a check like that would even work.

I figured there should be a way to iterate through the qualities, whatever they are, if present. I mean, I know some mods add completely dynamic amounts of quality levels. And they can be pushed to like 99+ levels. I feel like there's no way that's possible without some means to iterate through qualities without knowing their names/levels in advance. But I haven't actually looked into it.