keepee's Forum Posts

  • In the editor? Nope unfortunately.

  • There's no dynamic way to refer to different variables with one action. Condensing them into one var like r0j0 said is pretty much the only way.. or you could use an array I guess but that's probably even more awkward.

    Have you looked at the A* pathfinding plug in?

  • Hi, this has been troubling me for a while now..

    Say you've set up your layers for lighting, similar to the example file 'lighting', or by using the lighten/multiply shaders as shown in this .capx (link)

    Lighting layer   (All black, but with light objects that act like 'erasing' the darkness)

    Main layer   (visible game stuff, like the player etc)

    Backdrop layer   

    This works great for the main layer, but anything displayed on the backdrop (which could be something really far away, for example mountains or space) will be affected by the lighting in the same way.

    This makes no sense from a design standpoint..

    for example, a torch held by the player should not light up the stars in the night sky behind him (they should already be lit)

    and if the player is inside a dark house but on a sunny day, the view out of a window should still be bright.

    so any ideas on a work around?

    tldr: how do i make the background image in the following cap be unaffected by the top layer:

    (link to .capx again)

  • Mixing physics behaviour with other movement behaviours never really works properly.

    Your best bet is to make your own sin movement using the physics behaviour...

    I made a quick cap file, it's relatively simple as it only moves left and right but you could expand on it to make it go up/down and spin etc.

    When you preview it, left click to create physics boxes.

    capx file

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Apparently you have to email Tom directly, but you might have better luck by just asking an admin.

  • It should work.. 100% totally absolutely should work.

    I demand screenshot..!

  • eg. rotate 10 degrees > wait 0.1 > rotate 10 degrees > wait 0.1 > rotate 10 degrees > wait 0.1 > rotate 10 degrees > wait 0.1 > rotate 10 degrees > wait 0.1 > rotate 10 degrees > wait 0.1 > rotate 10 degrees > wait 0.1 > rotate 10 degrees > wait 0.1 > rotate 10 degrees >

    <img src="https://dl.dropbox.com/u/53374990/Pics/user647_pic54060_1345007615.jpeg" border="0" />

  • I meant to include in the last comment that you should try it that way just to see if it is actually a bug with the 'on object created'.

  • ohh i see now, it is slightly different to what I do..

    Instead of having icon.match you could have enemyships.match and do:

    + Enemyships.match = 0

          >create object icon

          >set enemyships.match to icon.uid

          >icon set animation frame to ...

    you can match them either way, it's just as easy to pick out the correct instance.. just if you do it this way you can also use the match variable as a kind of 'trigger once'.

    (The reason why you don't just use trigger once in the first place is incase it needs to apply to two or more instances in one or two consecutive ticks.. that way it'll break and only apply to one of them -'For each' may fix this but i think the way above is simpler)

  • This should work, i have a ton of objects that have their frame set according to a variable on the 'parent' object...

    Care to post a screenshot or .capx?

  • search manual for delta time

  • I can't give you a definite answer cos of no cap or screenshot..

    but 'For each' is generally what solves a lot of these problems.

    You might wanna read up the pages about how events/picking instances work in the manual too.

  • really blue/green/red should all be the same object (piece) and then you can do

    +on left button clicked on piece

    +pick top instance

    but if you do need them to be different objects you can put them all in a family and do the same.

  • No, I believe the sub groups keep their enabled setting independent of the main group

    but of course if you disable the main group, none of the subgroups will run because they are part of the main group.

    that's how it should work, if it doesn't it may be a bug

    But this is something you could easily check yourself with a few events

  • Either they are off screen or behind something, or they're being spawned onto a layer name that doesn't exist anymore.

    a screenshot may help, but if you upload the .capx then someone will find out what's wrong guaranteed.