The current scaling system is storing values in a table using tuples as keys (for example human_male~gnome_female). We have to have a scaling value for each model against every other model.

The system could be improved by using custom unit as a value of height and have all models be measured in that value. For example, we take Human Male as the unit, so human_male = 1. Then when scaling a Female Gnome against a Human Male we have gnome_female = 0.367 (implied 0.367 human_male). If we were to scale other models against the Female Gnome we can compute their human_male value since we know the human_male value of the Female Gnome, so for example if a Draenei Male is draenei_male = 3.78 gnome_female then we know draenei_male = 1.38726 human_male.

This method means we only have to scale a model once against another known model to have it scaled against every other known models.

What about when scaling two unknown models against each other? If we were to scale a flame elemental against a murloc, but neither of them have a known height in human_male, we can use the other models as a unit of a new (ultimately temporary) scaling system. So we could have flame_elemental = 0.88 murloc and murloc = 1.12 flame_elemental. All models that would then be scaled against one of the models would be scaled using that model as a unit, like naga = 1.48 murloc. We would have an independent scaling system using a different scale. Until we finally have one of the model in that system that is scaled against a known model using the human_male system. If at some point we know that flame_elemental = 0.97 human_male we can infer the human_male height of all the other models in the system, effectively connecting that remote system to the standard system, so we would know that murloc = 1.12 flame_elemental = 1.0864 human_male and naga = 1.48 murloc = 1.607872 human_male.

Here's a whiteboard sketch (in French) I did a long time ago now about this improved scaling system.

Satellite systems of unknown units resolution maths, by Solanya:

A few questions after looking at the code :

• Is there a technical reason that makes the ["ID1~ID2"] = { height1, height2 } structure better than ["ID1"] = { ["ID2"] = height1, ... }, ["ID2"] = { ["ID1"] = height2, ... } ?
  The second one seems better to explore the known custom heights as it wouldn't require to check pairs without either model when trying to find a satellite, but I don't know if there's a reason performance-wise or else. (Of course that would mean changing the code and patching the saved structure.)

• Do we want to save the data if we found a satellite ? Or are we only saving if they manually edit the height after ?

• Do we stop at the first satellite found or do we try to find as many as we can and average them ?

Seems like it won't be too much trouble to do otherwise.

The model1~model2 system has to go with the new system. It was necessary with the old system. The new system should have the value stored into a "Unit system", kind of like this:

UnitSystemX = {
ID1= 2.3,
ID2 = 0.8
}

A work has already been done on having a Class model for the Unit systems. The code has to be adapted to use this indeed. Patching the existing saved structured is not necessary, it would require to much work and could be easily re-implemented using this new system.

We only want to save if the height is edited, indeed. Otherwise it could provoke invalid value when we resolve unknown satellites dynamically.

We should resolve all the satellites that are solvable when we set a height that allows to attach satellites to the main system. If model A is found is 3 satellites and we get to set its height in the main system, all three satellites with model A should be resolved. Then, if the satellites contained models that are in other satellites, they should be resolved too, everything cascading until nothing is solvable anymore. This would be the actual true power of this system.