Pretty please?

It seems like a small thing but it'll make a huge world of difference for people.

No, I'm not asking because I want to make Codebreakers bigger! What are you talking about? XD

(in all seriousness, I'd absolutely love just file-size increases in general lol)

I would love this more than anything. Please Scratch Team!

5 is a nice, round number, and it'd take up more server space if this happened. Most people don't make projects that exceed the size limit anyway

ArcanisHD wrote:

Pretty please?

It seems like a small thing but it'll make a huge world of difference for people.

No, I'm not asking because I want to make Codebreakers bigger! What are you talking about? XD

(in all seriousness, I'd absolutely love just file-size increases in general lol)

he don't miss. he's spittin' facts. a file size increase would probably also help some of my friends finish their projects. definitely not talking about Monster World

mtech22 wrote:

5 is a nice, round number, and it'd take up more server space if this happened. Most people don't make projects that exceed the size limit anyway

Fair, but on the off-chance that their servers could handle this… it would be real nice.

Support! That way griffpatch can finally add the nether to paper Minecraft! this would make it easier to make much bigger projects which many people would like. I would personally like changing it to 8 as it’s also a power of two

Note: Red indicates evidence/key points; Orange indicates counterarguments; Limegreen indicates benefits/arguments for support.

Support! Considering how singular assets can already reach a larger size than 5 mb, it doesn't really make sense to me why the JSON file of a project can't be, say, 10MB (The audio file size limit when saving/uploading a project to the site).

To begin with, let's talk about the “issue” of project space.

Hypothetically, if whenever a Scratch project were made and 5 MB of static partition were created per instance, then, well… Considering how we have 76 million projects shared, that's 380TB of data (for only shared projects!). That's just a fraction of, say, the hundreds of millions of unshared projects. In this scenario, the amount of data doesn't seem to be very manageable, so I'm assuming that Scratch stores projects dynamically rather than having a static partition per project, and even if it didn't, a singular MB increase (refer to OP's suggestion) wouldn't hurt all that much, provided scratch's hypothetically enormous database size. In this case, I don't see why we can't have more JSON space for our projects. And considering how project assets (specifically audio files!) can be quite large to begin with, I don't understand why JSONs in particular are limited.

Even if space weren't the issue, someone could also argue that the increase in file size would allow people to program very sloppily and bloat their projects without a care for their code structure, therefore developing poor coding habits. I am here to point out that reaching 5MB of code is actually quite difficult; thousands of lines of code have to be written before you can actually hit that file size limit. In fact, the majority of those who have hit that limit likely possess the skills necessary to develop clean, organized code; most probably, they'd just like to take their projects to the next level with a new feature they'd like to add if provided the appropriate and necessary space.

Counterarguments aside, having a larger json size limit brings a couple of benefits, one of which is more breadth and depth to larger, more complex projects. While the “general audience” may create projects of smaller size, there are people who want to add large amounts of features to their creation(s) to expand its complexity. Those same people are deterred by the file size limit, and often end up scrapping ingenious ideas just to be able to share their projects. This in turn often leads to stunted creativity and a general habit of creating shorter, insubstantial projects. By increasing the json limit, creators have double that freedom and are able to create larger and more substantial games, animations, programs, etc.

Another point I'd like to make: adding a MB of file space doesn't pertain to blocks; it doesn't require extra consideration on, say, the validity of its use, the complexity for beginners, or even the availability of a block. In fact, adding more JSON space brings no considerable downsides to users, doesn't hamper the complexity of what is already there, and improves the possible availability and diversity of various Scratch projects that we'll be able to see in the future. The addition is also unlike cloud variable expansion; I'm pretty sure there isn't a whole tangle of web service issues to go along with increasing bandwidth when adding space to a JSON file.

I think that the idea of Scratch as a platform to Imagine, Program and Share should be limitless. While the notion of projects having an infinite size with unlimited assets being added is certainly a fantasy, I believe that the idea of increasing the file size is certainly achievable. As it stands now, there is an increasing amount of users who plan on, or are, making massive projects, some as a culmination of the skills they've learned on Scratch, others programmers taking a concept onto a whole new level. Having a 5MB JSON limit restricts the creative freedom of programming, and in turn, imagining. In other words, the current size restriction on JSON files leaves Scratch's motto unjustified and unfulfilled. Sometimes, that size limit ends up forcing programmers to reimagine or water down projects in order to share them. Sometimes it can even make users abandon otherwise brilliant and inspiring project ideas.

Simply put, there currently seems to be a rising need for more JSON space in our projects as people develop more and more comprehensive projects. People like us (who create/are in the process of creating large projects) are already doing everything we can in order to keep our projects down to the limit, be it code optimization, modular custom blocks, or worst of all, feature-cutting. And while there are workarounds to “gain JSON space”, people like me would like to just have a bit more inherent space within our projects.

It doesn't have to be a huge amount. Like the OP said, even a single MB will do.

I don't know why the limit for project.json is smaller than that for assets.

Ah, this is hard. This would be nice for massive projects that need 1 extra MB, like paper Minecraft. However, this may affect the servers a lot, and like @mtech22 said, most projects does not even hit the 5MB limit. From this, I think the cons outweigh the pros.

Fun fact: Every Scratch project that is already saved doesn't exceed this 5MB limit!

No support, it could make the servers much more expensive than before, so anyone can make 6MB projects.

I don't believe this would cause any problems for the servers. They can already store 10 MB sounds, so why not 10 MB code? And the number of projects is unlimited, so this doesn't affect storage space at all, just the server performance.

mtech22 wrote:

5 is a nice, round number, and it'd take up more server space if this happened. Most people don't make projects that exceed the size limit anyway

If most people don’t make projects that exceed the limit anyways, then concerns over server space would be a nonissue. As Gungallo pointed out, it’s unlikely that Scratch just partitions 5mb for each project’s JSON.

Socialix wrote:

Fun fact: Every Scratch project that is already saved doesn't exceed this 5MB limit!

No support, it could make the servers much more expensive than before, so anyone can make 6MB projects.

This fun fact is false. For example, take qucchia’s project here. While their project is relatively newer, it shows the fact that before 3.0, instead of having a JSON size limit of 5mb, there was just an overall file size limit (50mb in 2.0 and 10mb in 1.4). Projects could exceed 5mb in JSON because it wasn’t a limit, total JSON + asset size just had to be within that limit. In 3.0, asset size is nearly unlimited (318 Gb maximum) while JSON size was arbitrarily capped at 5mb.

To address your second comment, see my response for the previous quote.

No support, like Socialix said, it could make the servers much more expensive than before.

You can REDUCE the size of your project.json, there is a helpful tutorial here: https://scratch-mit-edu.ezproxyberklee.flo.org/projects/505513306/

support

WindowsMeRules2000 wrote:

support

Be constructive, give reasons why you're supporting this please.

–

Anyways, no support, Scratch is already generous with their data, and yes, I agree with Socialix - it could make the servers more expensive.

ktrav258 wrote:

ArcanisHD wrote:

-snip-

he don't miss. he's spittin' facts. a file size increase would probably also help some of my friends finish their projects. definitely not talking about Monster World

Please don't quote the first post of this thread!

Maximouse wrote:

I don't know why the limit for project.json is smaller than that for assets.

JSON is just text. While other assets can be 10 minutes long sound files. I don't think project.json should ever have the same limit as assets.

But increasing the file size by 1 MB isn't a big deal. Many people won't even use a tenth of it, so nothing bad would happen to storage space. At the same time, there is more room for advanced projects to grow. So, I would support this suggestion.

PUNNAMOODU wrote:

Maximouse wrote:

I don't know why the limit for project.json is smaller than that for assets.

JSON is just text. While other assets can be 10 minutes long sound files. I don't think project.json should ever have the same limit as assets.

project.json contains the values of variables and lists, which are often used for similar purposes as costumes and sounds.

Retracted. Please discuss compression of project.json in a different topic.
Bumping this to bring up a point that I haven't seen brought up in this suggestion or any others like it: project.json is trivial to compress and the benefits are immense. For example, compressing the JSON file for Paper Minecraft using Windows' built in ZIP compression features takes less than a second on my computer (AMD FX-8350, 2012), but it shrinks it to only about 16% of its regular size.

I don't see any reason why the JSON files couldn't be stored on the server in compressed form, with compression and decompression happening on the client.

full support. I am making a banner creator with lots of font data for the pen font engine and it's going to get huge to the point where I can only edit it in turbowarp and I have to package it up.