Object Name Change in Expressions

0 favourites
  • 8 posts
From the Asset Store
Simplistic hyper-casual game with nature elements. Tap to switch between the 4 elements and reach a better score.
  • Hey,

    the Object Names dont Auto-Rename in Expressions.

    <img src="http://85.214.39.20/shared/nameBug.JPG" border="0" />

  • I don't understand. Everything is named "Goodie" in that picture. What were you expecting to happen instead?

  • I think he is bothered by the lower case of the name.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • In Construct Classic, expressions will stay in the case you type it, so if you enter GoOdIe, it will stay that way. I guess C2 has this as well...

    Edit: Oops, looks like this has been changed, entering object names in expressions works properly for CC.

  • Yes, I intended that C2 leaves expressions how you typed them, and only changes it if the object name changes to a different string (not the same string differing only by case). Do you think I should change this?

  • Yes, I intended that C2 leaves expressions how you typed them, and only changes it if the object name changes to a different string (not the same string differing only by case). Do you think I should change this?

    Since C2 allows searching of an event list then it'd probably be helpful. Then they can find different expressions depending on certain cases (eg: Player, PLayer, one is the player object, the other is the layer the player is spawned on).

  • Would that really be useful? It seems to me a case insensitive search is more useful so you don't have to worry about whether you typed "Player" or "player", and naming collisions like that shouldn't be too common. I would prefer to leave it as is.

  • Agreed about the case insensitive search.

    Concerning the casing in expressions, at first I was a little surprised that expressions wouldn't change automaticly the case of variables or object names.

    When eye-scanning the code, it is easier to pair objects and variables through lines if they all use the same casing (the one of their definition).

    It's not a big deal though, as long as the expression works and pick the right object/var.

    Jayjay your example probably works for seasoned developpers who take naturaly into account that Player is not PLayer. It is less user friendly though when you have to look for hours in your code trying to find out why there is an error and that the player object is affected instead of the layer.

    "OH myyyyyyyyy I just made a typo and haven't seen it before."

    This happens often ^^

    Insensitive casing prevents that case.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)