ramones

Yeah I think you're right. I have a feeling it has to do with the fact that using Set Mirrored just makes the Width a negative value.

Interestingly, I just tested Set Width = -self.Width instead of using Set Mirror, and it has the same problem, has to be done after the scale.

TELLES0808: Not sure what you mean by that, modulo division isn't really suitable in this case. Taking the absolute value works fine.

Ashley: I understand your reasoning, I'm just worried that behaviors, plugins, even collision detection that rely on Sprite.Width/Sprite.Height might suddenly exhibit erratic behavior if the Width/Height could return negative values.

This bug that I just found concerning mirroring/scaling might be related:

Mirroring Scaled Images fails

Do you think I should just create separate animations for mirror/flipped images instead of using mirror/flip?

Specs:

Construct 2 64-bit r103.2

Windows 7 64-bit

Intel Celeron

When a sprite is scaled, mirroring the sprite seems to fail.

Bug capx:

Mirror Bug capx

Ashley

Hmmm, I'm not sure I agree with this. Width should by definition always be a positive value. Mirroring an image on a 2d plane should have no effect on the actual value. I understand that internally, mirroring may invert the width, but as a property value, width should return the measurement of an object from side to side. It's especially confusing considering that sprite rotation has no effect on the width value.

Since I can't rely on width to return a positive value for any given sprite anymore, and most of the sprite's in my game's visual state is indeterminant, it just means I have to wrap all my Width and Height calls in Math.abs statements.

I can't imagine a situation in a game where you would want to get a negative value for the width of a sprite. I guess you could argue that it lets you tell if a sprite has been flipped/mirrored, but there is already explicit conditional logic in place to check for that.

I spent almost 30 minutes trying to debug a subtle issue that when I finally managed to track it down, it was because width was negative.

Description:

Attempting to Disable an effect in the On Created trigger throws the following javascript error:

TypeError: inst.type.active_effect_types[0] is undefined

localhost/layout.js, line

Specs:

Windows 7 64-bit

Construct 2 r102 64-bit

Intel Celeron

Example:

Enable Effect Javascript Sample Capx

Specs:

Construct 2 r102

Windows 7 64-bit

Intel Celeron

Bug:

When a sprite is mirrored, the width is returned as a negative value. I don't think this is expected behavior.

Example:

Negative Width Capx Sample

sqiddster:

I think what alspal is referring to is the fact that when you select a sprite from the Projects list or Objects list, it automatically selects all instances of that sprite on the currently active layout. At this point, changing any values on the left-hand Properties bar affects all of them. NOTE: This will only affect the currently active layout's instances of that sprite.

Well, Construct 2 will probably not require you to drop a instance of every sprite into a layout in some future edition. However, we really need the ability to set default values for a sprite's properties.

Example:

Create Sprite1 (don't drag to layout)

Edit Sprite1's config to be Config1 (these should NOW be the default values whenever Sprite1 is dragged into a layout)

Drop Sprite1 in 10 different locations.

Drop Sprite1 another time. Edit this Sprite1's config to be slightly different, Config2.

Continue dragging more Sprite1 instances into the layout. (They *should* still have the default Config1)

The reason I say that is because, for all intents and purposes, the required first instance of the sprite is essentially the default one.

I think that's the logical way to do it. For now, I suppose you could just drop Sprite1 set its config, and copy and paste it to insure you get the same config values.

I am aware that the current implementation of Construct 2 requires at least one instance of very sprite before the game starts. I usually create a dummy DefaultLayout which is not used that contains all the default instances.

I created a sprite with Physics behavior and set its Collision Mask to circle on the first instance of it. I then went to another layout and dragged a new copy of the Sprite, however, it's Collision Mask was reset to "Use Collision Polygon". Shouldn't it have the config variables that I've setup initially? Those are considered the default values for every additional instance, right?

Somehow I seem to recall this being a bug several version back sub v90, but I'm using v102 right now.

Seems like keyboard support is definitely getting better. I'd still like to suggest some additional ones to avoid have to flip back and forth from mouse to keyboard and vice versa.

1. Create new event sheet shortcut

2. On creation of new blank event sheet, none of the standard keyboard shortcuts work except for 'N' (Include an event sheet) and 'V' (add global variable). It's a little odd.

3. On Layout view being able to tab over any objects in the scene, and a shortcut to access(put active focus) on their properties menu. I would personally suggest that this work similarly to how Visual Studio does it.

Thanks,

-- cacotigon

I'm sure there's a subtle message that I'm missing here. Also hanging from one's chin has to be fairly uncomfortable.

Any advice? Plus with the addition of family behaviors and variables, I honestly can't think of a compelling reason to use an invisible shell sprite anymore as per the manual recommendation.

http://www.scirra.com/manual/100/platform

Mario typing and Typing of the dead were a heck of a lot more fun than Mavis Beacon! <img src="smileys/smiley1.gif" border="0" align="middle" />