Bug across object/actor copies

TryangleTryangle Member Posts: 37
I just observed a bug that caused a serious issue in my game.

To give context, what I did originally was I created a "universal" object/actor, and placed within it general properties that may or may not be used across objects/actors that I would make out of that universal one. The purpose of this, was to limit the amount of work that would go into creating unique actors, as I would simply remove properties and logics that were not needed instead of completely reworking them where multiple actors would share groups of logics and those logics referenced self attributes.

The bug is this: I have these objects/actors with self attributes that logics refer to to grab data from a table, based on a change in a global attribute. However, when I remove a self attribute from a copy of the universal, it removes the table reference from all the logic of all the other actors who are a copy of that universal object/actor and make reference to the same self attribute i their own objects. As you can imagine, removing a single one of the original self attributes from a copy breaks the logic in all copies of the universal actor as well, which is pretty much all of the objects in my game.

This is a major bug, because it means that if a person makes copies of an object/actor, and makes a change to the self attribute of that actor, it breaks other actors that are not directly related but came from the same original actor for which copies were made.

Comments

  • slowcutslowcut Member, PRO Posts: 164
    In the GS version that I use, it is only possible to delete self.attributes from a prototype.
    And doing this it will of course also delete the attribute from all copies in the scene.
    I do not know how you copy your universal actor, dragging it to the scene does not produce independent copies from the prototype. The resulting actors will still refer to the prototype.

    If you wanna create editable duplicates of your universal actor, you should copy it in the inspector window (hold the alt key and drag it).
    This copy could be altered without effects to the original

    Everytime you are able to delete an self attribute you can be sure that you are editing a prototype, and this will always effect all refering copies.

    I would not call this a bug, that is the way GS works
  • TryangleTryangle Member Posts: 37
    No, you misunderstand. This bug occurs with prototype objects, not with unlocked unique versions in a scene. Copying a prototype as a new prototype, and then removing a self attribute has the effect of changing the same self attribute on all other copies that are prototypes derivative of the original prototype.

    Example: Actor A. I make two copies of Actor A, copy 1 and copy 2. If I remove a self attribute from copy 1, it removes all references in the logic from copy 2. This cannot possibly be a feature, as copy 1 and copy 2 have no direct relationship other than being derivative of Actor A.
  • TryangleTryangle Member Posts: 37
    I should add that the self attribute from other copies stays, but all references in the logic to that self attribute are changed to 0 values.
  • tatiangtatiang Member, Sous Chef, PRO, Senior Sous-Chef Posts: 11,949
    I hate to argue but this is not so much a "bug" as a design choice. @slowcut explained it well above. Prototype attributes are available to their instances but each instance doesn't have a separate xml entry for its own self attribute. That's the best way I can explain it but I'm not sure it's very clear.

    So in practice, if you create a self attribute for an actor prototype, it creates it for all future (and present?) instances of the actor and if you delete it from the prototype, it deletes it from all instances.

    New to GameSalad? (FAQs)   |   Tutorials   |   Templates   |   Greenleaf Games   |   Educator & Certified GameSalad User

  • TryangleTryangle Member Posts: 37
    I'm not talking about instances, I'm talking about top level prototypes. If I click the plus button and make a new actor and then copy and paste on the top level, the actor acts in every way that it's self attribute is its own. But if I delete the self attribute from a copy, the other copies on the top level still have the self attribute visually but it breaks the logic and I have to reattach the self attribute to logic in each actor. If it's intentional, then why would all the other actors remove the attribute references but yet keep a self attribute in its self attribute list, and the self attribute remain functional upon reattachment?

    It's like if I made a copy of a photoshop file with 5 layers and by deleting a layer from one copy it automatically deletes everything in the layer on all the other copies but leaves the layer. In what circumstance would this "design choice" ever serve a useful function other than make it impossible to remove a self attribute from a copy without breaking all the other copies of a top level actor prototype? Can you or anyone explain how this serve a useful purpose?

    Are we talking about the same thing? Are you saying prototypes are instances?
  • TryangleTryangle Member Posts: 37
    Btw, I'm not interpreting you as argumentative, I'm just not sure we are talking about the same thing. I am not talking about actors in scenes, I'm talking about top level prototypes. This happens without my ever even using an actor in a scene. I am saying that a copied and pasted prototype on the top level actor window acts like an instance even though it's a prototype. But it's not an instance, it's a prototype. If it's an instance, there is no indication that it is, nor any documentation specifying that copy and pasted prototypes on the top level are instances.
  • tatiangtatiang Member, Sous Chef, PRO, Senior Sous-Chef Posts: 11,949
    Okay, I did misunderstand after all. I see that you never mentioned instances and that I just assumed that.

    If you create an actor in the inspector and then copy and paste or option-drag it to duplicate it, the duplicate actor that is created should not share any self attributes with the original. If this is happening without placing any actors on the scene then I would suggest you submit this in a bug report. It is not the expected behavior.

    New to GameSalad? (FAQs)   |   Tutorials   |   Templates   |   Greenleaf Games   |   Educator & Certified GameSalad User

  • tatiangtatiang Member, Sous Chef, PRO, Senior Sous-Chef Posts: 11,949
    Here's a screencast of how it works for me. There is no audio.

    New to GameSalad? (FAQs)   |   Tutorials   |   Templates   |   Greenleaf Games   |   Educator & Certified GameSalad User

  • BBEnkBBEnk Member Posts: 1,764
    edited January 2014
    are you talking about this bug I made video of and reported in 10.4 and nightly builds.

  • SocksSocks London, UK.Member Posts: 12,822
    edited January 2014
    @tatiang
    Here's a screencast of how it works for me. There is no audio.
    That's not quite what he means - he is saying this:

    1) Create a new actor (actor A).

    2) Add an attribute, let's call it 'Death'

    3) Give actor A a rule that references the 'Death' attribute.

    4) Now make a copy of actor A (within the Actors window), let's call it actor B.

    5) Now delete the 'Death' attribute in actor B.

    6) Now go back to actor A and whilst the 'Death' attribute is still in place (as shown in your video) the reference to this attribute in actor A's rule is broken !


    Hope that makes sense !

  • SocksSocks London, UK.Member Posts: 12,822
    edited January 2014
    Example:


  • JSprojectJSproject Member Posts: 730
    edited January 2014
    What Tryangle describes is a real bug, I have experienced it myself. I sent in a bug report of it over a year ago but never received any feedback and the bug is still there. Although quite disturbing, knowing of its existence is half the battle...

    @Tryangle, strip down a project that demonstrates the issue, upload it to e.g. dropbox and submit a bug report with a link to the project.
  • TryangleTryangle Member Posts: 37
    @Socks: That is it exactly.

    @JSproject: Yes, knowing of it is half the battle, but it raises a red flag about GS because this bug can break projects.

    @BBEnk: I like how at the end of your vid, all the YouTube vid squares that displayed in the window were how to get rid of bed bugs. Maybe if I pour rubbing alcohol in the heat vent atop my iMac, it will fix the problem.

    @tatiang: It makes complete sense you would think it was what you thought, because it reads very similar to how instances work as a feature.
  • TryangleTryangle Member Posts: 37
    edited January 2014
    I would like to also add for anyone effected by this now and in the future, that one can delete the original actor for which copies were made or any copy or copy of copy, without breaking the self attributes of all the other actors. Only deleting a self attribute that is in the actor and inherited by the copies, causes breakage in other actors.
  • tatiangtatiang Member, Sous Chef, PRO, Senior Sous-Chef Posts: 11,949
    @Socks got it. Thanks.

    You're tempting fate by naming your attribute Death but I'll assume the bug also occurs for Love and other attribute names. =P

    Well that's even worse than the instance attribute bug. Definitely submit a bug report on this even if it's been submitted before.

    New to GameSalad? (FAQs)   |   Tutorials   |   Templates   |   Greenleaf Games   |   Educator & Certified GameSalad User

  • BBEnkBBEnk Member Posts: 1,764


    @BBEnk: I like how at the end of your vid, all the YouTube vid squares that displayed in the window were how to get rid of bed bugs. Maybe if I pour rubbing alcohol in the heat vent atop my iMac, it will fix the problem.
    Perfect for Gamesalad these days,lol..

Sign In or Register to comment.