Spriter/C2 update 11/2 bug fix for performance mode

Discussion and feedback on Construct 2

Post » Thu Oct 27, 2016 7:00 pm

lucid wrote:@TheRealDannyyy is there anyway you can use the Override Object Animation action to tell each sprite where to be while in ragdoll mode?

I guess it would be possible with the use of heavy maths and a lot of events which could easily bloat the memory use.

Sorry, I get the use of the action in general but I think that would be a little too advanced for me to handle compared to my current method.
My current way is to create a family with all sprite parts and give them the "chipmunk physics" behavior which has a more advanced pivot joint feature.

Could you perhaps create a small example so that I could get a better understanding?
I'd appreciate the effort and thanks for the quick response.
ImageImageImageImage
B
40
S
11
G
42
Posts: 467
Reputation: 24,482

Post » Fri Oct 28, 2016 1:02 am

"chipmunk physics" behavior?
Spriter Dev
B
87
S
21
G
12
Posts: 3,240
Reputation: 16,461

Post » Fri Oct 28, 2016 7:43 am

lucid wrote:"chipmunk physics" behavior?

It's a fancy name for a more advanced physics behavior inside C2. (HERE)
HERE is an old topic of mine about that, it includes a basic unfinished but working example of my method.

So, I'd like to ask again if you guys would consider adding a feature like that or should I keep on going with my currently old Spriter importing + ragdolling methods?
It just feels like we've talked more about a workaround than my actual request, which isn't wrong of course. ;)
ImageImageImageImage
B
40
S
11
G
42
Posts: 467
Reputation: 24,482

Post » Fri Oct 28, 2016 8:17 am

TheRealDannyyy wrote:
lucid wrote:"chipmunk physics" behavior?

It's a fancy name for a more advanced physics behavior inside C2. (HERE)
HERE is an old topic of mine about that, it includes a basic unfinished but working example of my method.

So, I'd like to ask again if you guys would consider adding a feature like that or should I keep on going with my currently old Spriter importing + ragdolling methods?
It just feels like we've talked more about a workaround than my actual request, which isn't wrong of course. ;)


Why do you just divide the objects that you want the physics on into separate parts and scmls to be inserted into C2 and combined them back with behaviors, instead in a singular scml?
That way, your old methods still work without too much effort.
B
36
S
18
G
11
Posts: 248
Reputation: 8,694

Post » Fri Oct 28, 2016 8:21 am

Sethmaster wrote:Why do you just divide the objects that you want the physics on into separate parts and scmls to be inserted into C2 and combined them back with behaviors, instead in a singular scml?
That way, your old methods still work without too much effort.

I think I don't understand you quite well, you want me to import ~12 different spriter parts and connect them with each other?
How would the spriter animations still work if I use different scml files anyway?
ImageImageImageImage
B
40
S
11
G
42
Posts: 467
Reputation: 24,482

Post » Fri Oct 28, 2016 10:02 am

TheRealDannyyy wrote:
Sethmaster wrote:Why do you just divide the objects that you want the physics on into separate parts and scmls to be inserted into C2 and combined them back with behaviors, instead in a singular scml?
That way, your old methods still work without too much effort.

I think I don't understand you quite well, you want me to import ~12 different spriter parts and connect them with each other?
How would the spriter animations still work if I use different scml files anyway?


That's the best way to go with it if you want results quickly and work on other features instead of waiting for something that might take weeks to months to materialize.
Yes, you have to rebuilt all the animations for each part in new scmls for separate parts. Easier than imagined since you already have all the important details in your original scml. Tedious but doable in several days.
B
36
S
18
G
11
Posts: 248
Reputation: 8,694

Post » Fri Oct 28, 2016 12:36 pm

Sethmaster wrote:That's the best way to go with it if you want results quickly and work on other features instead of waiting for something that might take weeks to months to materialize. Yes, you have to rebuilt all the animations for each part in new scmls for separate parts. Easier than imagined since you already have all the important details in your original scml. Tedious but doable in several days.

I've never said that I want this feature in a few days, infact it can even take up to a year if it has to.
So far the workarounds are mostly more difficult or tedious than my actual method, which leads me to believe that there is no "better" way to approach this.
Anyway, thanks for the idea Sethmaster.

I really hope that Brashmoney will revolutionize 2D Construct games a little further on this end, I don't see any negative aspect about this TBH.
It's already a standard feature that comes with the most 3D game engines, so why not make it a standard with 2D engines as well? ;)
ImageImageImageImage
B
40
S
11
G
42
Posts: 467
Reputation: 24,482

Post » Sat Oct 29, 2016 5:32 pm

@TheRealDannyyy - yeah, it's a bit outside the scope of Spriter to handle physics and and collisions. I think the best alternative would be to create the joints based on the Spriter bone positions. I don't have time to look in depth into chipmunk physics at the moment, but one thing I've considered adding and might be able to add (probably not too soon) is a hierarchical 'for each bone' condition that would loop through the base bones, and then each of their children, etc, and corresponding expressions to give you the 'current child bone'/'current parent bone' type info. Would that be helpful?
Spriter Dev
B
87
S
21
G
12
Posts: 3,240
Reputation: 16,461

Post » Sat Oct 29, 2016 6:34 pm

lucid wrote:@TheRealDannyyy - yeah, it's a bit outside the scope of Spriter to handle physics and and collisions. I think the best alternative would be to create the joints based on the Spriter bone positions. I don't have time to look in depth into chipmunk physics at the moment, but one thing I've considered adding and might be able to add (probably not too soon) is a hierarchical 'for each bone' condition that would loop through the base bones, and then each of their children, etc, and corresponding expressions to give you the 'current child bone'/'current parent bone' type info. Would that be helpful?

It's hard to tell right now, it might help but I think I will just keep on going with the current method and unfortunately skip the use of the new spritesheet function.
However if there are any news about this in the future, I'd appreciate a tag. :)
ImageImageImageImage
B
40
S
11
G
42
Posts: 467
Reputation: 24,482

Post » Wed Nov 02, 2016 4:25 pm

new version

11/2/2016
  • Fixed a bug where default pivot points weren't working with the new self-drawing/performance mode
Spriter Dev
B
87
S
21
G
12
Posts: 3,240
Reputation: 16,461

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: edisone, heatoneGR, iyenal222, pablo7 and 13 guests