What other Global things do I consider to prevent sprites appearing from one layout to the next?

Post reply
0 favourites
  • 5 posts
From the Asset Store
Globals 2.0
$3.99 USD
Globals 2.0 stores and group variables. You can also load and save data (variables) from/to JSON files.
ForConstruct's avatar
ForConstruct

  • I have a project with the following layouts:

    Start_Screen - start screen of the game

    Game_Layout - where all the game action takes place

    Camp_Layout - after game layout to purchase items, etc.

    Object_bank - layout where all the sprites are initialized (so that i don't have to put them on the other individual layouts). This layout is never actually used in the game.

    Each layout has one event sheet, the layouts share many global variables, and use many of the same sprite objects, of which many are in families. Each event sheet targets the correct layout in the 'properties' section, and the Start_Screen is targeted as the first layout.

    The issue is when I have an event that you click on something and call the "Go To Layout" action (e.g. from Start_Screen to Game_Layout), the project goes to the next layer, but the objects from the previous layout show up.

    I have looked at the forums, and just brainstorming what other things besides Global Layers (i have unchecked all the "global" options) should I consider to prevent layer "bleed-through" of objects showing up on layouts I don't want them to.

    Could the object_bank, which each Layout pulls from, be the problem? Could shared Global Variables be a problem? Could similarly named layers, layout-to-layout, be a problem? Thanks.

  • It's either a global object or global layer. Because you said 'unchecked' then that will be the individual object most likely because the global option is a checkbox. Likely it is the layer set to global=yes. Select the layer that the objects appear on and look at properties, is it set to global=yes? Probably check it in the object bank layout.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I found out the issue...but it is still bizarre.

    Events on one event sheet that "create sprite on layer 9" also create the sprites on the next layout after the GotoNextLayout event happens. Essentially the layout is being subjected to events from an event sheet not even associated/included to it.

    I solved this by using strings to identify the layers rather than relying on numbers (which can be universal across MANY layouts).

    I am not sure why the sprites are still created - but if you test this is a simple project with two layouts each with an event sheet, creating objects for each other picking each other's layers, the project is quickly broken (no sprites are created). Which you would expect since the layers on not recognized.

    With regard to create sprites on layers, i think construct should have more "bumper lanes" to prevent users from picking layers (i.e. the layers of another layout, not associated with the current layout) that will harm their project.

  • What you are describing with the test file as broken is expected behaviour. What you described in the first paragraph is impossible so the event sheet must be linked to the layout in some way.

  • Touche'. The issue was actually an event sheet (used for sounds) called "sound events" that was shared between all the other event sheets; the other event sheets included the sound sheet and the sound sheet included the other event sheets, thus building a "bridge" or many-to-many relationship between the event sheets and their layouts. Thus "on start of layout" events from the event sheets applied to all each other's layouts.

    While renaming layers and accurately naming them helped things... it didn't solve the above issue. I will remember this for future project designs!

    Many thanks, mk

Post reply
  • 5 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)