It's right there in the footer

Well I guess what I'm calling "not the complete path" and what you're calling "complete path" are the same thing.

I'm going to generate the particle normally (to get starting conditions), then project the path forward (to get end coordinates) based on:

• Starting x/y
• Angle
• Speed
• Lifetime

Then I'll either lerp it from end to start or shoot it backwards. I'll also lerp size, rotation and opacity based on what the user specified (taking into account that those values might hit their ceilings/floors before the trajectory ends).

Since the particle path is random and non-deterministic, the only way I can think to do this is to simulate a complete forwards path, then start at the end and play it backwards. That's not exactly a trivial change. I think perhaps it could be made in to a separate plugin.

Yup, that's exactly what I wanted to do, though I don't intend to simulate the complete path.

Also I know it's not a trivial change, it's not like you can just set particle speed to negative

Can I go ahead and modify the plugin to make my own "reverse edition" then?

This seems like it could be very useful - I'd modify it myself but since this is frowned upon, I'm making a feature request instead:

The particle object emits particles in a cone, with many settings such as growth over time, fade-out and so on. These are all deterministic, so why not allow it to emit particles in reverse?

That is, it would create particles in front of it and "suck" them in. There are many cool effects that could be achieved with it, as well as some interesting optimizations. I don't see any technical problems with it either.

Now, as I said in the beginning, I'm fully capable of implementing this. Question is, should I do it or wait for Ashley?

I've never had any issues visiting the scirra forums on my android phone either (besides that annoying bug where you don't stay logged in).

However, I've had plenty of issues where the "request desktop site" version doesn't work, the site refuses to serve content, instead redirecting me to a "mobile-friendly" home page, or where the "responsive" mobile theme lacked most, if not all, power-user features.

I say forget about optimizing the forums and keep everything as-is. "Mobile versions" are a blight in the web industry.

Oh god I hate "mobile-optimized" anything. One of two things inevitably ends happening:

Either the "mobile version" is crippled and we don't have access to all the features from the desktop version

or this:

What's wrong with zooming and reading in landscape mode?

Force = ForceFactorVariable * sin( 180 * hill.width * 0.5 / distance(ball.x, ball.y, hill.x, hill.y) )

You're in the right track, but there are a few caveats:

• This presumes the force gets stronger, linearly, the closer the ball is. What a weird hill! This is also likely to send the ball into the stratosphere if it crosses the middle (which would be even weirder if the hill had a tapered top).
• You need to take into account the steepness of the hill.

Personally, I'd just spread a bunch of invisible "force-applying" objects on the screen, creating a sort of "force map".

It appears you have two questions:

• Should I use WebRTC or WebSockets?
• How do I modify default plugins?

For the first question, we need to know what kind of game you're making. If it's a bullet-hell, use WebRTC. If it's a puzzle, use WebSockets. If it's a card game, use simple ajax.

For the second question, let's go point by point:

Multiplayer plugin seems to only support peer-to-peer, even though WebRTC is capable of following a authoritative server approach. Upside I gain UDP support, downside I lose the entire IE audience.

Peer-to-peer can be coerced into "authoritative server" by simply adding special logic that treats some predefined peer as an authoritative server. It's really quite simple, and you get the benefit of also connecting to peers, so you can send them non-authoritative data for a latency boost (and a lower bandwidth fee on your server).

Websocket plugin only allows you to send strings which would be a bit inefficient. I'd like to modify it to add ability to send custom datatypes.

Regardless of the datatype you send, it will get converted to strings anyways. Besides, construct doesn't support types other than string/number/bool natively.

Notice that you don't have to modify the plugins in either case.

I can't offer any advice for a gtx 750 ti, as I've never owned one.

In any case, you should be set if your card is even modestly young. Heck, I've had success with intel's crappy h55 (admittedly Intel has come a long way since the horrible integrated chipsets of old).

The most important thing I consider nowadays is triple-monitor support. Make sure the card can actually support 3 monitors, though - just because it has three ports doesn't mean it can run three monitors!

As for the setup, you're pretty much right, just go BIOS and select PEG (this is your card, it stands for PCI EXPRESS GRAPHICS). Remember to disable intel's card completely (in the bios) and plug your monitors to the right slot (again, your card, not your mobo). Then download the latest drivers and you should be set.

Considering the other system requirements, here are a few things to note:

• Dual monitors are better than single monitors, especially for construct (since you can code in one monitor and preview in the other). Once you go dual, you can never go single again. However, triple monitors are even better since it gives you a central point for your vision. When working with construct, I usually have construct on the left, brackets (a javascript editor) in the middle (since I sometimes create plugins, you don't have to do this), and chrome/firefox on the right
• An SSD is very nice, especially to cut boot times, but if your main use is construct, I don't know if I'd bother. They're pretty expensive, and only make a difference with i/o heavy applications (such as photoshop, AfterEffects, AudaCity). If you're going to use the PC for gaming, SSDs cut loading times by a lot, but they don't do much else.
• If you're like me, you'll want to have a load of programs/tabs open at once, so you might want 8Gb of ram instead of 4Gb. Ram sticks are pretty cheap. If you have a choice, go with the biggest sticks you can grab (to give you room to upgrade), but get at least two sticks (so that you can dual-channel). I.e.: 2x4Gb is better than 1x8Gb as well as better than 4x2Gb.

I don't get what you mean either, ASHLEY.

With intel's i3/i5/i7 series, all you have to do is go into the bios and select PCI EXPRESS GRAPHICS, that will completely disable the integrated H55 chipset, right? Cause otherwise gamers would be furious and flocking to AMD since intel would be gimping their system.

Either I'm missing something, or you misunderstood the OP (hint: he's not talking about SLI or Crossfire).

