Closed Can't upload mods with new ".pak" exception

So far as I can tell, mods now use the extension ".pak" instead of the old ".modpak" extension. However, when I try to upload I get this message:

Code:

The following error occurred

The uploaded file does not have an allowed extension.

 

They probably just forgot to change the mod repository system to accommodate the change, tis all.

 

There's a website/forum section too http://community.playstarbound.com/forums/website-forum-support.81/

You can just zip it and upload it for now.

 

Bug? Or feature? Personal opinion here, but I despise packed files. .zip is more than sufficient and natively supported on all major modern Operating systems. You don't have to break out a command prompt/terminal to extract.

I don't see the purpose packed files serve. It is an extra step for the person making the mod - without benefit as far as I can see. It is an extra step for me - the person who wants to look around and fiddle. And I've never heard a mod user request packed files instead of a .zip... nor claim they are easier to use(they aren't).

Well to each their own I guess.

Now what I would say could be good is if Starbound would accept .zip files from the base mod directory/folder. Perhaps it is a little faster though to have things already de-compressed and that may be why it doesn't do so already.

 

The problem with zip is that it is a format designed (a long time ago) mostly for the use case of quickly extracting every file in sequence and dump them into a directory, but not so much for random access. To randomly access it, you must first collect all the file entries that it contains and build an index. Modifying individual files (for game patches) is also not an efficient use case.

So a custom format based on b-trees may be more useful (which is what the .modpack format is judging by the name of some functions I saw here and there in starbound callstacks), especially as in starbound they use thousands of tiny files to describe every bit and piece of data.
Personally I'd just stuff everything in a sqlite database as binary blobs with the metadata as relational tables instead of rolling my own solution, but either way I can definitely see the advantage of not just using zip, even if it makes modder's/tinkerer's lives marginally harder.

 

I prefer it as a .pak file since I can just drop it into the mods directory without having to unzip it at all.

 

This should be fixed.

 

Distributing one file is infinitely more easy than trying to get people to correctly unzip (yes, that's a thing) and place the folder in the right spot.

And then,there are people who STILL use archiving utilities for .zips even though it is supported natively by Windows, lol. And these archiving utilities will oftentimes put something in the wrong folder, let's say you download a mod called "Foo" and you download Foo.zip and you unzip it and you get

\starbound\storage\mods\foo\foo\

And someone who isn't all that computer savvy is then rating your mod with 1 star going "IT DOESN'T WORK!!!!!!!!!!"

You don't get that problem with a .pak file, though.

 

I suggest getting 7zip. It is the ultimate in lazy/fast compression and decompression. I do get what you're saying though... fewer steps. Aside from a small decompression overhead, I see no reason why Starbound doesn't support doing exactly the same from .zip files. This has been commonly done by countless games and applications for... decades now? For example if you're using Firefox right now to view this very thread, those .xpi files(extensions) you likely have are actually just renamed .zip files. They're very easy to use!

I don't see why Starbound doesn't simply support mods within zip files. .pak isn't supported natively within any OS that I'm aware, and neither is it supported by say... 7zip(my personal preference) and as far as I'm aware the other major programs of that nature. If that where not so, I wouldn't mind at all.

It seems asinine in 2016 to be opening up a command prompt/terminal for something like this. I'm not setting mount points, but merely trying to access the inside of a file container, or adding/replacing new files into one. If they used a more widely supported standard, that would be quite different.

I might be spoiled, but messing with semi-proprietary formats isn't worth my time. I'm well used to being able to right click, hover over to 7zip's contextual menu, and either "extract here" or "extract to (folder named after file)\" when extracting and similarly "add to (file named after folder or file).zip" when I want to make a zip file. It wouldn't be much worse even if I had to use winrar etc within their GUI.

Plus I can fix a typo within a zip file without even extracting and re-compressing everything(or unpacking and repacking if you will).
Just open the file within (7zip's GUI) like normal by double left clicking,
edit like normal,
save like normal,
7zip asks you if you want to update the file within the archive,
click yes and you're done.

You can't do that with these .pak whatever files(at least not within any program I'm aware of).

Modders like myself are not the only ones wasting our time with these packed files. Chucklefish is too. packed.pak is a big file and unpacking/repacking takes noteworthy time. Tell me that fixing small problems or adding a few new things - WITHOUT unpacking and repacking the entire mess - isn't appealing. Of course it is. Wasted time for a company is wasted productivity and wasted money. Again the zip standard offers for non-compressed files within the file container if you so wish, thus no additional loading overhead versus pak.

Now they should also probably split off the media files(which rarely if ever change) into another separate container so they have smaller updates, but that's another matter entirely.

That can happen, but it is easy to direct them how to do it. All they need to know how to do is install a mod basically as it works the same for any mod. And oddly I do see some people putting myAmazingMod.pak inside myAmazingMod.zip for download. I guess they're really sweating the bandwidth.

And again if Starbound would simply support mods within plain old standardized zip files... not an issue! I can't understand why they don't.

 

See my previous post.

Chucklefish probably do their day to day work with non packed files, and the nightly/unstable builds are probably generated automatically by a script running on a dedicated build machine pulling the latest data from their version control repository. That's the standard way of doing those things.

That's how you ought to work as a modder as well: work with discrete files directly in the mods directory, generate the pak file with a script when you want to make a release.

As a side note in case you don't know, the game can load assets directly from unpacked files in a directory. The first early access builds were released with all the data files unpacked, the asset packer was introduced later on.

 

Ah I didn't see your previous post somehow. Perhaps the main packed.pak file shouldn't be a zip file. I'd rather it just be loose files within assets, but I get they probably don't want people editing those files(rather than mod properly) and then needing support after breaking things. So having them in a container makes at least as much sense.

Still for mods(which tend to be much smaller), I don't think it would be a problem to support mods within zip files. As I already said, it would probably perform marginally better to extract them but that would probably be a worthwhile trade for ease of use (for end users of mods) while still allowing effortless access to those who want to tinker. And really they could probably just extract and cache the entire mod directory at load time without any consequential hit to RAM... unless they're trying to support someone's old 32 bit Celeron or something ancient like that. You'd just have a slightly longer initial load time. I think most of us wouldn't sweat throwing the whole game in a RAMdisk LOL. I do with with much larger games.

They should probably be doing more of that anyhow. It does seem to me that starbound must be reloading assets far too often. I noticed (when loading from a traditional HD) this with animated objects(a considerable number of them) causing considerably less lag upon shrinking the PNG files(via PNGGauntlet)... which shouldn't be so consequential. Trying to be too light on RAM usage at the expense of excessive asset loading (thus load lag) is my guess. Maybe they really are trying to support those old Celerons. Looking just now, it is barely using over 1GB.

Well I've went pretty far off topic. I'm good at that.