Change Details

As it stand at the moment User Vars is a mess. What with all the info that is stored e.g AAR, bis_fnc_saveinventory_data, data for every map that has been played. Then on top of this you have anything else mod/missions decide to save in the profileNamespace, especially when they are pushing out loadout configurations. This is a feature request for a change to Vars and allow mod/scripters to write out their own Vars file. This way when the end user wants to uninstall a mod/mission/script they can also delete/backup the Vars file associated with it. Looking at the VBS page there are commands that have been around for years that allow this.. newConfig loadConfig/saveConfig addValue/getValue addClass/getClass/openClass The only security issue I could see with this is.. The above allow file extensions - This could be changed to a set extension like the current .vars Malicious writing out of huge files, which I presume( never tried it ) is possible with the current profileNamespace implementation, as I've never seen anything to suggest it is not. Would you be open to community discussion on some implementation of the above. I feel it would benefit everyone both end user, mission maker, mod creator and script writers, whilst allowing the end users to have some control over their Vars files by keep them clean and allowing them to delete individual Var files for content they no longer require.

As it stand at the moment User Vars is a mess. What with all the info that is stored e.g AAR, bis_fnc_saveinventory_data, data for every map that has been played. Then on top of this you have anything else mod/missions decide to save in the profileNamespace, especially when they are pushing out loadout configurations. This is a feature request for a change to Vars and allow mod/scripters to write out their own Vars file. This way when the end user wants to uninstall a mod/mission/script they can also delete/backup the Vars file associated with it. Looking at the VBS page there are commands that have been around for years that allow this.. newConfig loadConfig/saveConfig addValue/getValue addClass/getClass/openClass The only security issue I could see with this is.. The above allow file extensions - This could be changed to a set extension like the current .vars Malicious writing out of huge files, which I presume( never tried it ) is possible with the current profileNamespace implementation, as I've never seen anything to suggest it is not. Would you be open to community discussion on some implementation of the above. I feel it would benefit everyone both end user, mission maker, mod creator and script writers, whilst allowing the end users to have some control over their Vars files by keeping them clean and allowing them to delete individual Var files for content they no longer require.

As it stand at the moment User Vars is a mess. What with all the info that is stored e.g AAR, bis_fnc_saveinventory_data, data for every map that has been played. Then on top of this you have anything else mod/missions decide to save in the profileNamespace, especially when they are pushing out loadout configurations. This is a feature request for a change to Vars and allow mod/scripters to write out their own Vars file. This way when the end user wants to uninstall a mod/mission/script they can also delete/backup the Vars file associated with it. Looking at the VBS page there are commands that have been around for years that allow this.. newConfig loadConfig/saveConfig addValue/getValue addClass/getClass/openClass The only security issue I could see with this is.. The above allow file extensions - This could be changed to a set extension like the current .vars Malicious writing out of huge files, which I presume( never tried it ) is possible with the current profileNamespace implementation, as I've never seen anything to suggest it is not. Would you be open to community discussion on some implementation of the above. I feel it would benefit everyone both end user, mission maker, mod creator and script writers, whilst allowing the end users to have some control over their Vars files by keeping them clean and allowing them to delete individual Var files for content they no longer require.