Is your feature request related to a problem? Please describe.
Loading files (particularly KV files) in VScript fails when the file is more than 16*1024 bytes large
Describe the solution you'd like
Change the SCRIPT_MAX_FILE_READ_SIZE macro defined in src/game/shared/mapbase/vscript_singletons.cpp to a bigger value.
Describe alternatives you've considered
Additional context
While the exact new cap is a point of discussion I think it's clear that 16KB is way too strict. Hitting this limit is an absolute nightmare and it has become a significant problem in the MapLabs Test Tube 12 entry for which I'm writing a VScript system, as this system uses KVs to load some data which is prone to becoming fairly large as the map increases in complexity.
I think raising the cap to at least 1MB would be enough however maybe even that will turn out to be too little if the ambitiousness of VScript systems in MapBase continues to grow. At any rate, I think that this is a reasonable baseline. Could always raise it to match SCRIPT_MAX_FILE_WRITE_SIZE (64MB) however that may be a little extreme as I'm sure there's a reason that the read limit is there (though there would be some advantages to making the two definitions match, as it means VScript code will always be guaranteed to be able to read in any data it writes out and vice versa. As it stands, it's possible for VScript to write out a file which it has no chance of being able to read back in. It seems unreasonable to expect that someone would be writing 64MB of data yet only expect them to ever be reading in 16KB)
Is your feature request related to a problem? Please describe.
Loading files (particularly KV files) in VScript fails when the file is more than 16*1024 bytes large
Describe the solution you'd like
Change the SCRIPT_MAX_FILE_READ_SIZE macro defined in src/game/shared/mapbase/vscript_singletons.cpp to a bigger value.
Describe alternatives you've considered
Additional context
While the exact new cap is a point of discussion I think it's clear that 16KB is way too strict. Hitting this limit is an absolute nightmare and it has become a significant problem in the MapLabs Test Tube 12 entry for which I'm writing a VScript system, as this system uses KVs to load some data which is prone to becoming fairly large as the map increases in complexity.
I think raising the cap to at least 1MB would be enough however maybe even that will turn out to be too little if the ambitiousness of VScript systems in MapBase continues to grow. At any rate, I think that this is a reasonable baseline. Could always raise it to match SCRIPT_MAX_FILE_WRITE_SIZE (64MB) however that may be a little extreme as I'm sure there's a reason that the read limit is there (though there would be some advantages to making the two definitions match, as it means VScript code will always be guaranteed to be able to read in any data it writes out and vice versa. As it stands, it's possible for VScript to write out a file which it has no chance of being able to read back in. It seems unreasonable to expect that someone would be writing 64MB of data yet only expect them to ever be reading in 16KB)