|First Seen:||7:52:39 PM 16/1/2016|
|Last Seen:||8:53:42 PM 20/9/2020|
What would be the difference with your suggested block? This appears to be a flaw with having a system with daylight cycles, which using days since 2000 vs current [ v] in (timezone) has no effect on. Days since 2000 allows you to get a value for the time in any time zone, meaning there is no difference between it and your suggested block, so there should not be any cases for which one works and the other does not. There are only cases where one might be easier to code with.Your last example can be made with the current current hour block, and can only be made with it unless the user gives their timezone.
The days since 2000 block uses UTC and thus one single timezone, so you can use that to calculate the time in say, UTC-4 and UTC+1.(((days since 2000) - ([floor v] of (days since 2000))) * (24))is the hour in UTC, plus the percentage of that hour. Adding or subtracting from this number and then taking the floor of it will give the hour in that time zone.
Unfortunately, that will not work for multiplayer games with daylight cycles since a user can lie about their timezone and have the incorrect costumes which may lead to cheating if a game has “night” being darker and therefore the correct users will have trouble seeing.
2 more blocks?Determining weather a workaround is acceptable or not is not done solely based on how many blocks it uses. You must consider the ease to create a workaround or find one online, the effect on the amount of variables, lists, and custom blocks in a project, and the specific formats that it will be used in (for example, a block workaround can be put in a custom block, but a reporter workaround cannot be referenced within multiple layers of reporters). If your reasoning for determining the value of a workaround is based on the block amount, then many of the existing blocks would be removed, and many new blocks would be added. But in reality, there are more factors taken to account than I can list. have you seen the amount of suggestions with a workaround? and they get a lot more complex, can you really not handle
this Scratcher has made some of these.It looks like you're talking about their sets of projects with animated thumbnails that connect. They probably take 1 gif file and crop it to create 5 separate gifs. Then they use custom JS code to upload these files as the thumbnails for 5 different projects, and share them all in order, so that the 5 cropped portions appear in the arrangement that they originally did.
I wouldn't say it really exists, because they added it then removed it, so the only reason it still can be used is to not break old projects. If it was a feature that was still supposed to exist, it would appear in the block menu. There is a block for this.
The for in you can find it around a lot of “hacked projects”
It will report the last valid value it was set to, not 0 (unless the last valid value it was set to was 0)Yes, but if you do that it will report “0”Yes but you could also write Yes, just doset [Cloud Var v] to set [☁ score] to [abc]And cloud variables don't store letters.
As the topic creator said, this is a duplicate suggestion, so post your ideas on the correct topic that they link to. I support. How would a new scratcher figure out that you could put numbers in the dropdown?
It duplicates the project, but it's no longer actually creating a remix.yes, go inside the project, click file and then click save as copyIs there a one account method? go to your alt account, then open another tab signed into your main account, remix the project on the alt account and you remixed yourself
You don't actually need to look at the reason every time. If you can see why just from reading the comment, then there is no need to read the reason. The reason is just an additional detail to help in the case where a report is unclear. It also allows you to categorize reports and view them in order of priority, which I think can help speed up the process for more important reports. I say this every time this suggestion comes up: the reason that we don't have you input a reason for reporting a comment is because comments are so short that we are able to tell what's wrong with it, if anything.
That's not to say it's rejected, however. I think it could be helpful, although potentially cumbersome if you have to report multiple comments really quickly.
I actually just re-read your suggestion, and it seems like you're suggesting a checkbox system rather than typing out the reason. That's a pretty cool idea, I think. I disagree that would make things faster, though — because then we have to look at the reason in addition to the comment. But that doesn't really waste much time in hindsight, anyway.
The suggestions forum does get seen by the ST, so isn't this already the best way to show them? Lets show this forum to the st
That works, as long as it doesn't allow any events in unloaded sprites to be set off, and not being allowed to use things like touching sprite, go to sprite, point towards sprite, because all those sprites wouldn't be loaded. It would also need to have the backdrops loaded, or make the backdrop just be blank. Layering also interacts with other sprites, so the layering might need to be loaded. The values in variables and lists would need to be loaded, or else make the specific sprite not be able to access them. And it would still have to be very limited in space because of how many projects will get loaded. It's a lot of things to address but it's possible. It just doesn't seem like you would really be able to do too much with it after seeing how limited the space is. But what about it only works in one sprite. That sprite can have no code but the before green flag clicked block. Then all the code beneath it. It would sence which sprite has that code and only disable that.
<not < < >>
<not < > >>
<not < = >>
You didn't understand my question. How can it tell the difference between things that it has to load for the before green flag clicked block and things that it has to load for the actual project? It is virtually impossible to automatically detect the scripts and assets that need to load, and which ones don't. This means the only way is having to load the entire project, which will take a long time and use a lot of resources.If it gives you a warning though it will be like this. “Before green flag clicked blah blah blah SCRATCH: ‘Uh oh! It looks like you have used to much space and it will take too long to load! Try making the code shorter!’” Then you know when you added too much code to the before green flag clicked block.But how would it know which parts of the project need to be loaded for the thumbnail? It seems like it would have to load all of the project, and that would have to take a while. Hmm…. I never thought about that…. It would make it so there is no thumbnail at all! It would just be loading! Well… I guess… Maybe they can make a limit on how long the song is and how big the animation is so you can only need to wait like 5 seconds or less!
But how would it know which parts of the project need to be loaded for the thumbnail? It seems like it would have to load all of the project, and that would have to take a while. Hmm…. I never thought about that…. It would make it so there is no thumbnail at all! It would just be loading! Well… I guess… Maybe they can make a limit on how long the song is and how big the animation is so you can only need to wait like 5 seconds or less!
Maybe the numbers are converted to letters? 5 to 6 letters is easier to remember than 8 to 9 digits. The only problem is certain words appearing by chance. And how will this help, exactly? The only bit in the link, in my opinion, that's annoying to type are the Numbers. People are better off copy/pasting anyway, because remembering the numbers is virtually impossible. In which case, shortening the link makes no difference whatsoever. No support.