I mentioned this in the past, and I think it is worth mentioning again since nobody seems to talk about it.. The majority of new users won't spend the entirety of the year using Construct3. They will probably only use it a few months until either a couple things happen; they become tired or frustrated with their game/project, they become distracted by other things in life. There will be several months where they don't use it at all. Several months where they can't make what they want because they need to learn how to use the editor properly, and still it will take several months/years to do things optimally if they even understand how to manage a project effectively at that point. At the end of their first year subscription, I don't see these people resubscribing. But maybe in Scirra's eyes at least they paid for one. However, I don't think these users will be entirely trusting to dish out $100 for the first year without first testing it adequately, and from my impression the free version is very limited. Sure, they could use C2 instead to get a feel, but generally speaking people want to use the latest version and probably won't even consider using C2 if they see that there is C3 which is being touted as being better.

So I understand why Scirra wouldn't want to allow monthly subscriptions for new users, because that gives those users a way out if they aren't satisfied after the first month or two- which is a realistic expectation I have considering my own experiences in the beginning. I just don't see how this model helps retain users. It just seems like it will push away people in my opinion.

At least with models where you pay once, you receive software you can use at your convenience and can work at your own pace regardless of whether you take several months off you don't feel penalized for it.

Scirra can argue that the reliance on browsers forces having to do maintenance, etc, and charging for keeping everything working with the changing browser vendors. Will these users understand that? I doubt this is something they would consider in their purchase (probably not the primary consideration), and if anything it might be more of a deterrent if they do because they'd realize that things can change whenever a browser updates.

But maybe that will improve over time? If it does then why the subscription model? If it improves, then maintenance will become lighter for Scirra. The subscription kind of gives the impression that the stability will never improve.

I received the same emails too. Says " was recently put back on sale as the payment for the exclusive version was refunded."

I got this email for all my items even though they don't have exclusives.

Ah! yeah, I just found that too! sorry for the confusion.

Thanks! works for me now

Well, the issue I have is that the Trigger occurs outside the flow of the eventsheet, so I can't get the path immediately in the necessary position of the eventsheet when it is called to calculate the path.

So if I have a condition that is met to create the path, I have to restart that flow of logic elsewhere, while other events get ran in the interim.

Using wait doesn't solve the problem, as that delays receiving the path to the next tick, causing the need to use confusing or complicated event management which causes event entanglement.

So I think having the option to synchronously calculate the path would be a great addition to the behavior. What I am doing isn't cpu intensive, as I am not performing it every tick, I just need the immediacy.

Is there a way to use this without the "on path found" Trigger?

I tried setting the the iterations to -1, forcing the path calculation, but the path doesn't become available until later. I need to be able to get the path synchronously.

Feels like my store items are being held hostage.. There's no time specified on the bundles as to when they finish. Also when I change the items so that they can't be bundled, it remains bundled..

Why no explanation?

yeah, being able to specify in the events where behaviors tick would make the most sense. It's ridiculous that their order changes like this.

If you aren't making anything too complicated, Construct is good. If you intend on making something fairly complex or medium scale, I would shy away from Construct.

My reasoning is based on a few things:

As your project becomes larger it becomes increasingly difficult to organize and manage your events, assets, etc. You have to be sure to plan everything out- so you'll need to be very adapt at construct in order to perceive potential issues down the line in development so that you can avoid them. This is the case with any engine, but construct has a very unique framework that you have to deal with, and it is often not suited well for organizing aspects of your project.

Performance doesn't seem to be that great for older hardware. I haven't tested anything on any new hardware, so I am suspicious of that too.

There may be a lot of gotchas or limitations, or bugs that you might come across that you may not normally have with other engines- and this is due primarily to the way Construct was designed, so you won't have any way of solving them. Or you may have to wait a long time for fixes.

On the other hand, there are a lot of good qualities that Construct has, with good reasons for using it. If you have lower expectations, you can find comfort in the ease of use the editor has, and be capable of creating a lot of different stuff fairly quickly. If you become more adapt at it, and understand what to avoid, you can realistically create a small to mid-size game that runs fairly okay. I've never seen a game made with construct that I would consider "large."

Store a value that represents whether you've pressed the key during the animation. Then check the value when the animation finishes- if it is set, then continue to next animation and reset the value. If it isn't set, then don't continue attacking.

alright, here's the link:

https://construct3.ideas.aha.io/ideas/C3-I-172

and for the behavior, in-case anyone is interested:

Cnds.prototype.CompareTilesAt = function (tx, ty, cmp, t)
	{
		var tile = this.inst.getTileAt(tx, ty);
		
		if (tile !== -1)
			tile = (tile & TILE_ID_MASK);
		
		var tileArray = t.split(",");
		var tileCmp = false;
		for(var i=0; i<tileArray.length; i++){
			if(cr.do_cmp(tile, cmp, parseInt(tileArray[i]))){tileCmp=true; break;}
		}
		
		return tileCmp;
	};[/code:1pyao95e]
as far as I can tell from my own uses, it works well.

yeah, that's an option, but still is not adequate in my opinion.

In my case, I just added the ability to specify multiple tiles via a string "0,1,2" to a custom Behavior (I created a behavior where I just add stuff that is missing from c2).. So now I can do it in a readable fashion. This should be made available by default though. I submitted the suggestion to their suggestion thing.

There definitely should be a simple way to provide multiple values to check. I've needed this in the past numerous times. Current methods aren't that satisfactory for me due to the complexity it introduces to the eventsheet. :\</p>