Just wow...this is ridiculously awesome!

Tons of potential, great job! (Both you and Gigatron)

The original .capx is not a very good case - it relies on Platform + Solid on the same object, which has never been a directly supported case in the engine. The engine treats objects as either a moving object or an obstacle; you shouldn't use both. (I might actually block this case in C3 since it's not supported and people keep doing it.) I'd appreciate a different example .capx that shows a similar problem without using this not-really-supported case.

Thanks for your anwser, Ashley. But I think you should reconsider your posture on Platform + Solid not working well together and maybe look into making them more compatible (or offering some alternative for solid platformer objects). Also blocking it on C3 could break a lot of old/current projects and negatively impact backwards compatibility.

While I don't know the inner workings of Construct and assume it may be difficult to fix that incompatibility, think that stuff like pushable solid blocks (for wich using platform behaviour seems like the simplest and more obvious solution so they are affected by gravity, move around with Simulate control when pushed and interact with platforms) are actually a pretty common case on platformers (So there's the reason a lot of us keep doing it! ). Just to name a few examples, Spelunky, some Sonic games (like the first one) or even solid enemies you can stand on like in Super Mario Bros 2, and the list goes on and on.

For what is worth, as far as I can tell platform + solid currently works pretty well anyways, except on this case (on a moving platform, wich on most games it probably would be considered a rare case)

Momio you could enable double jump after climbing the ladder then disable it when you want to.

Between the time I posted this thread and read your answer, I did my own jump sustain mechanic independently of platform behaviour...it was easier (and less of a mess) than I thought!

But that's clever and could be simpler and more clean than my solution, since I don't contemplate (real) double jumping on my project I never thought of that, thanks!

(Although, upon testing, I run into the same(ish) problem...If I jump from ladder to ladder (or from wall to wall, I need this for walljumps too), I can't reset double jump to perform additional jumps without touching ground, oh, well...back to square one, I guess! )

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?