Official Forum for FTL: Faster Than Light and Into the Breach
https://subsetgames.com/forum/
Right.Sleeper Service wrote:How would it affect performance if we would separate the mod into smaller mod packages? SMM would process these one after each other, right?
The latter.Sleeper Service wrote:Could that be a possible workaround? Or does this get problematic if it has to append stuff to a file that is already very big from previously appended packages?
Is it possible to solve this issue by making the random access for mod tags optional? In effect, if no mod tags are used, then .append files are added iteratively to the disk .dat files, instead of being stored in memory (as jdom parsed objects) waiting for mod tag effects which will not occur?Vhati wrote:Ehhh. Not in a practical way. In order to have both random access to ALL parts of a file (for mod tags) and NOT have the entire file in memory (for gigantic files), it'd have to constantly re-read the file from the beginning to 'rewind' the stream for every little change - which is seriously inefficient and slow. Not to mention being a verry ugly total rewrite of the xml handling code.Sleeper Service wrote:Can it be done? Would it be worth the hassle?
I can't accomodate the exponential usage that comes from having every possible combination of every variant.
I could make up a new suffix (as opposed to png, xml, append) that gets combined in the old GMM-ish way. It'd load both files' bytes into memory, decode to strings (Trying UTF-8/Windows-1252/etc), do some minor replacements, and write them one-after-another back to disk - without using memory to create jDOM objects.rannl wrote:Is it possible to solve this issue by making the random access for mod tags optional? In effect, if no mod tags are used, then .append files are added iteratively to the disk .dat files, instead of being stored in memory (as jdom parsed objects) waiting for mod tag effects which will not occur?
Sounds great, thanks!Vhati wrote:I could make up a new suffix (as opposed to png, xml, append) that gets combined in the old GMM-ish way. It'd load both files' bytes into memory, decode to strings (Trying UTF-8/Windows-1252/etc), do some minor replacements, and write them one-after-another back to disk - without using memory to create jDOM objects.rannl wrote:Is it possible to solve this issue by making the random access for mod tags optional? In effect, if no mod tags are used, then .append files are added iteratively to the disk .dat files, instead of being stored in memory (as jdom parsed objects) waiting for mod tag effects which will not occur?
The tidying that incidentally results from printing the jDOM tree wouldn't happen, but that's only for the benefit of 3rd-party apps that would try to parse the XML (and likely choke anyway), not the game itself.
