sorry if this is a necropost but can we bump this? I like long lists

Support! Change it to a million and make the maximum number of cloud variables 25.

Bump.

--Explosion-- wrote:

(#7)

Zro716 wrote:

You might say I should use more lists if I want more storage. Problem is, I already have multiple lists holding simple information, and 3.0 simply refuses to allow more lists to be created on demand. There's just no way to get around this unless I build some crazy switch for choosing which list to retrieve info from, which only raises the limit but doesn't remove it outright. Each time I would do this it would severely impact performance and make the project a huge waste of time, both for coding and waiting.

I understand that, at least for previous versions of Scratch, huge lists could crash the application, freeze the computer, and make saving the project difficult or impossible for a variety of reasons. This I know all too well, however, I may add that such a limit restricts the scope of projects by culling out the more advanced kinds like per-pixel image processing, world generation, and 3d engines with high-poly meshes. I highly suggest better provisions and optimizations to minimize the chance of problems occurring.

So a hard limit of 200000 items is not enough. Please, I'm asking for 1 million items, maybe just half that, if removing it isn't an option the ST is willing to consider.

You should try Snap! it os pretty much scratch 1.4 but it has WAY more blocks and advanced block making, it is good for a step up from scratch

snap is pretty cool but the problem is that its almost impossible to make vector art and the interface needs alot to getting used to
EDIT: and not many are active on there plus i dont think you can import your scratch acc into there and you CANNOT import scratch projects into there because snap uses xml for sprites projects etc and scratch used sb3 sprite3 etc

Zro716 wrote:

(#1)
Story time: I ran into a unknown problem when coding a world generator that caused layers of the world to be missing. The world required 262144 (64x64x64) voxels. After an hour or so frantically pulling my hair out, I then discovered that my world's voxel list wouldn't go past 200000 in length. That is frustratingly low for many of my complex projects, some which need at least twice that much storage.

You might say I should use more lists if I want more storage. Problem is, I already have multiple lists holding simple information, and 3.0 simply refuses to allow more lists to be created on demand. There's just no way to get around this unless I build some crazy switch for choosing which list to retrieve info from, which only raises the limit but doesn't remove it outright. Each time I would do this it would severely impact performance and make the project a huge waste of time, both for coding and waiting.

I understand that, at least for previous versions of Scratch, huge lists could crash the application, freeze the computer, and make saving the project difficult or impossible for a variety of reasons. This I know all too well, however, I may add that such a limit restricts the scope of projects by culling out the more advanced kinds like per-pixel image processing, world generation, and 3d engines with high-poly meshes. I highly suggest better provisions and optimizations to minimize the chance of problems occurring.

So a hard limit of 200000 items is not enough. Please, I'm asking for 1 million items, maybe just half that, if removing it isn't an option the ST is willing to consider.

Update: This comment by @thisandagain helps to shed some light:

thisandagain wrote:

The limit was really a performance and UX compromise. During development we did some stress testing and found that large lists were causing performance issues on many of our lower-end test devices so we started to enforce a limit to keep project performance acceptable. One of the main reasons we were concerned about this is that in 3.0 adding items to a list (forever -> add (foo) to [list]) is *much* faster (and thus easier to get into a bad state without a limit).

However, I do have a few criticisms about this.

First, the data analysis did not include runtime list sizes, only those stored alongside their projects, so the distribution was biased for static data. Many projects of mine, and perhaps of many others, rely on dynamic list allocation to populate their games and simulations with sufficient data, which is usually cleared before the project is saved to reduce bandwidth/project size. The only times it's not cleared are, for example, debugging and sharing a specific project state.

Second, adding items ad infinitum to a list ought to happen as expected. There is practically no reason to not give the benefit of the doubt to Scratchers on behalf of their ability to understand their code. Code that does exactly what you tell it to do, no side effects, is the best way to learn to respect it. If it does stuff without you knowing, like limiting what you create, you start to distrust your own code and yourself (you really shouldn't). It's needless to say, mistakes are part of learning; if you accidentally make an infinite loop of adding things to a list, just be careful next time, it's not going to destroy your computer but it would leave a good reminder to double check your flow control.

Third, while it is a valid concern that performance across devices be as smooth as possible, there are still several ways people can crash Scratch, even accidentally, just by how the VM works – using recursion and cloning. Like lists, these two significant features of Scratch are also very dangerous when used improperly. I would go as far to wager that they are more dangerous than unbounded lists because of their easy ability to lock the CPU in a high usage loop, meanwhile filling a list can take a while to get up to a few hundred MB and it won't even brick the CPU. Futhermore, most devices will resort to paging on disk when there is low available RAM, so in my opinion, the performance issue is only ever present for devices that aren't even meant to run Scratch projects of mid-to-high caliber.

Fourth, the stress-testing on low-end devices was expected to yield bad performance results, but that shouldn't mean all devices must suffer because of it. Instead, simply recommend hardware minimums so that educators know not to use computers from the early 2000's.

I would like to remind everyone, including the Scratch Team themselves, about the Scratch Design Goals, which state:

lightnin wrote:

If Scratch was a room, it would have a low floor, wide walls, and a high ceiling.

* Low floor: It should be easy to climb in and get started with Scratch - even for Scratchers who have no experience programming.

* Wide walls: Scratchers should be able to make all kinds of things with Scratch - not just animations and games, but news programs, science experiments - things we can't even imagine.

* High Ceiling: Even though it's easy for someone who is new to programming to get started with Scratch, it should still be possible to make complex stuff.

– Source

I'm entirely for upholding this brilliant philosophy by @lightnin, one of the co-founders of Scratch. His vision of Scratch, to be a tool for beginners and experts alike with near-limitless potential for creativity, is a beacon of guidance to us all. However, I have reason to believe the Scratch Team is receding on this ideal in favor of catering to their younger, less experienced audience, thus bringing the ceiling down with the floor. So as my final proposal, I would like the list limit of 200k items to only affect whether a project is saved on server or not, and use a higher hard limit for runtime performance.

this is totally useful, like for example, I'm making a random million generator, and the list doesn't hold more than 200000 items.
Support

Maybe what scratch should do is put a limit to the list of items that can be changed, the base should be 200000 and when you change it, it warns you that your computer could crash, this is helpful for scratchers with weaker systems and won't cause problems, though older or more experienced scratchers already know how to bypass this and can be careful, this can be good for both sides and protect younger scratchers from broken computers

What if instead raising the limit and lowering, what if you could change it yourself! It could early-scratches and help the advanced, experienced scratches too. Think of this, there are ways to make a maxed out list, but what if could change the max higher and lower.
you could raise it to a million for complex things, and kids like me, could just lower and keep it at 20,000. I just realized I'm just saying what griffpatch said. Well still it would be nice change to scratch and would be easier to do things like make top leader boards and stuff.

Support. Scratch, even on the not so good devices, can run massive projects, but a long list would be too much to handle? Nonsense. There’s no real downsides,so I don’t see why not.

Idk what's a better option remove or make it bigger,

Crispydogs101 wrote:

Idk what's a better option remove or make it bigger,

There used to be no limit before 3.0, so I was really confused when reading this. I also read the title wrong as file size.

full support, helps with advanced projects alot.

bump (and yes I support)

the scratch team has low money so if you want an increase in storage please donate to scratch

snowbank4 wrote:

(#93)
the scratch team has low money so if you want an increase in storage please donate to scratch

that donating won't help to increase list storage. yes, scratch will be able to upgrade, but I forsee that the lists won't get more than 2000000(all the zeros) items.

The limit isn't there for nothing, as most scatterers use tablets or “small” computers. However, 200,000 elements, in some uses, is not a lot.
I support reasonable aumentation, such as 512,000 items, or, less reasonably, a million (and clear of list contents when the project is shared or saved from the online version).

no support, the limit is there so users won't crash people's devices, just make another list

glomeromycota wrote:

no support, the limit is there so users won't crash people's devices, just make another list

You might say I should use more lists if I want more storage. Problem is, I already have multiple lists holding simple information, and 3.0 simply refuses to allow more lists to be created on demand. There's just no way to get around this unless I build some crazy switch for choosing which list to retrieve info from, which only raises the limit but doesn't remove it outright. Each time I would do this it would severely impact performance and make the project a huge waste of time, both for coding and waiting.

I understand that, at least for previous versions of Scratch, huge lists could crash the application, freeze the computer, and make saving the project difficult or impossible for a variety of reasons. This I know all too well, however, I may add that such a limit restricts the scope of projects by culling out the more advanced kinds like per-pixel image processing, world generation, and 3d engines with high-poly meshes. I highly suggest better provisions and optimizations to minimize the chance of problems occurring.

The original poster said this.
Also, probably Android 1.0 devices, and they're saying they could either raise the limit or remove it entirely.

This limit is quite useless when you think about it. Sure the vertical limit is 200,000 items, but then you can just infinitely(within your RAM capabilities) extend horizontally. That's exactly what I did on my grid tile system, basically my own implementation of a 2d array. I can hold over 100 MILLION BLOCKS doing that, using one character of a string per block.

Still, this limit is annoying and limiting.

Bump #

I have begun working on many of my own RPG engines that don't use pen so always getting around the clone limit was hard enough. Recently I've finally created one that only requires lists to generate clones with correct data from a huge list containing all the info. It has always been the limit of me the coder, always working to make something better and better, but now I've reached scratch's limits in storing list data and even if I did convert to pen, still wouldn't matter, I can merely make very small RPGs.