I was thinking of using constants... probably tied to a global object... I sort of tend to avoid global variables, it doesn't work with me or how I work doesn't play well with them... you know what I mean?

I guess it's a missing feature. But because you can use any dynamic expression, it can't guarantee that 100% of references will be updated. For example if you reference

"Layer" & Sprite.LayerNumber

then rename "Layer0" to "Main0", it can't update the reference to "Layer" there.

Oh, I didn't even think to a dynamic expression like that!

Hey everyone,

I was curious if you can turn off autopolygon when importing sprites. I figured if it existed I must have overlooked it.

Nothing is more annoying than spending an hour our so turning automade polygons into boxes everytime you import a bazilion sprites. Its a neat feature, in theory, but honesty has anybody simply trusted c2 to make the polygon and left it at that? At the very least you have usually majorly tweak it. Eitherway, I want to turn it off.

You can use the layer name in expressions instead of the index. So something like LayerOpacity("Layer 1") would work. You can also do the same thing with imagepoints, either use an index or the name.

Right, But then those references are prone to being broken if you change the name right? They also don't auto complete unless I am mistaken. I'm not saying its an un winnable situation, just slightly sub optimal. I never notice it until I get into heavy layer usage, which typically I try to keep to a minimum and in locations I can easily change later if I have to reorganize.

So I was curious, why are different ways for storing names in construct 2 used?

Variables can be named and referred to by that name. You can change the name and the change is reflected across the project.

Layouts are the same - you can only reference them by name and changing the name changes the project references to that layout.

But groups, function names, and layer names... When referencing these things you get a handy autofill (which didn't used to exist for some things) but nonetheless, if you change anything about these guys it will not change your original references to them... you'll have to go through the project and make sure the changes are reflected when you call them.

Its no big deal... I think coming up with group and function names and sticking to those names is a simple organizational exercise with a smidgen of foresight... But layers are hard to name and keep in the same order for the duration of the project. I always find myself realizing that I would like an extra layer inbetween these other layers, or something.

Since you can refer to layers by name, it doesn't matter for actions, but expressions refer to the layer by number! One could set up a system of constants and just refer to the constant, but that seems like the sort of thing construct should already be handling. Its a pain to be half way through a project and realize you need to completely re arrange layers to support some fancy blending mode you realized you couldn't live without. Then you have to go back and manually change all layer expressions

Am I missing something?

Ya you are right, I realized when looking at the change angle that it only changes the angle if it is different. You might try getting Ashley to weigh in on the conversation. There have been a few times when I wanted to do something but didn't know if I was overlooking something or if it was part of the blackbox portion of c2 we can't touch.

Either way, he might add it to an update if it is something simple. One workaround you might try is simply to add an offset vector and store it to the sprite. you could then use that offset to artificially change its position for visual appearance or use it in collision detection as overlapping offset. I know it doesn't actually address the problem though.... Personally I hate workarounds even if they did work perfectly, lol but here I am offering a "why don't you do this instead" type comment...

It is a bit of a conundrum.

Well, you can strike my last comment. When an angle is changed, contruct 2 calls bbox changed after updating the angle. hmmm

Its cool you have gotten this far with it. For claiming to not know much code, you are well on your way. I am curious, I know its not ideal but can you set the angle of the sprite to itself.angle right after changing the polygon. You said that updates the polygon right? You could simply call it good if it works from there... I say this, but that solution would drive me up the wall...

So, what I think is, I imagine that internally contruct 2 only refreshes the polygon when it needs to. Basically, Lets say you have the polygons points stored in A. When construct 2 runs, it stores a new set of points in B. These are calculated based on the rotation and scale of the sprite. Calculating B takes a bit of work and there is no reason to perform that work every tick unless you have to. Changing an angle or scale would be a good reason to recalculate B. If you think about it, A is only useful for calculating B, where B is actually the real points of a collision polygon in the game world. Does this all make sense? Its the same reason you tell construct 2 to update the bbox. There is no reason to recalculate its position when it isn't changing. The same thing is true of the collision polygons points relative positions based on rotation.

I think if you look into the sprite you might find a clue in .SetAngle()... I am going to take a peek when I get a chance, but thats where I would start.

I am completely pulling this out of nowhere, just a hunch. But it would explain why

Any chance you could do a quick copy paste of the code? I can't download the files currently but I could look at the code if it were here. Thanks!

— - sorry about that, glad you figured it out. I typically comment all the things I change so I can find them again but I must have missed that!

— Colludium - One more thing, make sure you back up any project game file before trying this stuff out. If you add this and then take it out later, or be dumb like me you can find nefarious and subtle ways to corrupt a save file. This is true of adding and changing any behavior in a project. Mostly problems exist when you remove an action or property that a save file references.... and let me tell you, editing the construct 2 json file is not fun but is the only way to fix it if you have no backup.

Colludium you may find the above post showing how to enable prismatic joints useful. You might find a use for it that you can't live without