[Bugsy]

Originally Posted by imindfreak I changed it to 1024, 9999, and 99999 to test but unfortunately no good.

What issue are you having?

[imindfreak]

Originally Posted by Bugsy What issue are you having?

It's exporting the nvault data successfully now.
Thank you so much for your help Bugsy!

I was wondering if there is a way to not export bot data for the sake of making exporting faster.
Something like an if condition where if (!contain(szKey, "[Bot]")
or some sort of substr(szKey, 0, 5) equals "[Bot]".
Key values for bots will start with [BOT].

Example :

Key:

PHP Code:

[BOT]SomeBotName 


Value:

PHP Code:

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 : 1485454235 : 18 0 : 0 


Also, for one of my key's, the value is not correctly exported.
The value is cut off but it's the only one that is cut off so I'm not sure why.
I may end up just deleting that key completely as it could be corrupt for whatever reason.

[Bugsy]

Yes, I can make it not export bot data as long as there is a consistency in the name/key value.

The data being cutoff is be due to the data length limit set in nVault Utility which is 512 characters. It was set to this value since in most cases this covers the amount of data being stored.

If you set this to a larger value and recompile, it should export correctly.

#define _NVAULTUTIL_MAX_VAL_LEN    512

[imindfreak]

Originally Posted by Bugsy Yes, I can make it not export bot data as long as there is a consistency in the name/key value. The data being cutoff is be due to the data length limit set in nVault Utility which is 512 characters. It was set to this value since in most cases this covers the amount of data being stored. If you set this to a larger value and recompile, it should export correctly. #define _NVAULTUTIL_MAX_VAL_LEN 512

I increased that value to higher values, recompiled, and it still gets cut off.
I restarted the server and changed maps a couple times to see if it would update.
It didn't seem to have any affect when I changed _NVAULTUTIL_MAX_VAL_LEN's size at all but it should...

As for the bots, the bot's key is saved as "[Bot]NameOfBotHere" and the value is random.
So the only consistency the key's name string starts with "[Bot]". The values are not consistent though.

[Bugsy]

Above code has been edited to not export keys beginning with '[BOT]'

For that one record where the data is being cut-off, does that exist in the above vault you posted? If so, what is the key?

[imindfreak]

Originally Posted by Bugsy Above code has been edited to not export keys beginning with '[BOT]' For that one record where the data is being cut-off, does that exist in the above vault you posted? If so, what is the key?

The updated code worked perfectly on not exporting bot keys, thanks!
Attached below is an updated vault in which the 7th key, STEAM_0:1:12710464, is cut-off (508 characters in total exported to the 'Info' column).
This would be the 3rd entry as there are 4 bot entries before it.

[Bugsy]

Set _NVAULTUTIL_BUFFER_SIZE to 1024 as well. I need to update nVault Utility to either handle larger data or at least show an error message if the data for the vault record is larger than the string allocated to store it in. I will probably create a second type of nvault_util_read() and nvault_util_readall() where the user can input their own data buffer and not rely on the conservative sized buffers that are hard-coded. While they work for the majority of users, it would be nice to provide another means to handle this without having to modify the include file. nvault_util_read2() and nvault_util_readall2() maybe.

This issue likely affected other records in your vault, too.

[imindfreak]

Originally Posted by Bugsy Set _NVAULTUTIL_BUFFER_SIZE to 1024 as well. I need to update nVault Utility to either handle larger data or at least show an error message if the data for the vault record is larger than the string allocated to store it in. I will probably create a second type of nvault_util_read() and nvault_util_readall() where the user can input their own data buffer and not rely on the conservative sized buffers that are hard-coded. While they work for the majority of users, it would be nice to provide another means to handle this without having to modify the include file. nvault_util_read2() and nvault_util_readall2() maybe. This issue likely affected other records in your vault, too.

Perfect! Worked like a charm. I appreciate all the help!