Wedge009

> The... distinction was intentional, since the main menu buttons are the game's most important buttons... This intent was what I understood, I didn't consider it as disharmonious at all.

Attempted to fix the accidental edits.

Doesn't appear that unit or orientation matters. Confirmed in 1.18 and 1.19, on Linux. ``` wesnoth: src/editor/controller/editor_controller.cpp:667: virtual hotkey::ACTION_STATE editor::editor_controller::get_action_state(const hotkey::ui_command&) const: Assertion `un != get_current_map_context().units().end()' failed. ```

From `master`: https://github.com/wesnoth/wesnoth/blob/56d05b166ba2c8687a70927d3d2de21430377ac2/src/editor/controller/editor_controller.cpp#L664-L669 Most recent change was 489dcebd0116c61ab25a65cbdcfa4df4394b53b6 for Wesnoth 1.13.11, by @Vultraz. I don't really know what `get_action_state()` is supposed to do.

The issue doesn't occur if just placing a unit. The issue occurs if the orientation menu is opened at all, even if no selection is made. `mouseover_hex()` does sound suspicious....

Actually, I think the `UNIT_FACING` case should not be hit at all when clicking File. I am not familiar with any of this code, but it looks like `active_menu_` might...

It's something to do with `active_menu_` not being set properly. If I open the 'unit facing' menu, then open some other menu such as the 'Time of Day schedule', then...

The assertion just seems to be attempting to catch the case where no unit is assigned to `un` (I really don't like these abbreviated variable names). Without knowing more about...

As noted above, it's not OS-specific. Plus Windows builds have recently switched to 64-bit.

If this is memory-usage related, my guess is #6030 could be related as well.