My advice is go for AMD graphics card and not nVidia, Your choice

My advice is the opposite, go with nVidia: AMD suffered from poor drivers in the past, especially in regards to OpenGL (which is what makes WebGL work).

• License changes from "Per Project" to "Per Developer". Makes more sense for this category, buy once and use in any projects you're developing forever.
• Max price $5 USD. Current plugins are in the £15 - £20 range which we are not comfortable with. This is a significant % of the cost of a Construct 2 License. We're happy to allow plugins for a higher price than $5 USD but only with special permission and if we think it's justified. We also don't want potential customers for Construct 2 browsing our store and thinking that they will be locked into or tricked into having to buy expensive plugins once they own a license.

Those are massively discouraging words. I thought the store was supposed to be a viable way to generate income... there are so few coders in the community, is a developer's work really that cheap? Seriously, did Scirra forget Tigerworks already? Making addons is hard work!

Let's explore the differences between asset and addon creators:

• Audience:
  • Addon: Limited to construct 2 owners, since addons don't work anywhere else
  • Asset: Unrestricted. Addons work with all game creation software (MMF,GM,Unity,GameSalad,etc), as well as custom engines.
• Skillset:
  • Addon: Must know how to program (which technically means you don't even need construct). Must learn the SDK. Work produced is only applicable to C2 and doesn't work anywhere else.
  • Asset: Can recycle your old work, as well as sell said work in many other asset stores.
• Price:
  • Addon: Maximum price is $5 (and that's probably before scirra's and payment processor's cut). A single chargeback eats the profits of at least three sales.
  • Asset: Unrestricted pricing.
• License:
  • Addon: Per developer instead of per project. This means each plugin can only be sold to a user once. Depends on a steady flow of new users to remain profitable.
  • Asset: Per project instead of per developer. A user can potentially buy as many licenses as he/she has projects.
• Support:
  • Addon: Breaking changes means new versions have to be tested for compatibility and quickly fixed, or else you'll get a swarm of angry users and a reputation hit.
  • Asset: Once uploaded, never has to be changed. Files are all but guaranteed to continue working forever. "Conversion" permission means the user never has to worry about files becoming obsolete or incompatible.
• De-Listing:
  • Addon: Can be de-listed if scirra makes a similar, official version - all your work goes to the trash. Official versions will most likely work better than your addon version, since the SDK is incapable of many things official addons can do (such as spawning custom interfaces in the IDE and modifying engine code both at edittime and runtime).
  • Asset: As long as your work is original, it will not be de-listed, even if the art pack included with construct 2 is updated to include a functionally-similar piece.

The only saving grace is that addons are massively more reusable - a feature never gets stale, whereas art/music seen repeatedly across games screams "unoriginal". This benefit is negated by having per-developer licenses.

In the near future, with modularity, addon developers will also have to face modules as competition. Modules will probably be more desirable, since they're accepted in the arcade and suffer less from breaking changes.

So let's make a quick calculation: a person working full-time for minimum wage in the US makes around $290/week. In order to make that much selling addons, that person would have to sell 58 licenses per week (this doesn't take into account Scirra's cut). Is that viable? I don't think so. Even if it is, one can probably make more money by selling javascript code in other stores (i.e. codecanyon).

Current plugins are in the £15 - £20 range which we are not comfortable with. This is a significant % of the cost of a Construct 2 License.

Why aren't you comfortable with that? Look at the unity asset store - scripting section. Those prices are quite hefty, yet I don't think a user looks at that and thinks "gee, I'll have to waste a lot of money buying all of those", instead they look at it and think "wow, this is so flexible! Look at the possibilities!".

I've said in the past, we need an editor SDK (look at what unity can do) as well as a more powerful runtime SDK to make construct more extensible, but with that statement it appears you think all (of most) functionality should be out-of-the-box...? That the more addons exist, the less a user will be inclined to buy construct? I don't agree with that viewpoint at all.

The only way I see to work with a $5 per-dev-license would be to flood the store with single-purpose plugins that can be coded in an hour or less.

Now, I know that many developers have an inflated sense of what their plugins are actually worth (I'm not going to point fingers, but really, look at the current offerings in the store...). However, keep in mind there are IMHO only two sensible approaches:

• Either let the market self-regulate, in which case competition and the rating system will ensure that those plugins wither and die (albeit generating some angry users)
• Or price items yourself. I supported this approach in the past and continue to support it.

Keep in mind the primary goal, above all else, should be to maximize profit for content creators (as with any store), not to garner more customers for construct - that's a secondary benefit stemming from giving potential users a multitude of options. Putting that goal before content creator's income is the kind of conflict of interest that makes me think maybe an unofficial construct store would have been a better option.

Indeed a popular request, and one that I stand behind.

See my topic about it here.