TheInstance's Recent Forum Activity

  • Point taken.

    And i agree, about the running into problems when having 100 "all sprites" running.

    Yes i can see that.

    But.

    You can not adress behaviours by pickin a family in the wizard.

    In other words,

    the tabs that represent the behaviours attached to an object,

    when pickin that object trough its family in the wizzard,

    dissapear when u adress that object in the wizzard trough its family.

    This made me run in more problems then those u point to.

    Yet i think its normal that the behaviour tabs dissapear when u adress the object via its family.

    Thats correct and logic.

    Stays the problem that Familys are not a full substitute to adress a group of objects in an action to do something with.

    On the other hand.

    If i understand the way construct is made a little.

    Somewhere in the code that makes up construct. You have a pointer that points to "the objects picked" by the events.

    Am i right by this ?

    So all u have to do is give that pointer an accesable state ? And let it show into the wizzard ?

    This pointer i think, is always there, is needed and essential for the working of the events.

    Just at this moment it is for me as "constructor" working behind the scenes and not acessable.

    Am i right by this ?

    Its there allready, make it accessable and nothing changed in the risk for running into problems ?

    At this moment it acts like. Picture this: You made a nice physics system. When the objects fall, they do this by a build in gravity. But you dont give me acces to the force of gravity !!!

    Thats would be the same situation.

    And TY for giving me acces to that force. Its there. Its needed to make the system work. So yes you can as well give me acces to it, to use it and to alter it.

    And yeah i am a stubborn, lol .. sorry ?

  • for "object on layer" you will have to pick an object.

    Its not "any object" on layer.

    To launch the "object on layer" event ...

    You do

    new event/condition

    pick an object

    choose "on layer" (for the object u picked in the wizard)

    thats not close to "any object" on layer x

    right ?

    Annoyend ?

    The object field in the actions wizzard would be still there. We need it in some circumstances.

    But it would be so much easyer to leave it blanco when combined with loops that pick more objects.

    Mostly loop events, collision events, overlap events and (more importand) behaviour events. Knowing the action will adress to all the objects picked. And in case of a loop , the objects picked by the loop and in order of the loop.

    You say its possible to pick all objects on layer (x) by an event.

    Now how do you attach an action to that ? To adress all those objects ? When the action is forced to pick One certain object .. or instance of an object ?

    (besides give ALL the objects a family name)

    it is ofcourse possible this way ...

    Assuming there are only 4 objects and there instances in the game, namely ...

    "right_block"

    "left_block"

    "top_block"

    "bottom_block"

    then this

    (event) "right_block" on layer 7

    _______or

    ______ "left_block" on layer7

    _______or

    _______"top_block" on layer 7

    _______or

    _______"bottom_block" on layer 7

    _____________________________(action) ?????????????????????

    wich action would you attach adressing all objects picked by the evening blok ?

    I think ... the rigth answer is ...

    In the event sheet .. click on "add action"

    Pick any object .. but be able to leave this field blanco ...

    code the actions ... as needed

    but since the actions "object" field is blanco, it will run on every object picked, ..

    in this case

    adressing

    all

    "right_block"

    "left_block"

    "top_block"

    "bottom_block"

    's

    on layer 7

    wich action would you attach to this ? I could be wrong, and in fact that would be nice !

    Ofcourse, i could return to the solutions that i suggested in earlyer posts ...

    and now i think about it ...

    would't that be easyer ? rich ?

    to have an system object "event picked objects"

    then it would be so easy

    (event) "right_block" on layer 7

    _______or

    ______ "left_block" on layer7

    _______or

    _______"top_block" on layer 7

    _______or

    _______"bottom_block" on layer 7

    _____________________________(action) event picked objects.x +1

    and be done ...

    and Major inprovement !!! would be !!!

    when i later in the developping of the game, decide to take the object "bottom" out ...

    i take it out the event, but i dont have to reprogramm all the actions.

    hope u see what i mean . or that some one writes it in good english ..

    j0h

  • hey !

    oopz .. since Captain orderd me to stay on topic ! Ha ! i guess i make my Own.

    (Big smile)

    because, i have a suggestion.

    Oh now AGAIN, you think? LOL .. sorry ?

    Ok lets build this up a lil, starting from an easy example.

    the "for each object (ordered)" event loops trough objects you picked and based on an expression you choose.

    All ok, and i so like that event. But then ...

    Then you come to make an action. And the first thing the action wizzard does is ask you "wich object"?

    And then i have something like. Uhhhh, staring at the screen, why do you ask Sir Wizard ?

    All the objects the "For each" loops trough, ofcours !

    But the Wizz will insist that you pick an object.

    When u change this later, you have to change the event AND the action.

    And this is general for a lot of event/action configurations.

    Ofcours it is inpossible to leave the 'pick an object" out of the wizzard.

    When u dedect a collission between 2 objects, or between an object and a family,

    the action must be able to adress the right object.

    And yet,

    i have something like, this is a lot "not meat, not fish"

    now to adress this, and to simplify things. Can i suggest 2 thngs.

    1/

    For the actions, the possibility to leave the "pick an object" field blanc.

    Knowing the action then will do its thing on every object picked by the event.

    This will be very handy when the event is made with several conditions. And when the event picks more objects, not certainly beeing the same instances.

    2/

    A little more power to the event to compensate. Just 1 event more.

    "pick object (x) "

    to use like this

    (event) on collision between "bottom" and "ball"

    ___(sub event) pick "ball"

    ________________________________________(action) .x = .x * -1

    ___(sub event) pick "bottom"

    _____________"bottom" y < 100

    ________________________________________(action) flash 8 times 2 frames

    This will also make the way to events that we dont have yet without obstacles.

    We have no way to pick every object on a certain layer yet. And make an action adressing all those if we could pick em.

    There is no "any object" yet.

  • i got to go home !! .. lol .. work is done.

    Private event sheets. As we have private variables.

    If i want an object to multiply itself every time it hits a specific other object, and the multiplyd object wil do the same.

    Then that is so much easyer done by givng the object a private event sheet.

    Moment it gets spawned/created it starts its events.

    Another example ?

    An object that fals over the screen, when its outside screen, it jumps back to top of screen.

    So much easyer with private event sheet, and very flexible. Easy to use, make and change.

    See it as behaviours that u can write, with the powerfull tools given by construct.

    The ways to use this are endless.

  • hey !

    i am the foreinger in this forum, as u will notice in my english and in the way they drown my treaths to the bottom of time.

    But, if you want an honest opinion, i can do that. Althought i know most will not agree.

    Construct is Beta as ashley states. I think it is Beta in the shaders, but still alpha in the events.

    I also think that it is inevitable that the event sheets very nearby in the future will break with today,

    and be incompatible with what is implemented today.

    A short pro-contra list.

    PRO

    Construct seems to be very alive. New releases come quick. Major bugs get fixed fast. And it is all done by Ashley reading those forums. And thats a BIG plus.

    A lot of events take "expressions" as "input". And thats the real power of construct. Thats what lifts Construct above all other "game makers" that i used.

    Behaviours, the way objects behave, are plug-in based. And that will be in the future a great thing. Especialy because there is a SDK available, and one day there will be Docs for it too.

    CONTRA

    The bugs are not a contra. They are still opportunitys. Construct is in beta.

    Picking and isolating objects can be a real pain in the ****. The events/actions system is a puzzle.

    Its not documented yet. Things that u expect to work as triggers, dont work as triggers. The events can be done with the power of an expression, but the action dont carry that power on, because it will force you to "pick" an object. Where it is more logical to let the events pick/isolate, and keep the acions general. This way the action will work on every object picked by an event. And thats not the case now. And although Ashley is not open towards those questions, it will be necensarely to change

    the events-system to bring construct on again a higher level.

    I asked Ahley if he planned individual "event sheets". He did't answer me (as usual). So i guess not.

    No individual event sheets are a major draw back.

    I guess, you must complete the ghost tutorial to understand what i am mumbling about.

  • I dont get this LOS

    It's not working for me.

    I used a turret to take action based on its tracking angle.

    THis worked well for me.

  • Ok, so since no one seem to have a solution for my problem as stated in ...

    Let me try again to suggest a solution. Its the same old idea. But this time easier to implement.

    Is it possible to make an "plug in" object similar to the "array object" ?

    Just like the array object it should be possible to set the depth.

    Only this array will have only 1 dimension.

    And it keeps track off "the picked objects" by storing there UID's.

    So lets call it "Pick History"

    If i only want the 2 last objects picked to be tracked, i must be able to set the depth to only 2.

    and it can be used as follow.

    (event) system: always

    __(sub event) object "one" with .x 50

    ________________________________(action)

    __(sub event) object "two" with .x 60

    ________________________________(action) hinge to "pick history" at entry 1

    Also, it would be handy if every "starting" object in the wizard could be converted to an expression.

    If you hinge now, u can can convert the "to object" to an expression.

    But not the "from object"

    And thats the case in all actions.

    Plz, take the afford to read trough my bad English.

    Ty.

  • Attan, ty

    &

    it looks simple eh?

    What you suggested is one of the options ive been.

    In this zip you find 2 caps.

    http://www.mediafire.com/?yjztmj1rdnd

    One with the objects as Unique ID's, one with the objects as instances.

    In the instances .cap, well this feels like it should work.

    Only if you run it in debug mode, click the array to expand and look at numbers,

    you will see that those are not the UID's as one would expect.

    Thats the reason why it dont work.

    You can link this action to every loop u can think of.

    Even this ..

    System: 0 For "runit" from 1 to 640

    wave: 5 X Equal to loopindex("runit")

    will put the same numbers in the array, but they are not the UID's (well not those i see in the layout)

    the .cap with the unique objects i provide for in case someone is able to make a loop that runs trought the names of the objects. Wich would be nice too.

    the other option is that i link 20 objects a day one by one by hand,

    only takes me a month i guess : ) .. good thing its not februari

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • alright !!!

  • Here is a quick example.

    http://www.mediafire.com/?xuolx1gszxw

    I suppose you know what i am up to, since 640 is the screen size. : )

    I been diving a few days in wave equations.

    But they just dont fit (in my brain).

    While the solution is kinda simple.

    As you see .. Hinges have the right damping to simulate area tension.

    I just hope there is a way to automate this, and to take the stiff thing into an expression.

    Besides if i can automate the creation of this,

    i sure "suddenly" know how to pick&combine in more situations then i do know now.

    Ashley i love those physics, aren't they beautiful ? when you see them act like this ?

    You might have not looked at the Koch fractal i made, my comp could bring it to 8 iterations,

    man ! do u know how many objects that are ! ? !! .. lol

    j0h

  • I have 640 objects that need to be "hinged" to each other, linear.

    like,

    hinge object 1 to object 2

    hinge object 2 to object 3

    hinge object 3 to object 4

    .......

    hinge object 639 to object 640

    the " to object" in the hinge action has no "expression" to use.

    i cant figure out a way to do it in a loop

    do i have to hinge em all one by one ?

    or does someone has an idea about how to do this ?

TheInstance's avatar

TheInstance

Member since 5 May, 2008

None one is following TheInstance yet!

Trophy Case

  • 16-Year Club

Progress

16/44
How to earn trophies