This sounds exactly like what I want.

I'm using the system to simulate fog of war. If I have only one actor, the current system works just fine, I just pin a light to the player character and the obscured areas are out of LOS. Combined with the LOS plugin, this makes for an effective system.

The problem is when you are controlling a team/multiple actors. The solution seems simple enough: just pin a light to every actor. It sounds like a design problem that shadows take precedence over light.

You get a very unusual pattern of scattered black triangles in odd places, which just so happen to be the intersection of shadow for all three lights

The intersection of all shadows, in this context, means none of your actors can "see" in that spot, therefore it should remain black (obviously black polygons are weird, but nothing that a bit of semi-transparency can't fix).

It should be clear that, in this mode, light sources need a "maximum radius", to simulate a maximum LOS distance.

To be fair, there's nothing stopping javascript from reading XML, regardless of platform. It's just text anyways.

qual a quantidade máxima de events suportado pelo construct 2 ?

what's the maximum number of events construct 2 supports?

"tassio franca" Tassio, não poste em português nesse forum. Existem outras comunidades brasileiras sobre construct 2 (lista: http://www.scirra.com/communities), e se nenhuma delas atender, pelo menos poste uma tradução junto com o post, nem que seja pelo google tradutor.

Above message translated:

Tassio, please don't post in portuguese in this forum. There are other Brazilian construct 2 communities (list: link), and if none of those help you, at least post a translation with your post, even if you have to use google translate.

These are the only the only serious blocking features that need to be addresses on the C2 IDE side. Many requests can be done by anyone who is willing to actually do the heavly lifting to get work done. As an example if TileMap isn't good enough. Someone can do it themselves. However we can't make a plugin for say Modularity or an IDE based asset repository. There are some IDE elements that would be nice or could use clean up, but that's pretty minimal and will come with time. So below are my personal tops.

Modularity

Asset/Repository

APK Packer

Development device pushing for testing

Custom IDE development for tools(ie bezier curves for animation tweening)

Function used a primitive similar to Number, String rather than as a plugin.

Agree with everything you said. Also I'd add that dictionary and array should be primitives as well.

Shouldn't it be 500% the first time and 200% the second time? Otherwise you end up with a 2500% stretch

Thinking a bit more about it, I guess even if you run a short course, 83 cents per student can be easily absorbed. Besides, it benefits the student since he'll be able to continue using the software even after his course ends, which is only fair - I mean, after you just "graduated" from your short gamedev course, the first thing you want to do is pump out a few games, and having a few extra months to do that on your student license might be just the thing he/she needs before making the full purchase.

Tl;DR: yearly licenses make sense.

There's still no technical explanation whatsoever and a ton of management speak disguised behind a facade of "happy customers". There are no happy customers.

I'm disappointed in you forum mates, just because a company rep came here, suddenly it's all sunshine, happiness and lollipops? I haven't seen any technical documents and people are already clamoring for "integration with c2".

I still stand by my skepticism. This still sounds like a scam.

Love the idea. I'd also love heavy moderating in said forum, in the form of mods enforcing the questions being "advanced", moving the beginner stuff to other sub-boards.

Great news!

"up to once per year"...? What about semester courses? Aren't those more common than yearly courses, especially for something like game development?

Also, the ways you are describing counters sound more complicated than it was in MMF. However, that might simply be because I am fairly new to the program and haven't explored enough.

Trust me, it's a lot better. Once you learn the way construct 2's event system works, you won't be able to go back to MMF's "checkmark" system. They look really similar at first glance but construct's is so much better...

Also don't forget, I also mentioned Interface Bar. To clarify that is NOT a default MMF extension, it's the equivelent of a 3rd party plugin. But it has served me quite well in my days of making games with MMF.

You could just have a premade gradient and stretch or clip it via WebGL.

Sorry that clickteam is going to hell, according to you. While I cannot completely verify what you said, it sounds believable based on my experience with them.

I have like 10 years experience with clickteam, I started way before MMF1.5 with Click'n'Create/MMFX.

The only thing MMF has going for it is performance and better extensions, as well as support for application development.

The SDK is a load of garbage, though, official updates move at a snail's pace (see for yourself, their "patches" come once every 3 months, and "new features" every 5 years), besides, most of the things they call "features" are things that should have been in the software years ago.

I started bashing them when they started charging for "unicode support".

now they released Game Maker Studio, with laughable differences, for $99.

Don't forget that, if you want all exporters and features, it costs something like $500 (I don't have exact values). Meanwhile, UDK costs $19/month, and includes source code. Also, you only have to pay one month, if you stop paying you still get to keep the software and you can still publish, all you lose are the new updates.

I am sorry if I did anything in that other topic that was perceived as mean

We frequently have topics like the one you saw. Forum regulars quickly become tired, I hope you can see why. Some of them are made by people we respect, and when that happens we have a civilized discourse. When some new guy with 2 posts comes here and starts bashing, I have a lot less patience.

Counter objects are a holdover from the klick'n'play days. Construct 2 doesn't use them because we have instance variables (comparable to alterable values in MMF) as well as global and local variables.

For health bars, you can use the 9-slice object, as well as sprites with clipping, due to automatic and customized grouping. I don't know how you'd go about making a gradient, but I'm sure people can help you.

In regards to path movement, yep, we need one of those. I think there's a plugin that does it, though.

Clickteam only recently allowed discussion of other platforms - they used to censor other tools. There are basically no veterans over there anymore, and no one is successful, every half decent developer MMF had moved on to other platforms. I'm saying this from experience, I remember Fallen Angel used to be a pretty big name, now people don't even know who they were. Nifflas was the last big name to leave.

Their exporter strategy was a big failure, over half of them arrived too late, they all underperform, extension compatibility is ridiculous, there's no SDK, and a few have even been discontinued (j2me for instance, and soon the XNA as well).

In addition, Ashley's weekly updates have more features than what took clickteam years to code the 2.5 update was laughable. If clickteam doesn't get their act together with MMF3, they're pretty much gone.

I don't know much about game maker, but from what I hear, they're pricing themselves out of business, whereas much better tools like unity and UDK are getting cheaper every year.

As for construct's community, it has two good things going for it:

• Very good moderation
• An active, participating developer

Other than that, most discussions here are fairly moot and there are very few groundbreaking things happening as far as projects and demos. We have a handful of knowledgeable guys and 3 or 4 active community developers.

The text changes.