ata4
BspSource: Decompiling error, caused by java.lang.IllegalArgumentException: newLimit
I have this error when I try to decompile this maps: https://steamcommunity.com/sharedfiles/filedetails/?id=2845503123
[error] BspSource: Decompiling error, caused by java.lang.IllegalArgumentException: newLimit < 0: (-2138374787 < 0) at java.base/java.nio.Buffer.createLimitException(Buffer.java:395) at java.base/java.nio.Buffer.limit(Buffer.java:369) at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:1529) at java.base/java.nio.MappedByteBuffer.limit(MappedByteBuffer.java:330) at java.base/java.nio.MappedByteBuffer.limit(MappedByteBuffer.java:73) at info.ata4.io.buffer.ByteBufferUtils.getSlice(ByteBufferUtils.java:255) at info.ata4.bsplib.BspFile.loadLumps(BspFile.java:349) at info.ata4.bsplib.BspFile.load(BspFile.java:160) at info.ata4.bsplib.BspFile.load(BspFile.java:180) at info.ata4.bspsrc.BspSource.decompile(BspSource.java:107) at info.ata4.bspsrc.BspSource.run(BspSource.java:72) at info.ata4.bspsrc.gui.BspSourceFrame$4.run(BspSourceFrame.java:359)
The link to the workshop map doesn't seem to work anymore. If you could update it, I would have look at it.
@rihi I think I have a pretty similiar issue:
Error occurred decompiling '<bsp file path...>'
java.lang.IllegalArgumentException: newLimit > capacity: (178647 > 177872)
at java.nio.Buffer.createLimitException(Buffer.java:406) ~[?:?]
at java.nio.Buffer.limit(Buffer.java:380) ~[?:?]
at java.nio.ByteBuffer.limit(ByteBuffer.java:1565) ~[?:?]
at java.nio.MappedByteBuffer.limit(MappedByteBuffer.java:338) ~[?:?]
at java.nio.MappedByteBuffer.limit(MappedByteBuffer.java:73) ~[?:?]
at info.ata4.io.buffer.ByteBufferUtils.getSlice(ByteBufferUtils.java:255) ~[bspsrc.jar:?]
at info.ata4.bspsrc.lib.lump.LumpFile.load(LumpFile.java:95) ~[bspsrc.jar:?]
at info.ata4.bspsrc.lib.BspFile.loadLumpFiles(BspFile.java:424) ~[bspsrc.jar:?]
at info.ata4.bspsrc.decompiler.BspSource.decompile(BspSource.java:163) ~[bspsrc.jar:?]
at info.ata4.bspsrc.decompiler.BspSource.decompile(BspSource.java:128) ~[bspsrc.jar:?]
at info.ata4.bspsrc.decompiler.BspSource.lambda$run$0(BspSource.java:94) ~[bspsrc.jar:?]
at java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1403) [?:?]
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:387) [?:?]
at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1312) [?:?]
at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1843) [?:?]
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1808) [?:?]
at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:188) [?:?]
A few years ago I managed to decompile it btw, but now I can't get it back. I also managed to get it working by using the 1.4.5 Windows version via the .bat. Nah... It's very inconsistent.
Your problem seems to be something related to external lump files. When you have files named <filename>_l_<number>.lmp in the same directory as your bsp, bspsrc tries to load them as well. For some reason this fails.
If you could also provide the external lump file(s), I can hopefully figure out what the problem is.
@JarodSCP Your original issue however seems to be of some different cause. If you can still have the bsp, I would look at that as well.
Your problem seems to be something related to external lump files.
You're right! Indeed a problematic external lump was affecting the original bsp decompilation. The external lump was manually edited and had an excess size according to the header (178627, which becomes 178647 when including the 20 bytes from the header itself). The real size of the lump file is indeed 177872. I had forgotten to adjust the size in the lump header when I finished experimenting as, ingame, no error shows up. Here is the file btw: labirinferno_parte1_l_0.lmp.txt.
But most importantly, I did not know a lump in the same directory as the target bsp would also take part in the decompilation. I thought I had to explicitly include it in the Files list. Well, now I know. But I would suggest that you make it so that mismatching lump sizes are treated as a warning and not error, i.e. rely on the real lump size. Furthermore, it would be nice to clarify that the 'Load lump files' option reads lumps with the same name and in the same directory/path. As I hinted, when I read "external" in the tooltip, I understood that the lump files could be in any directory as long as you included them in the Files list. ;)
Yeah that's what I also took from this. Invalid lump sizes should not crash the program. We actually already have code to deal with these, but only for the lumps included in the bsp and not external ones. Should be easy to fix. I'm also not happy how external lumps are loaded, but never got around to changing it. Ideally the GUI should show which lump files are being loaded and with which bsp they are associated.