[Nuka1195]

in cguipassword::checkmenulock would it be possible to change the case statement for settings from:

case window_settings_menu:  // settings

to:

case window_settings_mypictures:
case window_settings_myprograms:
case window_settings_myweather:
case window_settings_mymusic:
case window_settings_system:
case window_settings_myvideos:
case window_settings_network:
case window_settings_appearance:

the reason is that window has more uses like show system info in pmiii, unless you intended for that to be locked also.

pros: it would allow more use for that window.
cons: it would mean you would have to enter the code for each individual settings window. you also wouldn't have custom settings locked, unless you could add a new constant maybe window_settings_custom.

also this check in activatewindow, could it just return if the password is incorrect, instead of setting the return window to home. it seems it was made for skins like pmiii and not allow more customized skins?

 if(!g_passwordmanager.checkmenulock(iwindowid))
 {
   clog::log(logerror, "mastercode is wrong: window with id %d will not be loaded! enter a correct mastercode!", iwindowid);
   if (getactivewindow() == window_home) // delete
     return;
   iwindowid = window_home; // delete
 }

i've briefly tested this so there may be side effects i'm not aware of.

i was also hoping there was a way to avoid asking for the password when a script exits? i know if you use master mode you can avoid this so, that's not that big of a deal.

thanks

[jmarshall]

no problems with the second piece of code as far as i can see.

not sure about the first though - on the one hand it's nice (simplifies the code - no need to check for the settings options from the context menus for instance) on the other hand it adds a restriction which may not be wanted (ability to easily navigate the settings without constantly inputting the masterlock stuff).

opinions?

[spiff]

i am very much against it. sorry. we should instead make an explicit check against the system info window if that is locked. it would simply cripple settings to the unusable.

[Nuka1195]

don't be sorry, i just thought it also would help prevent a skinner from breaking the master lock, by putting calls to the setting sub categories in a file other than settings.xml.

it would also allow settings to be on the context menu even if locked.

maybe a button on the settings window to enter master mode?

[spiff]

it would also allow settings to be on the context menu even if locked.

the reason they are hidden are that i explicitly removed them. there is no problem having them there, but locked. i figured that if you want to lock it, you don't want to make it accessible either.

this is obviously open for discussion.

as for the enter master mode button, its always just a couple of clicks away (at least using the gamepad) so i don't see the need tbh.

finally, just to make it clear, the second part of your first post, yeah, that is defintely not as it should be (i.e. it really shouldn't set the return window). left over from old code, will remedy.