Warning about possible wrong USE nodes at load if PROTO parameters not listed in the correct order

[stefaniapedrazzi]

Currently if the parameters of a PROTO instance are not stored in the correct order (for example in a world or parent PROTO file), it is possible that at the load the USE nodes refer to the wrong DEF node because:

• Webots DEF dictionary is based on the PROTO definition fields order (the same that is also displayed in the scene tree)
• WbNodeReader DEF dictionary is based on the reading order

Errors do not only occur if some default PROTO parameter values are used, but also in case of custom parameters.
But the main problem is that no warning is printed in the console and the user might not notice the issue.

Adding some additional computations (like looping through the parameter subnodes) it is possible to detect if the currently unordered field contains DEF nodes. If we add additional steps it should also be possible to detect if the current parameter is really shadowing previous parameter DEF nodes.
Or we could simply print a warning for each unordered list of PROTO parameters.

So the main question is which level of precision (and code complexity) we would like to have for the warning.
Note that if we print a warning for each unordered list of PROTO parameters, many user's simulations might print this new warning.

[stefaniapedrazzi]

Alternatively we could also improve the reading functionality so that it won't depend on the fields order in the world/proto file but only on the PROTO definition fields order.

[omichel]

I believe it should be legal to use PROTO parameters in any order. And that should not break the USE/DEF mechanism.
For example if we have a PROTO like this:

PROTO MyProto [
  field SFNode field1 NULL
  field SFNode field2 NULL
] {

...

}

And then we use it in a world file:

MyProto {
  field2 DEF CUBE Box {}
  field1 USE CUBE
}

It should work as expected.
When saving from Webots, Webots will re-order the fields and re-shuffle the USE/DEF accordingly:

MyProto {
  field1 DEF CUBE Box {}
  field2 USE CUBE
}

Is that difficult to implement?

[stefaniapedrazzi]

It is not straightforward to fix the reader to support DEF nodes in any order.
Currently WbNodeReader uses a simple list of DEF nodes, but this is not sufficient as it doesn't allow to manage the order of the nodes. We should store different levels of DEF dictionaries to be able to reorder them correctly independently from the reading order.

Currently even this simple example is not working:

PROTO MyProto [
  field SFNode field1 NULL
  field SFNode field2 NULL
] {
...
}

For example this world:

MyProto {
  field2 DEF GEOM Box {}
  field1 DEF GEOM Sphere {}
}
Shape {
  geometry USE GEOM
}

At load, the USE GEOM in the Shape field is a Sphere.
But if delete and readd USE GEOM from the Webots UI, it becomes a Box.

Note that supporting the example you posted it's even a step further in complexity.

[omichel]

OK, we can we do to address this problem?

1. enforce PROTO parameter order and display a warning for any PROTO parameter not in the original order.
2. forbid the use of USE/DEF in PROTO parameters and display a warning or error in case it happens.

I would prefer option 2 unless you have a better idea?

[stefaniapedrazzi]

2. forbid the use of USE/DEF in PROTO parameters and display a warning or error in case it happens.

Option 2 would be a big step back in usability of Webots and it would be the same as completely removing the USE/DEF mechanism. So I would not choose this option.

I will inspect in more detail the complexity to make the reader independent from the fields order and the option to detect if errors with USE nodes occur due to the fields order so that precise warnings can be printed for fields order only in case of issues.

[stefaniapedrazzi]

The only option to be able to support unordered fields and have the same result at load and from the Webots interface will be to display the fields in the UI using the same order as in the file.
Because even if it can be possible to switch the USE and DEF nodes in the example in #2108 (comment), the second example (#2108 (comment)) requires a common field order (the one from the PROTO definition or the one from the file) to have consistent results.

[omichel]

Yes, that seems to be a good idea.