How do I set the center of a sprite through blocks, or at least in JS?

The context is that I want to make a tower defense game because the tower defense games on scratch were very fun, and scratch's high ceiling was too low for me so when I heard of Snap! I started developing it here. Things are going so well so far. When I first heard of Scratch, I could not utilize the new features as much as before, so I have been restarting and learning from my mistakes many times.

The issue I am having is that I don't know how to set the center of a costume. I have two scenes, one for the game and the second one which I will make the menu. Some data like the maps (I will be calling the track that the enemy treks "maps") and towers is taken from the menu, because I want to allow the user to choose what map and towers, they get before they start the game.

All of the towers are centered Snap!'s poorly predetermined pivot because the three blocks I use to decode costumes into lists so they can be sent through scenes don't provide a method to set the center of the costume. I know they allow you to understand what the costume's center is, but that's it. I want to confirm that everything else about the towers work fine; I just am having an issue with the appearance.

That is what I request. I want to know how to set the center of a costume. The project is here. I have a very low standard for the quality of the solution, I don't expect you to make an entirely new integral block that goes straight into the editor as I am aware of how minuscule the team of developers for Snap! is, I just want to know. It can be in JavaScript, I don't care.

Also, the towers only look inane right now because I these designs are not final.

You can in fact set the pivot of a costume, or really the sprite. If you take the set variable block, go into the variable menu, then under the my submenu, select rotation center x / y. This will allow you to set the rotation center of the sprite. Keep in mind the position you set is not relative to the sprite, but instead a point on the stage. You can make it relative by using the my block, which has options for my left, right, top, bottom and center x / y, which are taken from the costume instead of the pivot position.

Show me an example of you using this technique please.

I can't do it right now, but you can play around with it. You can even check the pivot by right clicking the sprite on the stage and selecting pivot. I'm sure you'll find this useful. (Also, the script I showed at the end of my post is pretty much all you have to do)

That actually isn't it. Do you know how I can set the center of a specific costume in the editor? That is what I am trying to manipulate. I am not trying to change the pivot of the sprite; I only used the word because it was a synonym of "center". Doing what you said only made the issue worse. I don't want the head of the turret to completely detach from the base; I want the square to be in the center.

You can't change the center of the costume in the editor. The only way is to change the pivot of the sprite. You should alo design your game to not rely on costumes having different centers, but instead have the sprite itself have the different center.

Good idea! I figured out how much I need to offset the sprite's center while tinkering with the script, but the condition is universal and every clone's pivot changes when one clone's pivot does. Making an individual sprite for each tower is incredibly fatuous and won't work.

One technique that might work for you is to create your all your costumes the same size with extra whitespace around them and then just make sure that you create the required costume image with your visual centre at the sprite centre within those bounds

It didn't work. I'll just put the costumes in the game too so I don't have to deal with this.

If you want something like Scratch, but without the limitations, you might consider using Turbowarp.org or Turbowarp Desktop (https://desktop.turbowarp.org)


Something I made using it.
You can set it to disable clone limits and stage boundaries, and also add extensions that change things such as stage size or sprite width, making it nearly equivalent to Snap!
It has everything Scratch has, plus much more.

I already know about Turbowarp and its extensions. It just refused to save my project because it was more than 10 MB due to me adding a second map so I should consider this.

But the problem is that I already finished almost everything a regular tower defense game has using Snap!, and Turbowarp doesn't have first class sprites so I can't just switch like that. Maybe if you thought about it before using this problem as an excuse to advertise Turbowarp then I would've been more interested. I have seen the potential of Snap!, and I played my game until wave 40, and it was pretty fun.

I am not trying to be too gruff, but every claim is backed up with evidence and a reason. The evidence supports the claim, and the reason links the evidence and claim together. Subclaims are pieces of evidence that need their own evidence, but that isn't relevant here.

Maybe if you could be a little more critical and ANALYZE the problem, me not being able to set the center of a costume, then I would happily switch. You don't properly elucidate what makes Turbowarp better in this situation by excluding a reason. You just throw in an inane, improper, unfinished, claim out of impulsiveness.

But this won't mean anything if you don't learn what you could do better next time. You did not provide a reason (what links the evidence to the claim) when you stated that I should switch to Turbowarp, the evidence being that Turbowarp has no limitations, but you never told me how that makes Turbowarp better. Who cares if Turbowarp has no limitations if Snap! has no limitations either?

And what bothers me is the fact that projects made in Turbowarp cannot be added to scratch, only packaged. Where will I show these packaged projects? Do I need to create my own website?

Now, let's get to the point. I want you to tell me the reason, what makes the fact that Turbowarp's lack of limitations matter. Please explain that for me.

What I am saying is that if Scratch has what you need rotation-wise and TurboWarp also gives almost everything that Snap! has, and most likely all that you'd need, then it would be useful for this. But I see what you mean. If you already have this all in Snap!, it would not be practical to copy it over. I was just giving a suggestion. Maybe create what you need in Scratch, download the file, then convert it using https://snapinator.github.io. Then you would see what you needed converted to Snap! language so you could use it.

Also in Scratch the rotation is the center of the sprite costume. I would assume that in snap the basic turtle sprite costume has the nose at the center. I'll go check.

Sorry if I am unhelpful. If I am, just delete my comments and forget I exist.

I want you to learn from this, so you don't make the same mistakes. You have some good points now, so I can see you already improved. But Snap! Is different. Instead of putting the costume at the center, you put the center at the costume. It makes it seem like you barely used the editor when you act like this. Also, you can't precisely set the position of the Turtle's center, you can only choose for it to be in the middle or at the tip.

I admit there are sometimes where removing posts is necesary, like if instead of you trying to show me better visual programming languages, you straight up insult me and call me dumb for not being capable of solving the problem myself. That is something that really does insult me but what you said is different.

The reason why I did not remove your comment is something that makes a lot of sense when you think about it, so allow me to explicate. Do you know how there is the type of person to respond to any type of argument with "did I ask" or "who asked"? It's like removing your comment. If you take the time to analyze it, then it turns out to be something that benefits you rather than damages you.

Removing comments is very hypocritical for me because then I don't know what you are trying to expound. It's like your teacher tries to teach you basic math so you block your ears every time and then you end up not learning it, so then your only choice is doing the same thing for the rest of your year in school. My point is that if I actually listen to you then maybe I can think about it and improve myself. I never said you were stupid or something because your post was implausible.

Replying to your reasoning, Snap! actually runs slower than Scratch because it has to handle all the new features that put it above Scratch, and is only worked on by one person, Jens. He said this himself before. Scratch is very impractical for novice programmers so when you think about it, Turbowarp adding plenty of new features, compared with the fact that it runs faster, makes it useful.

But I still need to know how I will share my project if I develop it in Turbowarp. How will people trust me if I just give a .exe file and tell them to open it. The .zip and plain HTML5 formats can only be used in websites, meaning I'll have to use something like neocities where you can make a subdomain of the site with HTML, CSS, and JS.

https://snapinator.github.io

Hello? Did you hear me? I already explained that Snap! runs slower than Scratch because it has more features and has a smaller developer team. Jens said this himself.

Yes, I have noticed that. When opening a Scratch project (https://scratch.mit.edu/projects/782916237/) of mine with snapinator, it was way slower. Thanks for critiquing my help attempts XD.

I should still switch to Turbowarp though. Your other points were good, I took a look at the extensions and it is amazing.

Yeah. You can't change the window size or the shown controls using Snap! 9.

Bye! I will work on another tower defense game but in Turbowarp this time. If you have anything else to say then say it.

I made it give you a notification then start shrinking and growing so you couldn't stop the project.