Ashley's Forum Posts

  • What if the object was deleted, could the object in the event be replaced with something like "EmptyVoid".

    I don't think it's any better - that actually modifies a random bunch of your events, so you'd still have to go through and clean up a bunch of "EmptyVoid" expressions or just leave them cluttering up the project.

  • You still haven't provided a use case. I don't think there is any technical reason "Force own texture" should increase the CPU usage, only GPU usage. So I want to see a .capx proving this, otherwise we're adding a feature for the wrong reason, or no reason at all.

  • The first problem (pasting) is difficult because that control is handled by our UI library, and it's very difficult to change it. Hopefully it's not too much of a problem.

    The second issue (removing events when things they refer to are deleted) is by design. It is a very difficult problem to leave a condition or action that refers to something that has been deleted. Consider if in your example you did this:

    • delete the 'sound' variable
    • save the project, close and reopen it
    • now the editor has an action with an expression referring to "Sound", but it has no idea what it is
    • then you create a new object type called "Sound" - say, a Sprite or something unrelated to what it used to be
    • the name of an object by itself is a syntax error, e.g. you can't just have the name "Sprite" as an expression. So now the action no longer refers to anything deleted, but is still invalid.

    Another example would be to delete a number variable used in a number parameter, recreate it as a string variable, and then you have an invalid parameter because it's the wrong type. Currently the editor stops this by preventing you changing the type of variables that have any references in events, but deleting and recreating would work around this.

    This is one of those ideas which is far more complicated than you probably imagine it to be. It creates an opportunity to create "valid" conditions and actions (ones that do not refer to anything deleted) which contain a syntax error. This is inconsistent with the rest of the editor, since you are not allowed to create a condition or action if any of its parameters are invalid. IMO this is a major advantage of the event system, since you know everything you're looking at is valid, and you avoid running in to syntax error/invalid code type problems that you get with traditional programming languages. So allowing a loophole to create invalid events seems like it would just make things worse.

    IMO a better solution is to provide tools for reviewing the project, so you can find all references to an object or variable, and view a list of everywhere it's used. Perhaps this list could be shown before deleting anything with a message like "Note that deleting this object/variable will also remove the following places where it is used". Then you also have the opportunity to go and update all those locations, and safely delete the object/variable afterwards without other things disappearing.

  • Alternatively if you don't need to publish to the Chrome Web Store, just keep using WebStorage. Local Storage is a good idea for the long term and you should use it for any new projects, but if it proves particularly difficult to change over then WebStorage probably isn't going to disappear any time in the foreseeable future. Also if you have already published a game, Local Storage can't read data previously saved by WebStorage, so that might be a dealbreaker.

  • We no longer officially support Ejecta, so this will not be investigated. Consider moving to Cordova.

  • Should be fixed in the next beta.

  • The platform behavior is very complicated. It supports things like running up and down slopes while the direction of gravity changes, and has had a lot of work done to avoid edge case bugs when doing things like reaching the top of a jump-thru when at exactly the peak of a jump. This is what behaviors are for: to solve these difficult problems for you, so you don't need to address them in events.

  • Construct 2 stores your project in temp while you're editing it, so if you have some software which tries to "helpfully" clean temp while you're using the files, it will erase your project.

  • Yeah, accidentally used a new JS feature which Chrome supports but Firefox doesn't yet. It's already fixed for the next beta.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Looks like a duplicate of https://www.scirra.com/forum/viewtopic.php?f=151&t=129306. I'm pretty worried that AMD are going to put out a driver update that breaks C2. Let me see if I can get in touch with them.

  • ItemValue is set to the correct value in the 'On item exists' trigger, as of r203, so you should not need to use a 'Get item' action in 'On item exists'. However it's not set in 'On item missing', since, well, there is no item

  • Rename the .capx to .zip and extract it, then you have a folder-based project. You'll need to replace all the missing files. It's only using a temp folder to extract the .capx contents to.

  • Having dealt with thousands of bug reports over a period of years, I have come to have the approach I do because it is by far the most efficient way of resolving issues. I have eventually realised that a significant part of the process of dealing with bug reports is teaching people how to write useful bug reports, allowing the reported problem to be solved as quickly and effectively as possible. Lots of beginners print screen an error message and report it, and it is literally impossible to do anything about it. Another very common case is they carefully write up a list of steps, but don't share their .capx. I follow the steps (which can sometimes take a while, especially if there are vague bits which I get past by trying different combinations of interpretations) and it turns out they forgot a step which the original .capx they used did, and was the real cause of the problem. If I had the .capx, I could have solved it immediately. This kind of thing is not useful to anybody: it wastes developer time, and makes it take longer to get user's issues fixed. Unceremoniously closing the issue is the quickest way to get people to respect the guidelines, which helps everybody.

    Everything in the bug report guidelines is from this kind of thing happening again and again and again and again and again, until I draw the line and say I will outright reject any reports that do not follow the given requirement. And it still keeps happening. Yes, I can see that if you are a new user, you come along and spend some time carefully writing up a list of steps but don't provide a .capx, and then your report is immediately closed, you might think I'm being cruel or something, but experience has taught me there is about a 50% chance I'm not going to see the problem. Given there are over 4000 bug reports and they still come in fast, this can turn in to months of wasted developer time which could be spent on something more useful like developing new features, and the reporter could take some simple steps to help us help you effectively.

    The bug report guidelines are the things you need to do for a software developer to usefully and quickly investigate your problem, so please take them seriously.

    Also if you buy Microsoft Visual C++, I don't think you'd expect Microsoft support to help you debug your C++ apps for free - although they (or someone else) might offer a paid service for that - but they would address reasonable bug reports. Similarly I don't think it's fair to expect us to solve the event problems in your projects. When it comes to bug reports, as I've mentioned large projects are not even useful. In general, the larger the project, the less likely it is to be a useful bug report. If you can't reproduce the problem in a new empty project, it is probably not a bug (another point with years of experience behind it). This makes the copyright/not-sharing-my-work issue irrelevant, because I don't want you to send me your whole project anyway. (With one sole exception: performance profiling - but most bug reports aren't about that.) This is also industry standard. I would not expect Microsoft to fix a C++ compiler bug by sending them the entire Construct 2 source. They would require that I reproduce the problem in a minimal program before they could investigate. Then I also don't need to send the C2 source code anywhere, and they can fix the problem more quickly.

  • Yeah, but dynamically adding frames is a feature request, not a bug.

  • Scirra has been growing slowly for a while. We're just not making public announcements about it as we go along, but maybe we should. We have people helping with support, software development, business development, and more. There's also a whole raft of stuff you never see from your side like figuring out how the tax arrangements work for the third party sales in the Store, or managing the increasing number of education subscriptions, or optimising the database caching so the site can scale with the increasing number of visitors, much of which I have little involvement in so I can focus on the technical stuff. But none of that changes what a reasonable bug report is!

    FWIW Tom is actively working on the new Arcade now - a ton of stuff has meant it's been put off way longer than we originally hoped (ranging from prioritising the new Store with third-party content, to customer-invisible things like adapting to the new EU tax laws). But I think he's full-steam-ahead on that now and I'm hopeful we can have the new Arcade running within a month or two.

    We're not coding in our bedrooms any more! Things have come a long way