R0J0hound's Recent Forum Activity

  • For the math on the speeds and directions of moving through portals there is a capx here:

    http://www.scirra.com/forum/portal-vector-realignment_topic48791_post306636.html#306636

    For standing halfway through the portal and being seen on both ends it's doable with layer masking effects to hide a portion of the player. You'll be using two player sprites at that point for each portal. The most complicated bit will be handling collision detection for the player when moving through the portal. The main example of the problem would be a portal mounted on a solid wall, the wall will have to be set to not be solid or something when passing through. This is where some ingenuity and creativity will be required to get something working.

    For your last question... Put frosting on a loaf of rye bread. If that cake isn't a lie I don't know what is.

  • Checking collisions with 2 objects instead of 6 would be faster since less needs to be checked. With a small number of sprites the performance difference would be negligible, but it could be more beneficial if you have many.

  • One idea that may make it a bit easier to control is to only let the "ComputerProgramSpawn" function get called when not waiting.

    1. Create another local in the "computer spawning" and call it stall.

    2. Add to event 48 a compare stall=false

    3. And change the wait in event 52 two three events:

    set stall to true

    wait 1 second

    set stall to false

  • When not shaking you can simulate bounded with something like this:

    set scrollx to clamp(scrollx, screenwidth/2, layoutwidth-screenwidth/2)

    set scrolly to clamp(scrolly, screenheight/2, layoutheight-screenheight/2)

    I didn't verify the expression names but the idea should be sound.

  • There is no example of this combined with a bubble shooter example that I know of but this topic has some general info on a way to pick a chain of objects.

    http://www.scirra.com/forum/matching-more-than-3-sprites-gem-matching_topic51703.html

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I wouldn't say a bug really as all "trigger once" is run once every time the previous event changes from false to true. So within a loop i'm unsure what it should do at least I can't wrap my mind around it.

    The is overlapping is only false when none of the objects overlap, so trigger once is working as expected if the for each is removed.

    Or perhaps it is a bug. What do you think the expected behavior should be in the case of the example? Or should there be another condition like "trigger once per object"?

  • Centra

    The two issues you are running into are newly created object picking and dealing with picking multiple instances of the same type separately.

    Created objects become the only picked object for the the rest of the event. In the case of event 1 and 2 the 2nd spawned sprite will always have "isanswer" toggled. Also the created object object won't be able to be picked as normal until the next toplevel event (event that isn't a subevent) however a triggered event such as "on created" or a funtion call doesn't count as it's more like it's run right when it's called. Your on created event as it is has only one sprite picked (the new one) which can be somewhat solved by adding a "pick all sprite" system event, but you still won't be able to pick the other spawned sprite until the next toplevel event.

    And that leads nicely into issue #2, picking multiple instances of the same type separately. There are two ways to deal with this:

    * The first way is to pick one of the instances and save the values you want to compare into local variables and then pick the 2nd and do the comparison. It would look something like this:

    + Some event that picks two sprites
---local number inst0frame=0
---+pick sprite instance 0
------ set inst0frame to sprite.frame
---+pick sprite instance 1
---+compare inst0frame = sprite.frame
------ do something

    * The second way is to use single object type family. So you can pick two objects of the same type separately using two different names. You can think of the family name as an alias to the object name. Events would look something like this:

    + Some event that picks two sprites
---+pick family1 with uid of sprite.uid
---+pick family1 instance 0
---+pick sprite instance 1
---+compare family1.frame = sprite.frame
------ do something

    Ok, and in respect to what you're trying to do you can simplify it by putting the sprite into a family and call it say family1.

     +every 3 seconds
---create sprite
---set sprite frame to random
---create family1
---set family1 frame to random
--- +while
--- +compare sprite.frame = family1.frame
-------set family1 frame to random

    cheers

  • Hi,

    Here's your original capx with commentary on the problem events and what they do.

    https://dl.dropboxusercontent.com/u/5426011/fixed/tobye_orig_comments.capx

    And here it my cleaned up version.

    https://dl.dropboxusercontent.com/u/5426011/fixed/Tobye.capx

    Finally here's a simple capx that shows a feature of picking that was causing you issues.

    https://dl.dropboxusercontent.com/u/5426011/examples18/picking_behavior.capx

  • I do think this happens to everyone. If you look at the "website issues" section of the forum there is on average one topic per page about the issue. The oldest is on page 30 of the 31 pages, which shows that it's been around for a while.

  • Well doubt what you may. I'm willing to be impressed if this project is successful.

  • The lowest you could set it would be about 0.016 (or 1/60) seconds. That and anything lower would be the same as a "every tick" condition.

    Back to the question as to if it's accurate: it runs if the time passed since the last time it ran is greater than or equal to the value you used.

    Here's what "every 1.0 seconds" does:

    global number old_time=0

    +old_time + 1.0 >= time:

    -- set old_time to time

    -- do actions

    3) It will likely be a bit lower than 1000. Of course you could test this if you wanted.

  • For the physics behavior set gravity to disabled and manually apply a force with events in whichever direction you want.

    For the platform behavior you can use the "set gravity direction" action.