cacotigon's Forum Posts

  • The % is the modulo operator. It gets the division remainder between two numbers.

    For example: 375 % 360 = 15, 360 % 360 = 0, 90 % 360 = 90, etc.

    Step 1: Angle % 360

    Single angle could be negative or positive, the first modulo returns a remainder between -359 to +359 degrees.

    Step 2: Add 360 degrees

    Returns the positive quadrant equivalent: (ex: -90 degrees would be pointing upward, this returns 270 degrees)

    Step 3: % 360

    If original angle was positive, step 2 would have caused it to exceed 360 degrees, so take the modulo again.

    More information: http://stackoverflow.com/questions/1351925/why-does-2-mod-4-2

  • Egon

    Love the game style so far. You should consider adding the occasional downward draft (with visual cues) which forces you to tap very quickly to push through it.

    Basen

    You should post your questions into a new thread on the "How Do I" board.

    Even if you mean well, it's not cool to hijack somebody's WIP post.

  • If you need 0-360 for purposes of comparisons, etc., it can be normalized from 0-360 using:

    (Angle % 360 + 360) % 360

  • xoros

    The current workaround is to put every single sprite object into a BaseSprite family and every tiled background into a TiledFamily, then pick by UID. Having these base classes is useful in general especially when writing helper functions.

  • There's no way to set multiple lines in a text box field in the C2 editor short of editing the project XML file. Your other choices are loading a script file at run-time or assigning the text box using set value in conjunction with the 'newline' keyword.

  • [quote:2wp8gbis]If you use Is Overlap, it will trigger many times on each enemy hit. If you add Trigger Once to it, it sometimes does not trigger on the subsequent enemy hits so the AoE is not reliable.

    See my earlier explanation, it explains why this happens. It is expected behavior and by-design.

    Bottom-line:

    "On Overlap + Trigger Once" keeps track at a per-Object Type/Family Level.

    "On Collision" keeps track at a per-UID level.

  • locohost

    I wrote a tutorial a while back on picking instances within the same family.

    https://www.scirra.com/tutorials/556/understanding-picking-with-respect-to-families

    Here's a quick picture of how to do what you're asking:

    You have to pick instance A, and save the properties you need to temporary local variables, *then* pick instance B.

    So this is what your code might look like:

  • Try Construct 3

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

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

    Colludium already gave an example of this earlier in the thread. Using Overlap + Trigger Once, you may run into a situation where the the original object overlaps a second object while still having already overlapped the first one earlier in time. When this happens, Overlap + Trigger Once will fail to trigger.

    This limitation can get exacerbated if you make use of families: Obj1 Overlap Family + Trigger Once.

    For example, you have a Farmer object, and a Fruit Family which consists of three different objects Apple, Oranges, and Caimitos.

    Your collision routine is:

    Farmer Overlap FruitFamily + Trigger Once --> Spray the fruit with pesticide. (the fruit remains)
    [/code:1092tdzb]
    
    Here is a situation that might occur:
    [ul]
    [li] Farmer is walking quickly through the garden[/li]
    [li] Farmer overlaps an Apple[/li]
    [li] Overlap triggers and fruit is sprayed.[/li]
    [li] Farmer sprite is fairly large and overlaps an Orange [/li]
    [li] Since the farmer is still overlapping a FruitFamily (the apple), the overlap event will not be triggered.[/li][/ul]
    
    So basically, the overlap will NOT trigger again until the farmer is not overlapping *[b]ANY[/b]* FruitFamily objects. On collision does not have this limitation.
  • Colludium

    Unfortunately, even if the window and layout dimensions are identical (which means C2 only creates a single cell, https://www.scirra.com/blog/ashley/6/collision-cell-optimisation-in-r155), I still see the same performance degradation with the collision_test_capx sample.

    Oddly, I've never run into this issue even with thousands of objects in a level with "On Collision" because I have a hibernation system that periodically puts objects that are too far away from the player into a "suspended state". Then, I have upper-level picking conditions filter only active objects before the "On Collision" subevent.

    This is in contrast to C2 best practices: (quote from Ashley)

    [quote:1ts1pur8]Make sure collision conditions are the first condition in the top-level event. When no objects are picked, the collision conditions can make efficient use of collision cells to reduce the number of checks made, ensuring performance is good in all circumstances.

    If Is overlapping (or On collision) comes after another condition which has picked certain instances, it can no longer use collision cells ... If a prior condition picked a large number of instances, it must brute-force collision checks again.

    I agree with what everyone has said so far, I'd love to get some official feedback about this.

  • lucid

    I think this is expected behavior.

    I usually have my creation methods wrapped in a custom function called "Spawn (ObjectName, X, Y)" which returns the UID of the new object. If you explicitly pick by UID after the creation, then this problem shouldn't happen.

    It's best to just have a master Creation function to handle spawning of all objects. Having it also lets you "spawn by name" so you can easily switch Enemy.Projectile = "HomingMissile" or Enemy.Projectile = "RegularBullet", assuming these are Object Type names. Keeps your code clean.

    EDIT: Screenshot

  • bernivic135

    I'd also recommend giving the plugin architecture another shot. Just take a look at some of the existing plugins / behaviors js code. Start by deconstructing the simpler ones, for example rotate/sine behavior, and then move on to more complex ones like platform. Honestly, I think it's fairly straightforward. I have a simple template behavior and template plugin that I use as a sort of scaffolding when I need to quickly prototype new ones.

    There are already tons of people who have written addons for C2. It really depends on what you're trying to accomplish.

  • This capx you've uploaded has this problem and/or your sidescroller game? We still need more details. Are you talking about native browser (safari/chrome) on tablet/phone, or wrapped like CocoonJS or PhoneGap?

    Just tested this capx on my iPad 4th Gen using web preview without any problems. Could be a speed issue.

  • noisetank

    Check the collision box X values on each tine to make sure they are identical (set them to whole numbers). If you have Pixel Rounding set to OFF, and the values are fractionally different, the fork may not collide correctly.

    EDIT: This goes for the two boxes as well.

    Here's a capx:

    https://dl.dropboxusercontent.com/u/12667027/ForkTest.capx

  • Steely

    Yeah, the pin behavior will not reflect changes in the parent's height/width. Fortunately, it's fairly easy to roll your own generic pin system using Controller + ConnectedSprite by using families.

    I'm not sure what you're seeing without a capx, but here's a simple example manually re-positioning the head without seeing the popping-off behavior. And as a last resort, you can always turn your bug into a feature by repurposing your game into rockem-sockem robots.

    Here's a demo:

    https://dl.dropboxusercontent.com/u/12667027/ImagePoint%20Attachment%20Test/index.html

    Here's the capx:

    https://dl.dropboxusercontent.com/u/12667027/ImagePoint%20Attachment%20Test/ImagePoint%20Attachment%20%28not%20pinned%29.capx

  • Hmmm, I'm not sure to be honest. I think the standard Chinese fonts (at least for Windows anyway) are SimSun which is used for simplified and SimHei which is largely used for traditional Chinese.

    As far as Android, I believe that the default typeface Droid includes support for Simplified Chinese (GB2312) and Traditional Chinese (Big 5).