[Proposal] Add fully tunable transition dynamics (including deterministic mode) to LunarLander

Proposal

I propose extending Gymnasium’s latest LunarLander implementation with explicit transition-dynamics controls so users can easily tune or disable stochasticity and physical coefficients without maintaining a custom fork/subclass.

Specifically, expose optional kwargs for key dynamics parameters (with backward-compatible defaults), including reset impulse strength, engine dispersion, wind/turbulence terms, engine/leg power terms, and optional body-level scaling/damping controls, plus a convenience deterministic=True mode that forces zero stochasticity.

Motivation

This feature request is related to reproducibility and controlled domain-shift research. I’m always frustrated when I need to isolate one transition factor (e.g., dispersion vs wind vs initial impulse) but the environment only allows partial control, so I have to monkey-patch internals or maintain a local subclass.

Related issues that overlap partially but do not cover full transition control:

• #954 (wind reset randomization)
• #728 (reset determinism behavior)

Neither provides a comprehensive API for fully controlled transition dynamics.

Pitch

Add optional constructor kwargs (all defaulting to current behavior), e.g.:

• initial_random_strength
• dispersion_strength
• enable_wind, wind_power, turbulence_power
• main_engine_power, side_engine_power
• leg_spring_torque
• optional body-level controls (lander_mass_scale, leg_mass_scale, linear_damping, angular_damping)
• terrain controls: fixed terrain_heights (or equivalent terrain profile input) and/or explicit terrain-generation seed/profile mode; option to ensure the helipad is flat (default True)
• deterministic: bool convenience switch

Expected behaviour:

• With defaults: no behaviour change.
• With deterministic=True (and fixed seed), trajectories are reproducible for identical action sequences.
• Users can create controlled transition shifts without subclassing Gymnasium internals.

Alternatives

Alternatives considered:

• Keep using custom subclasses/wrappers outside Gymnasium.
• Monkey-patch module constants at runtime.
• Maintain a private fork of lunar_lander.py.

These alternatives are harder to maintain, brittle across upstream changes, and make reproducible benchmarking less standardised.

Additional context

I implemented this pattern locally in a TunableLunarLander variant and found it useful for:

• controlled continual-learning task design,
• deterministic evaluation,
• ablations over individual dynamics factors.

If helpful, I can share an API sketch and tests showing backward compatibility plus deterministic trajectory checks.

Checklist

• I have checked that there is no similar issue in the repo