Fix small printing error in aiming window

[olanti-p]

Summary

SUMMARY: None

Purpose of change

#37715 left 2 identical chunks of code related to range printing. Judging by what was printed before that PR, I think the author forgot to change the code to properly select between %d and %d/%d

Describe the solution

Format %d or %d/%d into a string, then display it

Testing

It compiles

[enaantd]

I'm no C++ expert, but considering this is the exact same block two times, I don't quite understand the need for a label_range variable. Plus I think this refactoring changes the logic quite a bit?

Wouldn't this be more appropriate?

            if( dst != src ) {
                // Only draw those tiles which are on current z-level
                auto ret_this_zlevel = ret;
                ret_this_zlevel.erase( std::remove_if( ret_this_zlevel.begin(), ret_this_zlevel.end(),
                [&center]( const tripoint & pt ) {
                    return pt.z != center.z;
                } ), ret_this_zlevel.end() );
                // Only draw a highlighted trajectory if we can see the endpoint.
                // Provides feedback to the player, and avoids leaking information
                // about tiles they can't see.
                g->draw_line( dst, center, ret_this_zlevel );
            }

            // Print to target window
            if( ( panel_type == "compact" || panel_type == "labels-narrow" )
                && display_type != "numbers" ) {
                mvwprintw( w_target, point( 1, line_number++ ), _( "Range: %d/%d Elevation: %d" ),
                           rl_dist( src, dst ), range, relative_elevation );
                mvwprintw( w_target, point( 1, line_number++ ), _( "Targets: %d" ), t.size() );
            } else {
                mvwprintw( w_target, point( 1, line_number++ ), _( "Range: %d Elevation: %d "
                           "Targets: %d" ), range, relative_elevation, t.size() );
            }

[olanti-p]

Plus I think this refactoring changes the logic quite a bit?

Yes, it restores the behavior from before the mentioned PR, when Range: %d/%d was replaced with Range: %d only when current range was 0 (src == dst).

Wouldn't this be more appropriate?

It removes the duplication, yes, but doesn't restore the behavior.

[enaantd]

My bad, I didn't read the description well enough. If this is a bugfix and not just simply refactoring, then my suggestion is indeed incorrect

[ifreund]

Thanks!