Hey matpow2, sent you an e-mail yesterday about a serious port request for a relatively ambitious C2 project, but based on previous experience it's possible it ended up in your spam or something (perhaps because it's from a unique domain name), so if you don't mind checking for it and letting me know if you didn't get it, I'd appreciate it!

How long might a port using Chowdren take, assuming a close-to-average workload? (Not including publishing times on consoles, which can take 2-3 months based on personal experience)

When should we be contacting you about this so that you have a chance of responding to our proposals? Are you only interested in completed games? Perhaps only games that have already sold well?

I’d really like to figure out some kind of timeline for porting our game (one of the most ambitious C2 projects out there), but since I haven’t heard back from you I’m not sure if I should be looking into a joint effort, commercial license, another porting company, or just porting it myself (what I had planned on doing before finding about Chowdren, which seems like it’d save me a lot of time/effort while also making you money).

Please advise if you can. Thank you.

For my previous issue where triggers were playing when they weren't supposed to (at the beginning of an animation), I came up with a hacky fix if anyone needs it until a proper fix happens (if ever)

In runtime.js on line 2737 in version 12-26-2016 where it says:

if(t>0&&t<1)

{

this.playEvent(eventline,eventline.name);

}

Add "&&this.currentAdjustedTime>20" to the condition which just doesn't allow any events to trigger in the first 25 milliseconds, basically... which could potentially be a problem, but for me it's a better alternative than having the game glitch at times.

You'll need to do the same things for sounds too or they'll have the same problem as the code is basically the same.

I still don't know why the event is being triggered in the first place, but this problem cuts it off towards the end, like a filter, rather than properly fixing the problem at the source, so I don't recommend it if you don't need it. (Also keep in mind how editing runtime.js files work, the devmode registry key, etc. when messing with this stuff)

---

To debug this, I looked through the foreign code for a while, and eventually tried commenting out a line, found it solved the problem but introduced other bugs, and then used a log message (log("[Construct 2] Event call at time " + this.currentAdjustedTime + ".", "warn");) to see when events were being called, confirmed they were happening when they weren't supposed to (usually in the first 10 milliseconds, so the chosen 20 just gives it some padding), and used the most straightforward solution to fix it.

