>

> or perhaps an action to record gameplay directly in C2 like some emulators do but I do not see that hapenning anytime soon.

>

Check out the user media plug.

I would be careful with that, as a self proclaimed "fanboy" of the canvas recorder I have to say that it's not very stable right now.

Although VP9 recording got fixed by Ashley a few weeks ago, there are still bugs left like for example bloated memory use and even crashes when using NWjs (32bit).

Finding a fix for those (bug-reporting to the browser vendors) is my task now though, as it seems like C2 is not at fault.

It works fine with NWjs 0.18.1. I have no flickering any more.

0.13.x - no flickering

0.14.x to 0.17.x - gives flickering

0.18.x - no flickering

I tested it only for around 10 minutes, but usually it started flickering within a minute, so I'm pretty sure it's fixed.

I think you got a game on Steam right (congrats btw), might want to check out their reviews.

The more different setups we test this on, the better we can identify and hopefully find a fix for this bug.

I rolled back to 0.13. No flickering.

I'm not on Ashley's level when it comes to things with the web but I've had similar issues to this one in the past with native software and directX.

For me this all sounds like there is something terribly wrong with the drivers, this doesn't necessarily mean that you guys are at fault.

No, it might be more of a bug from NWjs's side of things, however if that would be the case then you'd also experience this in Chrome itself.

I would like to request a basic example.capx where this bug is occurring so that I (and maybe others) could investigate it.

If you got some free time, I'd very much appreciate if you could share the following helpful information:

• Basic info about your graphics and cpu drivers
• Any 3rd party plugins that you use, even if they don't seem to be related to this
• The content of all 3 package.json files found in your nwjs folder (X:\xxx\Construct2\Construct2-Win64\exporters\html5\nwjs) You can upload those files to make things simple, they are just about 3KB big.

What you also could do right away is to clean install the latest version of NWjs.

At first use the uninstaller and then go back to the actual folder and delete everything that's left (nwjsforC2 folder only).

As useless as this sounds, I had my fair share of "experiences" with NWjs and I got them fixed by exactly doing that twice already.

Thanks for your time and looking forward to the helpful information.

You might be able to achieve different font colors by using the "Set Color" effect.

It will not help you for the case of changing single chars though and that's what you're looking for I guess.

Godot's visual scripting appears to be one of those 2D flowchart type systems, which are very different to events. They also quickly turn in to a mess, which they seem to have already noticed themselves

I also saw that tweet yesterday, didn't bother mentioning it tough.

Have you ever tried the Editor? It's far from as easy to use as Construct's in my opinion...

I think there's always a tendency to look for the "perfect engine". It happens on every user forum of all the mentioned software packages that i've ever been to. There are always things that could be better or optimized etc. I think there are a lot of people who never start actually making a game, because they keep looking at different game engines every other week. I know i had that problem for much too long. In the end what counts is, which tool makes you actually realize your project the quickest and most convenient to you, which is very subjective. For me PERSONALLY i really always came back to C2 because i didn't see any other program, where i could get something done so easily and still remain a great deal of flexibility. So i'll stick around for sure and i'm looking forward to see what C3 will offer

I've tested one of the older versions, the version that came with their Steam release to check out what it has to offer besides 3D support.

If I had to define what "easy" means, for me it's basically meaning that I can understand the use of the engine with just a little effort.

When I started it, I could easily identify all the core elements (e.g. scene editor, behavior systems ...) of the engine without opening up their documentation.

The only difference in comparison was that C2 is using eventing instead of programing so in their case, that was the point were I was forced to open it up and check on how things are done. Might be worth mentioning that their custom programing language is quite similar to python and I knew how to program in python before I've tested Godot.

I think generally any kind of alternative to programing, flowchart or event based counts as "easy" and it depends on the engine if it looks messy or not.

Just compare CTF to C2 and you'll understand what I'm trying to say with that.

For me personally it's too late anyway, I'm too far in game development to change to a different engine and start all over again.

I'm not trying to say that it's "bad" to use C2, it's just that a lot of the limitations that I didn't know about before I've started working with C2, now reveal themselves.

Nah, I think Scirra should let them do the first step.

Would be good to see what those "praised" new versions/programs really have to offer.

Game Maker Studio 2

Does GMS2 also come with a visual scripting editor? I couldn't find any details about that.

ClickTeam Fusion 3

CTF was always more of an "ugly" version of C2 for me, If they plan to clean it up a little for their 3rd version, it might be a serious competitor.

Spark (Full Release)

I've lost all the hope I got about Spark, I think it's either going to be dropped soon or come out within the next 5-10 years.

Godot 3.0

Now Godot 3.0 is something that Scirra should really worry about, not only is it open source (FREE!) but it could also easily compete with C2's editor in terms of usability. The major thing that was kinda missing is the visual scripting editor. Now it seems like it's about to be added, this might be interesting to follow.

EDIT: Of course there are also other problems and errors that need to be fixed too.

SuperPowers 3.0

Superpowers looks like one of the many script based game engines that you can find on the Internet, nothing to worry about IMO.

These are just my opinions about the competitors, if you disagree or want to add something feel free to do that below!

It's always nice to compare things and find out the dis/advantages that they might have.

Alright. I tried with --single-process and the game won't even run.

...

It's a known bug, I've already reported it and they've confirmed a fix in some of the future NWjs updates (probably v0.19.0)

I hope all of our worries about weird glitches using Steam + NWjs will be fixed, once we can make use of the single processing function.

As always, we have to be a little patient and everything will be fine.

EDIT: Sorry I missed that Silverforce already told you that, whoops.

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.

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?

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?

"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.

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.

Introduction:

This is going to be a large post but first I'd like to start off with saying hello to the Brashmonkey team and hello to everyone that is providing support towards fixing bugs and many more things.

My Case:

I'm currently working on a fairly large game and as a proud owner of Spriter Pro I can only say, thank you so much for making my and my artists life easier.

I recently decided to try out the new spritesheet feature because I'm getting closer and closer to the sprite limit.

So far my tests have all been successful and I was surprised that even char maps worked using the new method.

My Problem:

My game is using custom ragdolls (physics joints that connect the single sprites with each other making them "wobbly"), this feature was working fine with the old method and as you might already be able to guess, spritesheeting unfortunately breaks this feature of mine.

The Request:

I know this probably sounds easy from my perspective but I would like to request a custom ragdoll feature that you could perhaps turn on/off at will. I understand that this won't be as easy to implement as I think but I'm sure that if you'd implement this feature, you wouldn't only make me happy but also a lot of other Spriter + C2 users here.

Some Last Words:

Adding this feature in combination with spritesheeting would be a blessing and honestly it would calm down my fear of reaching the sprite limit for sure.

If you guys need someone to test it out (if it's possible), I'm willing to invest my time into it and surely all the other helpful people here will do it as well.

Thanks again for this amazing product and looking forward to hear from you guys.