The Update and Merge Menus script first records any menu customizations*. Then it clears the menus and loads the new defaults. Then, it iterates over the recorded customizations and weaves those entries back into the new defaults. While weaving those entries back in, if a menu item that was recorded as being “custom” already exists in a given menu as a result of loading the new defaults, the customization of that item is discarded - if it wasn’t done this way you would end up with duplicate items. This basically means that while the ordering of customizations should be preserved, the default ordering of items in a given menu override that of customizations.
*The script can only do this if it can discern which menu items are “custom” an which are not. Prior to build 188.8.131.52, the application simply did not keep track. A menu item either existed, or it didn’t. In 184.108.40.206, I added support for keeping track - so that I could write a script that would “Update and Merge Menus” for users that have customizations they want to keep, but also want the improvements to the defaults. This support consisted of a few changes. One of the changes was to record whether a menu item is “custom” in the menu configuration file for the session - which saves each time you accept the Customize dialog, apply a layout and/or successfully close the application. This file is one that causes the interface to load in the same state you last used it.
Because the session menu file already existed for anyone who had run the application and because there was no concept of whether a menu item was “default” or not when it was constructed, an initial state had to be assumed. Either everything was “custom”, or everything was “default.” Assuming everything was initially custom defeats the point of the script… so it had to be assumed that any entry that wasn’t explicitly marked as being non-default was in fact “default”, and could therefore be ignored in the recording phase of the script. Unfortunately, this meant that any customizations that are not “Custom Actions” (which are always “custom” - by definition) are lost when the script is run on customizations created in builds prior to 220.127.116.11.
There are a couple of ways to “fix” this…
1) Re-apply your saved layout to restore your old menus… (you did remember to save your layout, correct?). Then, manually edit the session menus.dsx in “%appdata%/DAZ 3D/Studio4” (or “%appdata%/DAZ 3D/Studio4 Public Build”) to add the Default=“false” attribute to each element that you want to keep where they are currently. Don’t bother editing the “Action” child elements of the “CurrentActionList” element, it will not have the effect you want. Keep your editing to the MainMenu, PaneMenus, PersistentMenus and ViewToolMenus children.
2) After running the script once (which will replace the menus with the defaults), use the Customize dialog (F3) to edit the menus to the configuration you want.
The shortcut bug was fixed in the Dev channel this past Friday. The general public will not see that fix until build 18.104.22.168 (or later) makes its way to either the Public Build channel, or the Production channel. Before that happens, the fix still needs to be verified in the Private Build channel, which is currently testing 22.214.171.124. The Public Build channel is slated to get the 126.96.36.199 build next, so you won’t likely see the fix until the update after next.