Momio's Forum Posts

  • While jump sustain is a cool feature, it gives me some problems, for example:

    A platform character who can climb ladders-> When on a ladder, platform behaviour gets disabled and a vertical-only 8direction is enabled.

    If I jump off the ladder, I disable the 8 way and re-enable platform, but if I have already "spent" my jump sustain jumping into the ladder, since I didn't touch ground, and despite the platform behaviour having been toggled off and on, I still technically am on the same jump, so I can't jump off the ladder with jump sustain.

    I'm thinking of making my own jump sustain via events and timers, but if possible I'd like to use C2's tools whenever possible. I tried setting jump sustain to 0 while on the ladder and restoring it when jumping off but it doesn't seem to work.

    Any ideas? Thanks!

  • I guess that if exporting below Android 5.0 is not available it would be for some reason, but...can we expect it in the near future?

    My cellphone, for example, is a mid-tier one running on KitKat, it can play pretty much any game, and to this day I never got any android version incompatibility with anything I ever tried to download from the Play Store (Well, as a matter of fact, I actually had that problem with Super Mario Run but the very next day I tried again and it downloaded and ran just fine).

    As cool as directly exporting apks is, this is kind of dissapointing and greatly reduces C3 scope.

  • The events are only being indirectly affected. The functionality change isn't related to the events at all. You get different results because the behaviors (both platforms and the sine) evaluate in a different order. This causes the positions of the objects to be different than they otherwise would when the event sheet is evaluated, which then changes the result of the conditions. You can see this when the player 'lags' behind the other sprites. The platform behavior attempted to solve this problem by doing its move logic in 'posttick' while other behaviors use 'tick', but all this really did was move the problem, which is made clear when you have a platform object stand on another platform object.

    There are ways that this could be changed so that you don't have to think about the tick order of behaviors, but I wouldn't expect to see them in Construct 2, what with Construct 3 being the primary development focus now.

    At the very least, it would be nice for this kind of stuff being consistent so we can work around it. This is pretty serious and I hope it gets fixed on Construct 2 -Construct 3 or not- since it can potentially break a lot of stuff, and kinda penalizes you for trying to be organizated.

    (I have no idea how Construct 2 works internally, but maybe it could be made so the folders are an editor only abstraction thing and doesn't get reflected on the final code in any way).

  • Problem Description

    Platform behaviour gets glitchy and imprecise on some situations......only if the object is organized into a subfolder!

    Attach a Capx

    CAPX

    Description of Capx

    The example presents a simple platform game situation, with a moving platform (solid object with sine behaviour), a solid block on top of it (solid + platform behaviours with default controls disabled), and a player character with platform behaviour.

    Steps to Reproduce Bug

    • Create a sprite with sine (linked to vertical movement) and solid behaviours.
    • Create a sprite with platform (optionally disable default control so it stands still) and solid behaviours to act as a solid block and place it on top of the moving platform.
    • Create a platform behaviour sprite.
    • Create an object subfolder and move the player object to it.

    Observed Result

    With the player standing on the solid block, it lags behind the vertical movement of the platform and the block, and the "Is on floor" condition (Displayed via text at runtime on the example) acts erratically only being true at the extremes of the vertical movement when it is slower (As you can imagine, this can lead to all kind of issues on a complex project...).

    At first I tought it was just a limitation with Construct and stacking stuff on moving platforms, but the thing is........It works perfectly IF YOU JUST TAKE THE PLAYER OBJECT OUT OF THE SUBFOLDER! (You can do just that on the example capx...take the player object back from "New folder" to the Object types main folder).

    Expected Result

    Well, at least that folder organized objects behave the exact same way as unorganized ones...This could be a pretty serious bug...who knows what else may not work properly just because being into a sub folder?

    Affected Browsers

    • Chrome: (YES)
    • FireFox: (YES)

    Operating System and Service Pack

    Windows 7 Sp1

    Construct 2 Version ID

    r244 64-bit (A friend of mine still uses r237 and reproduced the bug)

  • Hm, seems that the examples I linked earlier doesn't work properly with touch control and only scrolls left, apologies to anybody who tried it on a cellphone. Easy fix, but I won't bother because....I fixed the main problem!

    For anyone who may find this useful, the correct width equation is (LayoutWidth-ViewportRight(5)) * PARALLAX_SCALE + ViewportRight(5) (Layer 5 is fixed with 0 parallax).

  • What I want to do:

    Given a stage with several parallax layers, what I want to acomplish is for tiled backgrounds to automatically adapt in width (Im not using vertical parallax) at start of layout to wichever layout width you throw at it without wasting space.

    What I did so far on a simple example capx:

    -A layout sized sprite acting as background (on a regular 100% X parallax layer) with a colored stripe on its vertical center so we can identify the middle point of the layout

    -Several parallaxed layers. On each of them, like the backgroud sprite, there are sprites with a vertical stripe at center (so we can see where the center of the background plane graphic is. On a real project this would be a tiled background). This graphics have its center situated at top left, so with a 0 x coordinate they are already correctly aligned to the left of the layout.

    -Now, what I want to do is, based on the parallax of the corresponding layer, to calculate the required width of each plane sprite so they stretch all the way to the right margin of the layout without going out of it or falling short.

    -The closer I got to it is setting the width to layoutwidth * parallax of the corresponding layer / 100, but it is still far from it...The background planes only seem to correctly align to the right margin of the layout when I scroll all the way to the point when the right margin of the layout is on the left edge of the game window (Im using unbounded scroll for testing, so I can scroll outside of layout bounds).

    This is all kind of abstract and hard to wrap your mind around (at least for me it is), so here is the test I made (Scroll with the cursor keys or by touch/mouse):

    -With layoutwidth * parallax of the corresponding layer / 100 formula, notice how the planes align with the rigth margin of the layout when the layout is leaving the screen on the left side of view.

    -Desired result, this version doesn't calculate anything and instead it uses manually adjusted width on each plane. Obviously, the whole point of what I want to do is not having to do that, but this illustrates what I want to achieve.

    Please note that since this uses unbounded scrolling and the background sprite covers the entire layout, whenever you see white, you are looking outside of layout bounds.

    CAPX (Disable the last action to make it work like the "Desired result" example).

    I don't know, maybe the window width factors in all of this, but so far I didn't manage to incorporate it to the formula with sucess......Any ideas?

    Thanks!

  • Weird, I don't remember deleting or moving it (it's still on my dropbox but the link is different)

    Link updated, ASHLEY.

    (Edit: Bug persists on r244 64-bit)

  • Yeah, that would be cool

  • Pretty self-descriptive, but you know, adding rotation properties for individual particles to the particle plugin, rotation speed, angle (and rotation speed) randomisation and all that stuff. This could really improve Construct particles.

    And while we are at it, let's go nuts, why not animated particles too?

  • Cool, any chance we can make custom translations ourselves?

    (If it helps move this up on the priority list think that languages is an advantage Stencyl has over you guys )

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I noticed that option on settings, although there is only english available at the moment. I may get a job teaching kids videogame design soon, and not being on a english speaking country, language is a drawback for Construct on that front, so I really like this.

    When can we expect more languages? Does it change everything or just help text and stuff like that?

  • Personally I think the "X" to close should be simply be removed, and leave right clicking (long press?) the only way to close or undock the bars.

    I like having the Xs myself, but it's kind of annoying how hard to see they are with that gray color over a dark blue bar.

    The save button only shows options for cloud saving. I imagine a new user might find it difficult to realize local saving is an option at all, as it is once again buried under submenus. It would be great if the interface for cloud/localstorage/download save were unified.

    I agree.

  • So far, I tried a Construct 2 project and despite exceding the (annoyingly short) event limit it worked. But then I stumbled into this, so it is unplayable right now. I hope they address it soon, i guess something like that should be trivial to fix, but it breaks backwards compatibility for me and I need it for a big project Im doing for the scirra store, so obviously I really want it to work on Construct 3!

  • Another suggestion: Why not implement all the Touch plugin coordinate translation functions ( X("layer"), Y("layer"), XAt(layer index) and YAt(layer index) ) to every plugin wich uses coordinates? It's pretty handy, and specially so SIMPLE!

    Right now, Im using an action on a Construct 2 project that obtains the equivalent coordinates of a sprite on another layer (with different parallax, scaling and all that, so I need to translate coordinates) and it goes like this:

    CanvasToLayerX("Layer1",LayerToCanvasX("Layer2", sprite.x, sprite.y) ,LayerToCanvasY("Layer2", sprite.x, sprite.y))

    (Same thing for Y)

    While it could be so much more elegant and ABSURDLY EASIER with:

    sprite.X("Layer1")

    I bet anybody who ever had the need to set up something like that did struggle with it at least a little (I sure did!)

  • > As a suggestion, for an user friendly engine as construct, it would be nice a new type of string variable on wich we can store predefined strings, kind of a 'multi-choice' text variable.

    >

    > This way, when checking or setting this variable we could choose from this predefined value from a drop-down menu, improving readability and ease of use.

    >

    > This would be very useful when checking events based on stuff like difficulty level ('if difficulty is hard') or any other multi choice option, or when a character has a 'state' variable ('if state is taking cover').

    >

    Isn't that what arrays are for?

    Kinda overkill and not really what I was talking about, with arrays you have to mess around with indexes and all that stuff, and fill them via event sheet actions, and you can't have an instance array for objects (well, you could use a single array for a type of object and tinker around with dimensions, assigning UIDs, besides my point of simplicity anyways) what Im talking about is...well, a picture is worth a thousand words, right?

    Pretty much that, but custom made. Simply put, a variable with custom fixed values accesible via dropdown menu.

    Think about a complex character on wich you need to check a lot of special cases, so you make a 'state' string instance variable for him and events for every value to see if he is "crouching", "jumping", "blocking", "atacking", etc.

    If for some reason you want to change the wording of some of those states ("crouching" for "ducking" for example) or correct a typo, you would need to change every event wich checks the prior wording in order to match the current one, and in every case remember whatever you called a specific state.

    Now, with what Im talking about, you could define this fixed values in-editor when creating the variable and simply pick them out of a dropdown later, or change the 'name' of this predefined values anytime with the events automatically updating it. It's pretty much a regular string under the hood but with the editor working with you to make things a little bit easier (less typing and not having to remember specific values).

    It doesn't even need to be a new type of variable now that I think of it, it could be just some "Add predefined values" option to numerical and string current variables, while they still could function normally and take non-predefined values too.

    I hope this explains it better.