Closed jamartinh closed 10 months ago
Yes, some wrappers need to be imported in a slightly different way, the changes should be included in the 1.0.0rc1
release notes
Thanks, a part from the importing from wrappers instead of the older routes, I am observing that they behave different with respect to env attribute access.
In the older versions since gym and gymnasium when your root env had an attribute say a Mujoco env containint the dt attribute you can access the attribute even if you top env is a wrapper of 4 layers. However now we are forced to use env.unwrapped.dt.
Is this now by design or a temporal bug ?
This is an explicit design goal to avoid a situation where a wrapper and environment shared the member variable name
Ok, so , by design and starting at version 1.0.0 we should explicitly call the attributes of root env by env.unwrapped. Is that correct?
yes
Thanks @Kallinteris-Andreas, yes this is a by design change in v1.0.0 as otherwise users could access variables anywhere in the environment stack but importantly not modify them. This change forces users to be more explicit with where they are accessing the variables from
See https://github.com/Farama-Foundation/Gymnasium/issues/357 for the original issue
Question
Hi, are there new rules for attribute forwarding of Wrappers? In previous versions <1.0.0rc
The attributes of environments where propagated to the wrappers transparently.
Now I am experiencing many attribute errors, it seems they are not propagated any more or I am doing bad for new library specification?
If this is a NEW design structure please announce this clearly as a design option to be alerted of code breaking.
Ii there a new design documentation for how wrappers will work now ?
Thanks.