I think the real issue has to do with not clearing the state of the timeline or something like that when an animation is changed mid-way (i.e. doesn't complete itself), but I couldn't figure out the code myself so I still don't actually know... but since the duplicate trigger always happens right after the animation starts (probably the first tick after?) idk what else it could be but some false trigger from a previous animation or something.

> I've made a complicated input system before.

>

> The basic idea, at least behind how I did it, is that you record inputs (e.g. in a queue) and every X seconds, read those inputs and have an action occur because of it.

>

> The input window should probably be around .10-.15, if it's too small then what happens is, let's say you need to press A and B at the same time, or Down on a control stick and the X button at the same time, if they aren't on the EXACT same frame and you just do a check, it won't work.

>

> If you do stuff like wait commands, it can get a bit messy when people press multiple buttons at once, among other scenarios... maybe it can work but I don't think I even tried, I couldn't really imagine how it would.

>

> For reading inputs, you probably need to differentiate between directions and buttons. So you don't just want to say "what was the last button pressed", but more like, "what were the last 3/4 directional inputs, and the last 2/3 button inputs, and in what order".

>

> That way you can see, okay, they did down, down-right, and right, in that order, this is a quarter-circle forward, and then they pressed B and A, well A was the last input so we take that one. Or maybe you want them to press two buttons at once, so you can read that, or maybe you only take their first input. There are lots of different possibilities.

>

> Rather than a wait command, I would start a Timer whenever an input is received (again, for maybe .10 seconds, it means there is a small delay on the inputs but it's almost unnoticeable and even professional games can have small delays like these), and then once the timer is done, you read the inputs.

>

> Another thing is that, instead of doing:

>

> "on press A, do this"

> "on press left and A, do this"

> "on press right and A, do this"

> "on press B, do this"

> "on press left and B, do this"

> "on press right and B, do this"

>

> you now have

>

> "on press A, record A"

> "on press B, record B"

> "on press left, record left"

> "on press right, record right"

>

> Read/execute input one time.

>

> You see how I reduced 6 checks (redundant left/right input checks) to just 4? And the more you have the more the reductions add up. Then you only need to check for each button input once, and you just have an I/O-like system to do things based on the inputs.

>

> Coding it can be a bit difficult but it's part of game development/programming in general (C2 might not be script-based but programming knowledge is still extremely useful, if not basically required IMO, at least for more complicated things), action/fighting games can be especially hard in this sense, so yeah. Good luck if you choose to try it.

>

So this will be harder than what we had thought xD

Maybe, but if you design it on paper and then implement it bit by bit, it's actually not too bad. Start with doing it for one button, maybe, and then go from there.

Like basically anything in game design though, it'll take some time to get fully polished, yeah.

I noticed that C2's save and load function doesn't store Spriter object scale or animation speed.

I think this issue is also a thing with the direction of the object, as I've had objects facing the wrong direction once reloaded.

My solution was to have an instance variable on the object (and all spriter objects are conveniently in a family, so I only need to add it once), and upon loading a save, it overrides the way they are facing based on the direction value.

I imagine you could do something similar for the object scale and animation speed, the only downside being that if there is no variable you can just access and mirror, you have to manually keep track of it.

I suppose it might not be too hard to fix this issue from the source but I kinda don't want to mess with the Spriter plugin in case it's updated again later. There's also Mike's solution, which I didn't really understand when I gave it a quick read, but it probably works.

-------------

Anyway, I want to report a bug, but like with most obscure bugs, I don't know exactly what causes it to occur or else I could replicate it in my own CAPX.

In short, sound effects and event triggers in Spriter can activate multiple times in C2 when their easing curve is set to linear (the default)... but, this won't usually happen. It only seems to happen under some obscure scenario that I cannot pin down despite constant testing.

Setting the easing curve to instant seems to fix it, but I can't imagine an event or sound trigger would ever *want* functionality like this, so... yeah. As far as I can tell, the way to cause it is something vaguely like this:

• Play an animation with a sound/event trigger
• Interrupt this animation mid-way (before it is completed) with another animation, or maybe interrupt it with another animation mid-way (the latter seemed to be more consistent with the glitching), not sure
• Play the 1st animation again?
• Interrupt the animation as before, and the sound/event trigger will activate on the first frame or the millisecond after or something like that.

Again, this is just a general idea, I do not know how to actually, consistently reproduce this glitch. Should you want to fix it, you may have to try some random variations, all I could see in common was that animations were either starting mid-way or ending early and that the easing curves for the offending triggers (NOT the keyframes they belong to) were set to linear.

If I have time to play around and figure it out, I will try, but I had to spend a while just trying to figure out how to fix my sound effects seemingly randomly playing 2-4 times, so I'm kind out of time to debug the underlying cause, especially since I don't really understand how easing curves work in C2 for me to guess at why it'd affect the sound/event triggers.

EDIT: Seems I'm actually still occasionally getting the bug, but less than before. Still don't know why. :\</p>

I've made a complicated input system before.

The basic idea, at least behind how I did it, is that you record inputs (e.g. in a queue) and every X seconds, read those inputs and have an action occur because of it.

The input window should probably be around .10-.15, if it's too small then what happens is, let's say you need to press A and B at the same time, or Down on a control stick and the X button at the same time, if they aren't on the EXACT same frame and you just do a check, it won't work.

If you do stuff like wait commands, it can get a bit messy when people press multiple buttons at once, among other scenarios... maybe it can work but I don't think I even tried, I couldn't really imagine how it would.

For reading inputs, you probably need to differentiate between directions and buttons. So you don't just want to say "what was the last button pressed", but more like, "what were the last 3/4 directional inputs, and the last 2/3 button inputs, and in what order".

That way you can see, okay, they did down, down-right, and right, in that order, this is a quarter-circle forward, and then they pressed B and A, well A was the last input so we take that one. Or maybe you want them to press two buttons at once, so you can read that, or maybe you only take their first input. There are lots of different possibilities.

Rather than a wait command, I would start a Timer whenever an input is received (again, for maybe .10 seconds, it means there is a small delay on the inputs but it's almost unnoticeable and even professional games can have small delays like these), and then once the timer is done, you read the inputs.

Another thing is that, instead of doing:

"on press A, do this"

"on press left and A, do this"

"on press right and A, do this"

"on press B, do this"

"on press left and B, do this"

"on press right and B, do this"

you now have

"on press A, record A"

"on press B, record B"

"on press left, record left"

"on press right, record right"

Read/execute input one time.

You see how I reduced 6 checks (redundant left/right input checks) to just 4? And the more you have the more the reductions add up. Then you only need to check for each button input once, and you just have an I/O-like system to do things based on the inputs.

Coding it can be a bit difficult but it's part of game development/programming in general (C2 might not be script-based but programming knowledge is still extremely useful, if not basically required IMO, at least for more complicated things), action/fighting games can be especially hard in this sense, so yeah. Good luck if you choose to try it.

Original project link unavailable so closing.

> It seems like it doesn't account at all for multiple fade behaviors—it triggers stuff based purely on the object instance the Fade behavior belongs to

>

You're right, this sounds like it would explain it from the description, and it's an architectural oversight more than a bug. The proper fix would involve re-architecting all behavior triggers which would be quite a lot of work, and possibly cause compatibility problems with third-party behaviors. So I think it would be easiest to fix this in the upcoming C3 runtime which is being rewritten anyway.

I'm not sure why you'd want to use two of the same behavior anyway - why not just adjust the settings of one?

Whoop, didn't think the link would die out, sorry about that. Though you responded anyway, so it's not a big deal.

Yeah, it's not a bug per se, just intended to work differently than what I expected. Sorry if I worded any of my posts poorly. I understand the situation and as you implied, I think a C3 adjustment would be the best course here, it's not a problem that can't be worked around in C2 and it's not a simple fix per se, nor is it an issue of much significance.

As for the answer to your question—ease of use/organization.

Let's say I have an object that fades in and out, each at 2 different speeds, meaning there are basically 4 ways it could fade. For each given fade, I could set all the values first before fading, but this would get a bit tedious/cluttered if I call a given fade more than once.

I could then put it in a function to fix that, but then I need to write (preferably using local variables) and call said function before every fade, and I'd rather have that information preset as part of the object/behavior since I'd be able to find it easily, rather than having to look up and edit a function.

Since I can rename behaviors, I thought it effective to name each Fade based on the type it is (e.g. "FadeIn", "FadeInQuick", "FadeOut", "FadeOutQuick"), then just call said fade, thus making it clear what kind of fade is happening, without adding the extra work/clutter of fade functions—C2 lets me set the values to start, anyway.

I'm not sure if there's a notable overhead for having multiple fade behaviors like that, but I can't think of any reason there would be. And if there's an easier way to do it than I've brought up, I apologize for having not been aware of it (and not coming up with it myself).

tl;dr, the issue could easily be considered a matter of convenience/organization and not essential, but might be appreciated in C3 should you find the time. Thank you kindly for responding and for your support.

Cool plugin, helped a lot with something I wasn't sure how I was going to tackle. (At least, not without a lot of struggling, haha.) Glad it has tag functionality too, I did some string-crafting of sorts to pass info about the path being checked through the tag and I'm not sure what I would have done without it, lol.

That's all I got for now, just wanted to share my appreciation for it. Maybe I'll have a question with it later though~

yeah exactly, it's just that it adds up when you have a lot and if I forget it could be problematic haha, it's not bad individually

well for a work-around you'd start the fade and set a flag and then in your OnFinished, just check the flag as well and that's how you'd manually figure out which fade had finished. You'd create a bool for each Fade.

Yeah that's what I did, it's just a little confusing to manage that for each one in a big project like mine, haha.

Getting an error when playing sounds related to Spriter, curious if anyone else has got this error and if so, how they fixed it/if they know anything, before I spend too much time trying to debug it myself.

When I disable this code:

The error no longer pops up. Given the error message, it seems to have to do something with an invalid input type, but I can't really make enough sense of it to get an actual sense of where I should be looking for potential errors.

(Not looking for an actual solution, just advice if anyone has it)