Rex Rainbow made a lot of very usefull plugins for C2. Many people used them and he did a great job. When my understanding is correct, Rex Rainbow decided a time ago not to port his plugins to C3. I regret his decision very much but have to respect that. However, are we gonna put the future of C3 on the decision of one man? That is not a good idea in my opinion.

The problem is, Construct still has some deficiencies, and the community does pretty much need to make plugins to bring it up to the capabilities of other game engines in some respects - so if one of the most prolific and reliable developers of these plugins doesn't support it, then it's a big deal. I haven't checked C3 for a while, but when it dropped I was a bit disappointed, and since I'm several years into a C2 project I probably couldn't switch even if I wanted to. There are so many simple plugins that should come as part of the standard package - things like the canvas, move to, music fade, image/perspective distortion etc. The perceived mentality of Scirra seems to be that the community will make all that stuff, but I would be more confident if the base package had more of these quality of life improvements built in, so that we had proper ongoing support from the actual developers. Like I said, I haven't checked out C3 for a while, but last time I checked it still seemed to be missing many things that I would have thought obvious as high priority for people building a game engine that is meant to make things easier.I absolutely hate relying on plugins from sporadic developers, who use a forum like this full of dead links to post their work so I wish Scirra would take more responsibility for useful core behaviours and plugins in this respect as the community files are decentralised and an absolute mess. Community plugins are great, and I love the idea of them, but they should be used to enhance an already great product, not fix it up with sticky tape and glue.

Thanks heaps Dop - that is a huge help indeed! Much appreciated :D

Hi, I always seem to have issues with making multiple things on screen behave in a timed manner, but to different times.

I have some columns which pop in and out of the ground - each one has a timer behaviour, an instance variable called "traptimer" and a boolean variable to see if it is active or inactive - at the start of the layout I do a for each loop and set the timers to the "traptimer" instance variable. This then toggles that boolean variable on and off and stuff happens depending on its state. This works fine for one object. But as soon as I have multiple, all hell breaks loose.

If you look at the attached example, you'll see that there are 3 columns, with their "traptimer" instance variables set to 1, 2 and 3 seconds. If you look at the objects in debug mode, that boolean is being toggled on and off at the correct rate for each of them, yet the animations are going haywire. I can't seem to find what's wrong, if anyone has a moment and could take a look it would be much appreciated. Many thanks :)

LINK:

dropbox.com/s/23njtqfx1bbx0fd/popup.capx

Try putting them on the layout rather than the layer.

Zed2100 - thanks very much! It sounds like it could be a good solution. Perhaps sticking the objects into a family and scrolling that is the way to go. The map is made up of an array, 2 tilemaps and a position indicator so could be wrapped up in a family and scrolled without too many problems I think. Now that I think about it I might just be able to pin everything to an invisible bar and scroll that. Thanks for your response, I was probably approaching the issue from the wrong angle.

Hi all, I hope this makes sense, I would post a .capx but it's a bit hard to isolate from my game at the moment, but if anyone thinks they can help and wants to take a look I will do so. Will try to describe first.

My game has several different layers, one of them is a global layer called 'MAP' which is shown when the user presses the M key. When the M key is pressed it pauses the game and it unhides the map/menu layer.

The map/menu layer contains three screens worth of information, so it can't all be displayed at once. Instead I give the player the option to press the left and right arrows and it will smoothly scroll to the relevant point on the screen using lerp(scrollx, target, etc). Because I can't target a specific layer to scroll to, it does the whole layout - it doesn't really matter because the map screen covers the game area so the player would be unaware of this, BUT using this method there is quite a limitation, in that if the current game layout is smaller than the area needed for the 3 menus it can't scroll to them.

So if I have 3 screens wide to fill with my map/menu it takes up 1920 pixels but if the game layout is smaller than that eg 1280 pixels, the scrollto won't work at any range outside of the layout, even if the layout the global map layer is on is larger than this and set to unbounded scrolling.

If I could turn unbounded scrolling on and off with events, or if I could target a scrollto location on a specific layer I might be able to come up with a workaround, but there doesn't seem to be a way to as far as I can see. I could just make sure all of my layouts are at least the width needed for the map/menu - but it will be a lot more mucking about, less easy to maintain - as I'm doing a metroidvania style game with many different rooms/layouts with a map etc, I don't really want to have to pad layouts out like that if I don't need to.

Anyone got any suggestions, or better ways I could go about this?

Many thanks!

I don't think Construct 3 is any more limited, but as John Cutter said there will be less addons (some of which are very useful). A lot of people can't transition over to C3 due to being mid way through large C2 projects with dependencies on such addons, or don't want to because of the rental system. There isn't really a right answer. If you don't mind software rental then I'd say go for C3 as it's where Scirra are focusing their energies and it will only continue to improve. There are some workflow enhancements, and of course it will run on tablets if that's your thing, but there's nothing really that new or interesting feature wise added to C3 yet. That said though C2 is pretty feature complete for a lot of things and will probably be relevant for a while to come - if you design your game without using too many additional plugins there's nothing stopping you building it in C2 and then continuing it in C3 if you ever wanted to - that would probably be the 'safest' route as you will have a perpetual C2 license and the luxury of developing at your leisure but also knowing that you can jump onto the newer platform if you need to at a later date.

On each of your play and exit controls, before the System>go to layout - you can just add an action for the audio plugin to stop - and then put in the tag you want to stop, so in this case stop "game action" it will stop the audio, so in the next layout on start of layout you can put in another audio action to start the relevant audio for that layout.

Rather than attaching a sound to each tile, it's probably better to attach it to an invisible sprite and then place the sprite in an area that needs the ambient sound (tweak the settings so that the distance/volume is correct etc). I usually just create a bunch of these invisible sprites, 1 for a waterfall, one for birdsong etc and then place them strategically on my layout.

Waltuo - thank you for a solution - it does indeed work.

Here's an example of what I mean. If you play the attached file when you jump with up key near a ledge the character will hold onto it (the state of the hitbox will be jump) if you press z, an animation will play and hitbox will be teleported up to the ledge. If you're jumping this seems to work ok - although it was a headache to even get that far and another user worked out that I needed to set a small offset to stop construct triggering the jump animation. The problem now, is that if you catch the ledge when falling (try jumping from one pillar to the other and grabbing the ledge) when the character pulls themselves up it triggers the fall animation straight after the hitbox teleports. Already, the system I have had to set up is very 'hacky' and not very good. It could be made much more elegant and could probably actually work with control over those states.

https://www.dropbox.com/s/yay2q8g52c7t7 ... t.c3p?dl=0 <--- C3 file

https://www.dropbox.com/s/mhsh6fknxes04 ... .capx?dl=0 <---- C2 file

I thought that setting vector x and vector y to 0 would fix this too, but it doesn't appear to. When the object is returned to a platform it still continues from where it left off and triggers unwanted animations (even if the hitbox doesn't necessarily move, or appear to move). It would be really good to have control over the states so that I could just set it to "stopped" therefore overwriting the land animation (when necessary). Giving the character a bunch of variables and changing animations depending on what's happening is a good idea, but I'm thinking it may still have the same problem - because I have a landing animation and would need to call it when "on landed" happens - which is still part of the inbuilt platform behaviour - and since that is what is triggering when I don't want it to, it would probably still trigger.