Hmm if you need to keep track of modifications to the noise, then you might want to have it in an array after all. I personally would still approach it by recording only what is necessary rather than everything at once though.

Again, you could break it into chunks, Minecraft style, where you keep an array instance per chunk and have a system to keep track of the relative location of each array/chunk

I am filling one z axis of the array with perlin noise values so I have a feeling that if I broke the map into many arrays that the noise wouldn't be so perliny on chunk edges

With the same seed, as long as you're consistent with your coordinate system, there should not be any seams at whatever chunk edge you define.

Well I can't answer the array size limitation question... but I can say normally I wouldn't store what is I'm assuming your entire world's procedurally generated values in an array to begin with. You should be able to look up a value at any given position for a particular seed any time you want, so just get the relevant values as you need them from a function.

Alternatively, if you must have the values in an array, you can split your arrays into chunks (can still be a single array object, with multiple instances). Use x/y instance variables to keep track of the relative position of each array, and have each array's size be whatever you're comfortable with that doesn't crash.

I'm just guessing here, but I think the array size limitation is based on your system, so I'd stay well away from that threshold if I were you, since your end users' systems might not be as capable as your own.

The "Pick Nth Instance" system condition works as described, picking only out of currently picked instances. So we kinda do already have it.

The object(n) expression does not seem to care about picking, but can reference the full instance list of that object.

The suggestion is about referencing UID in an expression. But its probably more of a quality of life niche case type of thing, as picking by UID can already be done by condition as well. Might save a few events here or there. The example Tacker gave could simply be done with a For Each player instead, or add an instance variable to narrow the scope by picking as normal.

The ability to specify only picked IID's (they call them SOL ID?) in expressions might facilitate the whole "how to I refer to and manipulate two instances of the same object colliding or otherwise interacting" without resorting to the common object and family workaround though! Maybe. That would be the fireball part of Tacker's example, and that's where I would be really interested. But that is what Ashley dismissed as already existing, which doesn't seem to be the case, so it's probably good to call attention to it.

I believe you want to use the new(ish) "Tag" property of solids, and the associated "Set solid collision filter" action of sprite objects to determine what solids those sprites can interact with.

Yes... you would just do exactly as you said. On clicked on level 1, go to checkpoint 1. Did you run into a problem doing so?

You can set the destination checkpoint as a global variable upon selecting the level, and on start of layout position your player character based on that global variable.

Huh. I always assumed object(iid) let you use values from any object, not just the ones that were picked (which is what is currently happening). Also I didn't see the manual specify that IID list changes based on picked instances (then non picked instances wouldn't have an IID during picking?). Clearly IIDs can get changed as instances of any given object get created and destroyed, but I didn't think that would happen during picking.

But based on Ashley's comment this doesn't seem to be intended... Maybe just slipped his mind about how index based expressions were set up? Just checked the earliest version of C3 that still worked and C2 and the current behavior is consistent across them, so changing this would decidedly be a breaking change... and the suggestion was talking about something else anyway.

Or even better, you can use a tiled background the same size as the viewport on a zero parallax layer, and simply set the Y offset to -1*minScroll every tick.

Even though the layout in the layout editor is small, it is still actually scrolling at runtime. So you would just need to create the next background object in the proper position (every multiple of background.height), based on the viewport position (you can use the minScroll global variable for this).

So a reddit type voting system would be only up to one vote per suggestion, but unlimited suggestions. Would definitely need to be combined with a way to cull low quality/popularity suggestions. It's easy for anyone to make hundreds of suggestions, but no one really wants to read and respond to all of them, much less actually implement or try to convince or explain why it isn't feasible (which doesn't necessarily have a straight answer to begin with).

The main disadvantage of that would be that small, easy to implement features (the ones most are actually likely to be implemented within a short timeframe) would often get lost if they are not of universal interest. And then the response to big huge features, most likely to be the most popular and usually not well definitely in scope, would simply be that they don't have enough time or resources to implement it in the near future. Those ideas would just sit on the back burner and lead to more potential frustration.

Then there is the problem of gaming the system with multiple accounts or bots, which I like to believe isn't actually a problem... But then things like spam still happen on even these forums which is kinda mind boggling to me.

Seems like common courtesy. They did make the suggestions site after all.

I mean... that's the kind of thing that would make me regret putting up a suggestions site in the first place as a developer. I stand by my stance that this level of community interaction is rather uncommon, rare even, though of course each person's own experiences may perhaps differ elsewhere.

Seems to me they made the suggestions site because did care about the community suggestions, so that suggestions wouldn't be lost in the forums. Not to mention the amount of suggestions actually implemented from the suggestion site. The unfortunate result of showing that they care, and having had some history of responses, seems to have resulted in these expectations.

If I had to make a comparison, would you expect a restaurant to send you a reply when you drop off a suggestion in the suggestion box? Microsoft, Google, or EA? The government? These entities have way more personnel and resources at their disposal. Maybe they would give you a canned response back, since they might have a dedicated PR or CM or other marketing person to return a pleasant non-answer.

Anyways, looks like this thread did result in action being taken regarding responses at the suggestions site so there's that. Someone should try setting up a suggestions subreddit. I suspect it won't gain enough traction to be superior than the current system though.

My 2c regarding the vote count - the whole point is to have users curate their own priorities, because the devs do not have the means to. If you've got 35 ideas and 25 votes, yes you have to remove votes from some of your own ideas, since the devs would never get around to 25 ideas from each idea filled person, much less 35. So the voting system supposedly encourages users to determine what is most important to them. If anything maybe it would be nice to add a some sort of policy where they reply to any idea with over a certain amount of votes, say 100. But the most likely response still isn't yes or no, it would be "Possibly, at an undetermined time in the future, should resources permit." Which is basically what the default response to every unanswered suggestion is anyway, and "Yes" wouldn't be an answer until it was ready to be pushed to beta anyway. Especially for big ideas like the scene graph that might take months of development. I would never say I'm working on it even if I decided to START working on it, because I don't know if I'd finish or how long it might take. Having an automated canned response of "Maybe" would likely do little to resolve the current frustration though.

They definitely used to read every suggestion on that site at least, regardless of response. I know some ideas with just a single person's votes had been implanted. There's probably fatigue over time with low quality suggestions, repeats, and sheer volume though, so eventually it would be taken less and less seriously or lower priority. That's why the occasional reset might not be such a bad idea after all, maybe annually with the top (5? 10? How many are reasonably expected to get implemented in a year?) ideas archived or carried over. Or maybe an idea expiration system, that culls ideas with less than x votes after y amount of time, but I doubt the platform supports that.