locohost's Forum Posts

  • Yes I am sending in a UID to re-pick in the function. I would not expect a function to see any external picks.

  • Also, nearly all of my "code" is in functions. Does this make a difference?

  • Ok, yes that does make sense. Thanks :-)

  • Ok newt, let make sure I follow you:

    You're saying if I pick an object, then pick same or any other object at same level this "breaks" picking. What does "break" mean specifically? Does "break" mean: Each pick at same level cancels (un-picks) any prior pick? So if I pick in subevents, I will not break the prior pick?

    So like...

    Pick ( SomeObjectA ) by-whatever

    ---- Pick ( SomeOtherObject ) by-whatever

    -------- Pick ( AThirdObject ) by-whatever

    ------------ In this pick subevent I will still have all 3 objects picked

    But if I do above like this...

    Pick ( SomeObjectA ) by-whatever

    Pick ( SomeOtherObject ) by-whatever

    Pick ( AThirdObject ) by-whatever

    ---- In this pick subevent I will have AThirdObject picked, but break/lose the first 2 objects picked?

    I'm assuming if you ever (regardless of same level or subevent) pick same object again, you lose the prior pick. Yes?

    Thank you for helping my friend! :-)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • When I pick an object, does this create a scope? Meaning, in order to correctly reference the picked object, do I have to put each referencing event/action as a sub-event of the pick? Or will any subsequent event (just following, not in a sub) have a correct reference to the prior picked object?

    Thank you for clarifying :-)

    Tagged:

  • Post subject describes the issue. Or am I doing something wrong?

    * I open any .c3p project from a local file

    * Do some edits

    * Click [ Ctrl ] + [ S ] and C3 tries to save to cloud storage.

    Why? Why doesn't C3 save project back to file I opened?

    Tagged:

  • AllanR

    Thank you again AllanR for the great ideas!

    I'm still exploring a couple ways to simulate objects that have complex properties. i.e. object properties and arrays of object properties. C3 Containers is soooooo damn close to what we really need for this. But it just won't serve in it's current implementation.

    Right now I'm working on implementing the Monster complex properties as simple UID pointers to external arrays. I've put together a suite of functions (that take a MonsterUID as first param) to create, get, set, add, etc. the Monster properties.

    This "functions/UID-pointers" approach is waaaaay more "code" than we really should be forced to build. C3 Containers needs some improvements or we need some way to store and retrieve complex data properties in objects.

    I will definitely investigate your excellent suggestions. Thanks again my friend! :-)

    Mark

  • See my second and fourth post.

    Do your second and fourth post say that the C3 editor is flawed so it disallows correct usage of Containers? If not, the Containers implementation is flawed. Regardless, thanks for the replies :-)

  • Or...

    Are the Containers designed exactly right (as I'm describing) and the flaw is in the C3 editor UI that doesn't allow me to create the Containers the way it should? So my workaround above gets past the editor bug?

  • I still feel this is Containers design flaw. I can work around this, by created uniquely named "templates" for each object I want in the container. The flaw is why do the exact same object templates, need unique names in the Containers?

    So now to do what I want with Containers I have to do this...

    Create sets of uniquely named object template sets (to make the Containers) like...

    sprMonsterBlu1 (container, this object)

    --- arrMonsterBlu1ActionChosen (container child)

    --- arrMonsterBlu1ActionSet (container child)

    --- arrMonsterBlu1GridsAdjacent (container child)

    sprMonsterBlu2 (container, this object)

    --- arrMonsterBlu2ActionChosen (container child)

    --- arrMonsterBlu2ActionSet (container child)

    --- arrMonsterBlu2GridsAdjacent (container child)

    sprMonsterBlu3 (container, this object)

    --- arrMonsterBlu3ActionChosen (container child)

    --- arrMonsterBlu3ActionSet (container child)

    --- arrMonsterBlu3GridsAdjacent (container child)

    sprMonsterRed1 (container, this object)

    --- arrMonsterRed1ActionChosen (container child)

    --- arrMonsterRed1ActionSet (container child)

    --- arrMonsterRed1GridsAdjacent (container child)

    sprMonsterRed2 (container, this object)

    --- arrMonsterRed2ActionChosen (container child)

    --- arrMonsterRed2ActionSet (container child)

    --- arrMonsterRed2GridsAdjacent (container child)

    sprMonsterRed3 (container, this object)

    --- arrMonsterRed3ActionChosen (container child)

    --- arrMonsterRed3ActionSet (container child)

    --- arrMonsterRed3GridsAdjacent (container child)

    These are the exact same object templates over and over and over and over with just unique name. Isn't this a Containers design flaw? Why can't Containers do this?...

    sprMonsterBlu3 (container, this object)

    --- arrActionChosen (container child)

    --- arrActionSet (container child)

    --- arrGridsAdjacent (container child)

    sprMonsterRed3 (container, this object)

    --- arrActionChosen (container child)

    --- arrActionSet (container child)

    --- arrGridsAdjacent (container child)

    sprMonsterGrn3 (container, this object)

    --- arrActionChosen (container child)

    --- arrActionSet (container child)

    --- arrGridsAdjacent (container child)

  • The "child" objects have to be unique objects to work in a container.

    Just add more objects to meet the requirements.

    Like you can't put a hat in a container and let them all share the hat.

    If they all have hats you have to add unique hat objects, even if its the same image.

    Ok I get what you're saying but we're not talking about "hats". We're talking about hat "templates" are we not?

    I need to create a sprMonsterBlu1 (its a sprite) and at same time create 3 Arrays that contain data specific to that one instance of sprMonsterBlu1.

    I think this is just something we can't do in C3. I want an instance that has complex instance vars. Not just int, string, bool instance vars. I want instance vars that are arrays of other objects specific to that parent object.

    I thought Containers was the tool I needed, but it seems not. It seems only way is to create "Monster" Family with: Monster.dataArrayA_UID, Monster.dataArrayB_UID, Monster.dataArrayC_UID, then I'm forced to 3, 4, 5 or more repeated picks over and over and over in many different functions to "assemble" my unique Monster instance. This will be a ton of repeated boilerplate.

  • Other than just replying "no your're wrong..." over and over, can you offer a way to do what I'm trying to do? Or am I not explaining my issue well enough? Thank you for trying to help. I definitely appreciate! :-)

  • You can't add containers to containers.

    There's a logic issue you have to consider.

    I'm not doing this.

    I want a Container that has (this object) as the monster sprite, then 3 other array objects in the Container. Follow? I can do this, but only once. See OP above :-)

  • Here is a small snapshot of my objects...

    Sprite "Monster" types. Each with unique image: sprMonsterBlu1, sprMonsterBlu2, sprMOnsterBlu3, sprMonsterRed1, sprMonsterRed2, sprMonsterRed3, and so on, ...

    Each monster above has a unique image.

    Each monster above is in the same "Monster" Family to share one set of all same instance vars.

    Each monster has 3 "child" or "related" or "partner" objects (1 unique UID of each) that I want to create/pick/destroy at exact same time I create/pick/destroy the unique monster UID.

  • The Container functionality you just described is exactly what I want. Now refer back to my OP. Thank you for helping me understand :-)