The main issue is that your sprites are rotated. You can select the lower leg sprite for example and mirror it in the layout editor - set width to negative value. You will see what happens to it.

You will need to rotate the images in some external editor and set their angle to 0 in Construct.

Also you need to disable Sine when the hierarchy is mirrored.

Here is an example:

https://www.dropbox.com/scl/fi/rhek2x89kjxmqzgxofrl8/test-mirror2.c3p?rlkey=gxnmbm5x4hlbqdd4um0mv4xlk&st=1skir0ja&dl=0

Thanks a lot!

That is a viable solution. But what if we prefer to keep the original sprite orientation? I found that we can offset the angle somehow (i.e. as if it was rotated in the sprite editor) by using Set Angle = -Self.Angle, but it works only for the arms and hands.

dropbox.com/scl/fi/tqlbp3wewbwd9i8tokewh/test-mirror.c3p

Thank you.

as well as co-operating with addon developers to ensure the v2 SDK covers all features where reasonable and feasible

This is key. Ashley Please prioritize the requests of the addon devs. Maybe allow them to have a sub-forum or a special flag/section in the github feature request repo.

Instead of complaining, I would request the features I need to port my plugins, and see how helpful Scirra is going to be with that, if they are true to their word.

Ashley As a user, addon devs were solving some major problems for us, which gave confidence for more users to rely on C3. Some of the -soon broken- plugins are already used by many users, so I would request prioritizing helping them. You can treat that as working on new features for the next couple releases?

Maybe make a script that analyzes the listed addons and pinpoint the deprecated API calls in the code, then notify the owner. Make their lives easier. It would benefit everyone as much as (if not more than) adding new features to the engine.

Addons are "already" in use, so helping them stay in use is as important as the backward compatibility you always talk about.

In general, for game engine software, Unity, Unreal, Godot all have plans that allow for their internal engine source to be accessed

The addon devs have done a tremendous job to keep C3 updated.

If devs have full access to the source, I doubt anyone will pay Scirra anymore!

If the api is hidden, no one will be able to make workarounds or custom features.

I hope the sdk v2 is a step towards a middle ground.

And to be honest, in the previous thread, some developers were willing to update their addons using unsupported apis, but now when v2 is released they are not willing to port their addons.

This is the reality. No one has time for this sort of thing. So while the addon devs will invest a lot of time porting their addon, Scirra will keep them supported as part of the official api, so the devs won't have (hopefully) to maintain them as frequently as before.

As a professional developer, some clients had old C3/2 games (maybe bought online) with long-gone addons and were asking me to spend unreasonable amount of time porting them or making similar functionality. I think sdk v2 is a step in the right direction, but it is not enough yet.

It's not easy to support npm in Construct as it runs in the browser without any involvement of node. If you can get a library you want packaged in a manner suitable for using in a browser, it should work in Construct too. So usually the trick is to find some browser-compatible package of a library.

Is it possible to support npm in the future? The number of SDKs (social media integrations, ..etc) increase every day and it is not feasible to ask the C3 team for plugin for each sdk.

My main focus is HTML5 games.

I feel there are 2 main points that keep repeating:

- Advanced users want the assurance they can keep doing what they are doing,

- While C3 team want the right to remove these features at any time.

Basically, the team is saying: "you can spend a lot of time on something that we can (probably will!) throw away at any time".

afaiu, Ashley the problem is that the team is trying to make a blackbox engine using a technology that doesn't support encapsulation well..

But modifications will never stop, even heavily-protected software gets modded, eventually. We need a better alternative: a more flexible and integrated SDK.

I would suggest a system to separate Safe and Unsafe addons. When a user installs an addon that uses internal code, the user gets a warning. Basically: "Do not rely too much on this addon".

(This way, C3 team doesn't have to fight with the advanced users, and instead puts the responsibility on the end-user).

What I find hard to understand is: if C3 had a better SDK, why would someone want to use a feature that is subject to change?

Some users treat C3 as if it was a local (client-side) engine where they can have their own custom modded copy, but I don't think this is what Construct is trying to do.

Maybe if the SDK tools are reliable and flexible enough, you can start obfuscating the internals.

Almost any popular engine nowadays has proper extensions/plugins. If the main concern is the engine reliability a decade from now, I would suggest to improve the SDK tools please.

It will take a lot of the load off your small team, earns you money from store items, and allow advanced users to make cool stuff with C3.

Win-win for all, yet it is not prioritized.

Sometimes I wish I had the flexibility of Unity editor hacking; where from the editor itself I can create scripts to automate my work, and can package some objects+code to make a plugin and share it easily with others. (i.e. export part of my project as a standalone package, directly from the editor).

The future is for engines that can be easily extended (whether open-source or not, with proper tools this can be done).

Update for 2024: we are moving the suggestions platform to GitHub! This allows filing suggestions in a similar way to bug reports, and it uses the same account system. You can find the new place to submit suggestions here:

https://github.com/Scirra/Construct-feature-requests

Please note we plan to continue to reset all suggestions every year.

Also note the old suggestions platform based on aha.io will be shut down in the near future. We will continue to maintain its existing content up until March 1st 2024. At any time beyond that the old service may be shut down. Be sure to preserve any content you want from the old platforms by that date.

The original post has also been updated with this information.

Ashley I care about C3 and my ideas, but I think copy-pasting 40 ideas is too much! Some of my ideas have many votes already, how would that be transferred?

Could you please consider the following suggestion:

1. Prevent people from posting any new ideas on aha.io

2. Keep implementing ideas from aha.io for 1 year.

3. Archive aha.io after 1 year.

Also please consider tagging ideas that are unlikely to be implemented, so we don't copy-paste them to the new platform and they get shelved either way ..

Some community members have spent a lot of their work time to post these ideas, so please consider valuing their time and effort.

I've read that aha.io has an API, please consider exporting the current relevant ideas to github using a script or something.

It might not be a "perfect" solution, but I think it is a compromise between your team's effort and the community effort. After all, most people will find it daunting to copy-paste their ideas every year, and it is a loss for the product on the long term.

Thank you.

Hello,

I have an object, when I click a button, the game applies impulse force J to it.

I want to predict how it will move (assuming no obstacles, and 0 friction) over time. Ideally a formula like this:

x(t) = ...

y(t) = ...

Currently I found an iterative approach:

(dtt=0.1, vx0=400, vy0==-500)

The problem is calculating ay (acceleration in y direction). I couldn't find a formula for it, but I used a hack by calculating the ay of the Ball object (which is moved by the engine), then plugging that value in ay (the value was 500), the method worked, and the created Mark objects resembled the true trajectory of Ball.

Notice that I set vx0 and vy0 manually instead of using forces and impulses; because I couldn't figure out how the forces work, so I simply applied the ipmulse to the Ball then got those values from the debugger and used them as vx0,vy0!

The questions are:

1- Is there a better way?

2- How to calculate ay given the initial velocities vx,vy? (i.e. before the ball moves)

3- Any idea how the x(t) and y(t) equations will look like?

4- Is it possible to use the impulse J, calculate the resultant force F, then calculate vx,vy of that force?

Thank you!