oosyrag's Forum Posts

  • I would expect this OR-condition to either pick all of the instances that are to the left of X=500, or pick all of the instances that are above Y=500. Even as we're talking about this, I struggle to think of what else it could logically do.

    You say it should be one or the other, so which would your actions apply to? It makes sense to me that sprites that meet either criteria would be picked for actions to happen.

    Based on this thread, it sounds like what would happen is that it would pick all of the sprite instances that are to the left of X=500, while un-picking all of the sprite instances that are above Y=500. Is that what is supposed to happen?

    If picking was reset between or conditions, that is what would happen. Which isn't what currently happens, but that was the provided example of what would happen if picking was reset.

    > You could file a suggestion, but based on the problems I've shown, I don't see a better way it could work unfortunately! Then there's also backwards compatibility: we can't just change how thousands of existing projects work...

    Would it be possible to add a true OR condition? Or would that require fundamentally changing the way things work.

  • We do have both ways now though, an or block doesn't reset picking, and an else-if does.

  • I haven't looked at the source yet but if the problem is that you don't know where to position your border because the position can be random/variable, then the solution is usually to save the randomized value in a variable so that it can be used for other things later.

  • Iirc example projects and templates are royalty free, but if you want to monetize a project and anticipate making more than a certain amount of money you'll need a business license for Construct 3.

  • What's wrong with looping?

    Without looping you would be able to insert breaks but they would not be taking word length or spaces into account.

    I'd approach this with len() too, but using len() isn't perfect though. Just counting characters does not guarantee that any given string will fit into a certain pixel width, since different characters take up different amounts of horizontal space. That's why rojo discusses measuring the text.

  • It looks like the moveto behavior's stop on solids property doesn't actually let the objects collide or overlap, it stops before they touch at all.

    You can use the stop moveto action on collision to stop instead of the stop on solids property if you want collision based events to fire.

  • + Sprite: On Pathfinding path found
+ System: Repeat Sprite.Pathfinding.NodeCount times
-> System: Create object Node on layer 0 at (Sprite.Pathfinding.NodeXAt(LoopIndex), Sprite.Pathfinding.NodeYAt(LoopIndex)), create hierarchy: False, template: ""

  • Is your text box large enough to contain the word? If the word doesn't fit, it doesn't get displayed at all instead of being cropped.

  • If it is changing animations when idle, you have some other events interfering. This may be related to your moving animation playing when idle. Try to isolate the issue by disabling all related events until you find out the cause.

  • Does idle left work? 0 degrees is usually to the right and 180 is left. Try disabling the angle conditions and see if it works.

  • Use a solid image instead of pieces? Looks like a pixel rounding issue.

  • I'm not absolutely sure about this one though - try it out with the built in sprite font and see if it makes a difference.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Have you tried with a sprite font instead of text? It may work better. From what I recall, the text object is particularly inefficient, such as when updating large amounts of text every tick. I assume transformations are the same.

  • You can use an instance variable, that contains the "type" or "state" of each instance of the sprite, which you can use to pick and apply specific events to. Then you would only need one sprite object.

  • If there are only fixed snap locations without other shapes or sizes, I would try using invisible helper sprites to snap to. You'll need two sets, one for triangles and one for squares, since the distance to the center of each is different. Set the helper sprite angle to the angle between itself and the object that created it (rounded).

    So placing a square would create 8 helper sprites, one for each square and triangle at each snap location. 6 helpers would be created for triangles. When placing a new shape, check only the correct helper type to snap to, and if it's close enough to snap then set the angle of the new shape based on the angle of the helper sprite it snapped to.

    Destroy any helpers that are already overlapping a shape.

    Edit: make sure your "connecting" flat edge is facing towards the right (0 degrees) for the triangle sprite