Is your feature request related to a problem? Please describe.

In my case I wish to check as quickly as possible (i.e. without too complicated computations) whether the next step in the Environment will have disconnected elements (e.g. detached loads/generators). Instead of using a full simulator, I would like to use the fast obs + act interface. However, currently this does not update the topology to reflect if a line is overflowing for too long.

Describe the solution you'd like

The suggested change is to add a few lines to the grid2op.Observation.baseObservation.BaseObservation class's 'add_act(...)' method:

def add_act(self, obs:BaseObservation, act:BaseAction, issue_warn=True):
        """
        Quick method for simulating the topological effect of an action.
        This version does take line overflows into account.
        """
        cls = type(obs)
        cls_act = type(act)
        
        act = copy.deepcopy(act)
        res = cls()
        res.set_game_over(env=None)
        res.topo_vect[:] = obs.topo_vect
        res.line_status[:] = obs.line_status

        # >>>>>> START NEW <<<<<<<<
        # >> Line Overflow <<
        res.timestep_overflow[:] = obs.timestep_overflow
        res.timestep_overflow[obs.rho > 1.0] += 1
       # NOTE: Need to access the environment parameter NB_TIMESTEP_OVERFLOW_ALLOWED here somehow (!)
        overflow_mask = res.timestep_overflow > self.NB_TIMESTEP_OVERFLOW_ALLOWED
        res.line_status[overflow_mask] = -1
        line_or_topo_vect = res.topo_vect[obs.line_or_pos_topo_vect]
        line_or_topo_vect[overflow_mask] = -1
        line_ex_topo_vect = res.topo_vect[obs.line_ex_pos_topo_vect]
        line_ex_topo_vect[overflow_mask] = -1
        res.topo_vect[obs.line_or_pos_topo_vect] = line_or_topo_vect
        res.topo_vect[obs.line_ex_pos_topo_vect] = line_ex_topo_vect
       # >>>>>> END NEW <<<<<<<<
       ...

From my testing this takes about 397 μs ± 22 μs per iteration, compared to 342 μs ± 20.9 μs per iteration for the original implementation (not entirely sure why mine would be faster... since it adds more computations) . Regardless it does not seem to seriously affect the computation time.
The main issue with this implementation is that it requires access to the environment parameter NB_TIMESTEP_OVERFLOW_ALLOWED, which is not visible from obs nor act (as far as I am aware). Another issue is that just because a line is in overflow now, does NOT mean it will be in overflow the next timestep too, for instance because of the action (which the line res.timestep_overflow[obs.rho > 1.0] += 1 assumes).