Ashley's Forum Posts

  • You can define nine cells of the panel object, but I realise that's more for stretching and UI. I guess you want a sort of "composite object", which is made out of other objects but acts like one?

  • You do not have permission to view this post

  • Have you seen the Panel object? Is that what you mean?

  • You do not have permission to view this post

  • C2 doesn't yet support arrays, so you can't return more than one value from an expression. You should use different expressions, or a parameter (like the Array object takes an index parameter in Classic).

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Did you define it in the right class?

    I have to say, if you didn't know about the OR operator and are having difficulty with member variables, it might be good to run through a few C++ tutorials to learn the basic principles. This is beginner level stuff, and really to use the SDK well you need to be better than a beginner...

  • I was going to say you might save some for a Prof-uis license

    Plugin and runtime development can be done without a license. It's only for the editor - and even then, you can still edit the code and have another dev build it.

  • I'm happy to hear anyone's opinion!

  • apply (the function the runtime uses to do the same thing).

  • You do not have permission to view this post

  • Hi all,

    We tried Fundry for Construct 2 briefly, but decided it wasn't ideal. However, I've set one up for Classic.

    Fundry allows you to pledge money towards new features that you want. Once pledges are made, a developer can mark the request complete. Then, pledgers can accept or reject the feature. If they accept, their pledge is paid out; if the majority of pledgers accept, all pledges are paid out. You can read more about how it works here. You can also make straightforward donations.

    I think this might help encourage community development of Classic. Developers are volunteers, and they work hard in their own time and generally don't get anything in return. This way, users can encourage the features they want, and developers get extra motivation and some reward for their effort!

    Given there are a number of informal developers, I propose that it could work like this:

    • everyone can pledge money towards requests - either complete features, or more minor things like bug fixes you really need (which might still be a lot of work)
    • developers can 'claim' a request, by posting a comment - the first dev to post has the claim
    • once complete with a new build out, the feature is marked complete and pledgers accept/reject
    • The Fundry account is registered to Scirra, so pledges are initially paid in to that account - we'll ensure the developer who did the work then receives the money, less paypal fees etc.

    This might not be perfect - developers who claim a feature then go inactive could be a problem, for example. However, I think we can probably safely work out any issues if and when they come up. I do think I should state that "Scirra's decision will be final", though, just to pre-empt if any worries do turn up.

    I also propose that traditional donations (via PayPal or Fundry) are split:

    • 50% to Scirra, for the legacy work done 2007-2011 during "0.x"
    • 50% to the new community developers as added incentive.

    The only fair way I can think of to share out the 50% going to the community developers is to pay it out in the same proportion as the pledges received so far by each dev. In other words, a donation is half to Scirra, and half a kind of blanket plegde for everything. Does that sound fair?

    Click here to visit the Classic Fundry!

    Let's run this for a bit and see how it works out. Let me know if you have any thoughts!

  • I checked, and as far as I can see, Classic only uses XML when it loads persist files. Persist files are also parsed with TinyXML, a different XML parser to MSXML. So as far as I can tell Classic doesn't actually use MSXML and therefore should not actually be vulnerable to any MSXML security flaws.

    I think your fears are unfounded. I'd be more worried about zero-day browser exploits, personally...

  • You do not have permission to view this post

  • Flash is the de-facto standard as you say, and maybe they want a quicker time to a viable product (i.e. no waiting for HTML5 to reach 99% adoption).

  • I'm not sure what you mean... parameters are passed to the functions as ordinary javascript parameters now - if you have an integer parameter followed by a string parameter, it calls the action routine with a number followed by a string. These are just ordinary javascript values, nothing special.