Feature Request: Support for compressing a multicontent NSP file (built with NSC Builder) to NSZ format

[ElektroStudios]

Hi. Could you please consider to add support for allowing compression of a multicontent NSP file (built with NSC Builder) to NSZ format?.

When merging base game + updates + dlcs, NSC Builder allows me to generate two kind of multicontent NSP: a ticketless NSP file, or else an "special" NSP file with unmodified NCAs (that is what the program prints in its user interface). I don't have enough knowledge about this file format to know how it matters a ticketless or non-ticketless nca in a NSP file... both of them loads and works fine in all the emulators that I've tried.

So I tried both kind of generated NSP files in NSZ tool, but it just can't compress it. For the ticketless NSP file (which ends with a "[rr]" suffix in its auto generated file name by NSC Builder) NSZ fails with an error message about the missing .tik file.

I just came across this comment:

There currently is no official support for multicontent files inside this tool.

I might plan to support them in the future as they are probably not that hard to implement.

It's been two years since then — perhaps now is a good time to revisit the idea and start making progress towards implementing support for multicontent files? This would be a very relevant step forward for NSZ, especially as it would enable us to preserve multicontent ROM files at the lowest possible required disk space.

Could you also clarify me which NSP format would be preferred—ticketless or non-ticketless—if NSZ gains support for multicontent files in the future?, I mean in case of only one of these kind of NSPs can be supported. Just to avoid doing things in the incorrect way while I'm trying to build my rom collection...

In any case, thanks for considering this request.

[ElektroStudios]

Please check NSZ *IMPROVED* as a temporal workaround to be able compress/decompress multi-content NSP filez.

Current Improvements

• Allows you to compress/decompress ticketless Nintendo Switch dumps.
• Allows you to compress/decompress multi-content Nintendo Switch dumps. These dumps can be ticketless or non-ticketless in certain circumstances.

The "improvements" I've come up with to allow compression/decompression on multi-content NSP files actually are so basic that it only consist of altering/suppressing a few checks:

One in NSP.py file:

def ticket(self):
	for f in (f for f in self if type(f) == Ticket):
		return f
	#The presence of a ticket is not mandatory.
	#raise IOError('no ticket in NSP')

And one more in ExtractTitlekeys.py:

def extractTitlekeys(argsFile):
	...
	for f_str in argsFile:
		...
		# Prevents error for a ticketless NSP (and XCI?) file.
		if ticket is None:
			return None

This is not a correct way of adding support for a new feature (those suppressed checks could be relevant in other scenarios maybe), and also these changes that I did it causes the hash verification to fail/missmatch when using --quick-verify parameter, so I can't really consider making a pull request of these basic modifications since although they do allow the goal of compressing/decompressing multi-content ticketless and non-ticketless NSP files - and it works perfectly in that regard (I've tested compression/decompression on many many multi-content NSP files, and the resulting files are byte-identical) - I'm not really fixing anything, in fact, I'm provoking a bug in hash verification.

That is why I preferred to publish these changes as a standalone repository separated from the original NSZ repository, and this is also why these changes should be considered only a temporal workaround until the author could give us a better integrated solution.

If that happens some day then I will delete my repository.

[nicoboss]

Thanks a lot for your awesome work. I reviewed your fork and am really satisfied with the changes you performed. I don't really see any reasons for the checks and exceptions you removed and would be really happy if you could create a pull request with your changes. The main reason I have not added support for multi-content dumps so far is because of issues with hash verification but just adding a warning the way you did it seems like a much better solution then to further delay this much requested feature.

[nicoboss]

I recommend to create a separate pull request containing your batch scripts. I'm sure they would help many users to automate NSZ.

[ElektroStudios]

I recommend to create a separate pull request containing your batch scripts. I'm sure they would help many users to automate NSZ.

Hi, I just made the pull request. I tried to make two pull requests, one just for the scripts as you said, but I realized that when I made more commits to my fork (unrelated to the scripts) they were applied to that pull request, so in the end I redid everything leaving only one pull request.