delgado,
You can use the formula current width/image width to get an objects scale...therefore, what you'd need to do is:
every tick:
IF (Sprite.Width/Sprite.ImageWidth))>1 THEN set scale to? max((Sprite.Width/Sprite.ImageWidth)-0.1,1)?
This scales the object back down to a scale of 1...the ?max? part makes sure it can't scale smaller than 1 (100 percent scale)
Pixel perfick,
To clarify my points: (caps are for emphasis and not intended as rudeness or yelling.)
1) If you can set width, it stands to reason you can retrieve width..and you can. If you can set height, it stands to reason you can retrieve height...and you can. If you can set opacity, it stands to reason you can retrieve opacity...and you can. This is why retrieving scale seems missing...because you CAN set object scale but can NOT retrieve object scale (without jumping through a hoop and figuring out the formula I gave delgado above...or wasting time and variables to keep track of every sprites scale). My suggestion (?retrieve objects x scale? and ?retrieve objects y scale?) resolves this issue perfectly, in the manner that any user would expect...there would be zero confusion.
2) ?Retrieve object X scale? and ?Retrieve object Y scale? would NOT be 2 conditions for the same thing, it would be two conditions for two separate things, which happen to be interchangeable IF the object's X and Y scale are always identical, which IS THE CASE if the user only uses the already existing feature to SET OBJECT SCALE...which many people do, and which is WHY this keeps coming up.
3) The fact that ?it can already be done in events? has NOTHING to do with whether or not there should be a built in feature, or whether or not it seems missing based on all the other features that DO EXIST. (please realize all of the things mentioned in point 1 could be done with events, as could 90 percent or so of all the other built in features of C2)..do you concede therefore that this was a moot point?
4) People simply want to be able to check the scale of their objects (independently of each other and having NOTHING to do with the layer any given sprite might be on) relative to the original size of that objects images and relative to the action SET OBJECT SCALE which their game is using. This has nothing to do with the layer the object is on..at least not in any way remotely related to what people are asking for.
5) The layer sprites are on have a LOT to do with z-order, because if a sprite is on a back layer, it can never go over anything on a front layer and vice versa. This means, if you're using one or more layer specifically to control or retrieve the scale of certain sprites, then those Sprites in question are slaves to the z-order of the layer, relative to other layers and other sprites on different layers. This might impose a massive limit in Z-order control to the person making the game, as well as just being needlessly confusing.
6) Using layers to control or retrieve the scale of sprites (especially if you have countless sprites all scaling separately, as different rates, all at once, which is highly likely) is inherently convoluted because you are using one completely different thing to control or retrieve information for another thing. This is practically the definition of ?convoluted?.
I must say I AM confused about your suggestion of using layers In order to help end my confusion, could you please make an example file that achieves delgado's goal using the method you suggested in your one sentence solution. ?Place sprites you want to scale on a single layer, there is a compare layer scale condition..............?
Lets say there are 10 sprites, all which have been set to separate random scales using the set scale action...please show me how to check their current scales using this layer method you speak of.
Thanks,
Mike