Ashley's Forum Posts

  • I think this has been discussed before - and one of the main problems I see is a donation is not really a donation if you're expecting something in return. It's more a commercial contract - if feature X is completed, then payments from N people totalling Y are paid. But even as a commercial system where people lodge payments it sounds like it'd be extremely complicated to organise. If people donate money in to a holding account for a feature, what if nobody got round to implementing the feature? Would everyone get their money back? After how long? Would everyone be happy if that happened, eg. if somebody assumed they were definitely paying for a feature to happen? If people don't pay upfront and merely promise to pledge donations, what happens if the feature is done and some people don't follow through? I can't think of any good solutions to the problems of this style of payment model.

    It's very kind of you to offer money for various features, but I see too many difficulties and would prefer donations to go the usual route of nothing-expected-in-return (but are still greatly appreciated and very motivating of course!). Also, something like an export-to-XBOX would be a huge project, lasting many months - probably best left to Construct 2 in the first place, but it's also difficult to imagine how donations could offset the time for that kind of project length as well.

  • Do you mean you simply want a quicker way to have a different collision mask for a sprite, or do you want a new collision engine (ie. current is pixel-perfect, it sounds like you want a vertex-based polygon collision detector), or both?

  • Construct can't do this right now - you could have a shot at making a plugin to do it, or ask another coder to try. Construct wasn't really designed for this, it's primarily oriented as a game creator.

  • I like the idea, but I was also considering enhanced containers for modular code (ie. a container which can contain events, other objects etc. and be copied/pasted around with complete functionality in one go, no need for "variable" objects because everything needed is pasted in). How do you think this idea compares to that?

  • It's on the SourceForge CVS.

  • I've never been able to reproduce it on my computer, so there is very little I can do: to me, everything looks like it works fine.

    I need more information, such as does saving/closing/re-loading have any effect, does it happen 100% of the time, are there any application settings that affect it, etc? Anything else you can think of that would be helpful? Also, does it happen specifically on 0.99.4 or 0.99.42 (they are different builds, listed here - this would help me track down the precise code changes that happened around then).

  • It's a nice idea though and a common question - maybe some feature could be developed to make it easier, at least.

  • Which bug was that? I think I marked a bug similar to that as 'can't reproduce', so you'd need to provide a way for me to reproduce it.

  • Wow, that 2D Guild Wars intro has to be the most beautiful 2D artwork I've seen. Much more artistic and pleasing to the eye than 99% of 3D scenes out there.

  • Lucid is right. I might have called it too early on this build, but it's still a sound idea. It's intended that people test unstable builds on backed-up copies of their work and report back any problems.

  • It would be better to use four animation frames than four sprites - it makes more sense that way, and you wouldn't need a 'destroy object by name' action.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Yeah, add a serialize() to the struct that does ar << a << b << c etc, and the same for loading (ar >> a >> b >> c). Then to save the whole vector, save the size, then for each element, call its serialize(). To load it, load the size, clear the vector, then for each element serialize() it in to a temporary struct and push it back to the vector.

  • Normally you'd just save the size then iterate each element saving them. When loading do the reverse - load the number of elements then for that number of times, load an element and add it to the vector.

  • Not right now, no.

  • A degree of reverse engineering is always possible in all programs (if you had the tools you can disassemble any compiled program back to assembly, for example - and this is especially problematic for .NET I think, which relies on obfuscators).

    Considering the amount of work it'd take to reverse engineer a Construct EXE I'd say it's implausible for now - and remember you lose all edittime-only things like comments.