Ashley's Recent Forum Activity

  • Several things:

    1) Pressing Cancel on the Install addon dialog reports: Addon installed, Successfully installed the addon... Clearly this wrong.

    Thanks, fixed for r16.

    [quote:2eor50g8]2) There needs to be some kind of feedback other than "Failed to install the addon"

    You should be able to see an error message in the browser console.

    [quote:2eor50g8]3) Yikes, this painful. I started with a fairly small plugin, but there are so many fiddly things to add across multiple files, it's not easy to do. I also never did succeed, as there is some kind of error, but I don't know what it is. I did find several issues by using an online JSON validator, so that helped me, but there is no feedback on what the remaining error is.

    You should check the browser console. Also if you use an editor like VS Code, it ensures files like .json files are correct as you type them, and highlights any errors in real-time.

    [quote:2eor50g8]How can we download plugins? An important part of plugin development is looking at how the built-in plugins work. Are you going to provide some way to look at the built-in plugins?

    We're currently distributing the stock plugins as built-ins basically so we could launch quicker, since as you can see the SDK is not complete yet. We may be able to port some of them back to the SDK later down the line.

  • The development process is pretty awkward at the moment, sorry. I've got several ideas to improve it such as hosting a plugin on a local webserver rather than having to install it to browser storage constantly.

    Currently if you get an error like that you just have to clear browser storage. Open dev tools, go to the Application tab, click the "Clear storage" category, then click "Clear site data". When it's done, reload. Your plugin will be uninstalled and you can try again.

  • It's really hard to do frozen updates. The free edition is always kept up-to-date, as it's really part of our marketing and we want to make sure there's the latest and greatest version for people to use. So this approach means for some users, you sign in and then it has to downgrade you to an older version than you're already running. If that downgrade doesn't work or is blocked, you get the latest update anyway. Plus I think on the off-chance there's a Chrome bug that breaks even just very old versions, currently that doesn't matter, but with frozen updates it will cut some people off. I think that would work out very badly: either we have to effectively fork our support and maintain multiple different versions of the codebase for essential fixes, which is a big drag on development, or we just tell users sorry, we're not patching it, and then I'm sure they'll get upset anyway because something they once paid for no longer works.

    It's a great deal easier and simpler just to keep everyone up-to-date.

  • Yes, we intend to support this, as we mentioned in the blog post about the build service.

    • Post link icon

    lamar - you have previously ignored my replies and repeated the same question, and you're doing it again, so I don't feel like it would be constructive to reply.

    Is there c2 plugin support for in c3?

    We covered this.

    [quote:2u18tg45]some kind or even access to the cloud exporters (or whatever is going on with c3) could be extended to c2 devs

    We also covered this.

    [quote:2u18tg45]I have to agree that Scirra is all about the waiting, wait for this feature, wait for this announcment

    We just released the public beta of a major new product. This is not vaporware.

    Was implementing multiplayer really a waste of time though?

    From a business point of view, I think so, yes. We could have spent that time working on something else which people want more (and as always there's a lot to choose from). It took several months to implement, and back then it was just me, so it was more or less "stop everything and do this". Several months of development holding back everything else is a very costly thing to do for a small startup, and overall I don't think it was worth it. Like I say I don't personally regret it since it was super interesting, and I think to some extent it's good for marketing since people like to see the option is there, even if they don't really properly use it. But maybe we could have averted some of today's concerns if we'd put that much effort in to something else. And in that sense, the fact a ton of people voted for multiplayer and then we went and did it, caused damage to the business. So I do have some concerns about bringing this whole voting idea back, but hopefully we can manage that.

    Now, in regards to "HTML5 faster than Native?"

    I'm not going to defend a 4 year old blog post. Yes, it's probably wrong. It was just an interesting benchmark result. I haven't spent the past 4 years claiming HTML5 games are faster than native. Just that they're fast enough. It is basically fair and correct to say WebGL has identical GPU rendering performance to native code.

    [quote:2u18tg45]A page with Scirra tested benchmarks for each platform(PC/Mac/Linux with PC specs, Android/iOS with model, wrapper vs browser) with a Construct 2/3 version of the exported test file would work wonders in giving people an idea of how relative their current devices are to the test devices.

    We already ship some in Construct 3, in the tech demos section.

    That would be great if Construct would use Electron instead of NW.js

    They're the same browser engine, so this would not materially change anything.

    Working exports?

    Can you point to any specific bug reports so I can look in to the actual issues you're talking about? I'm honestly struggling to figure out precisely what anyone's talking about. There's a lot of vague references. Also some suggestions won't actually help. For example if you turn off spritesheets you'll run in to OS max image limits faster, which would probably break large NW.js games. So when you suggest turning off spritesheets, I think that would cause more problems than it would solve. A lot of the feedback here is like that. Nothing is as simple as it seems, really. It's all tradeoffs.

    If everyone can slow down a bit, I can probably address everyone's points in more detail. This thread is literally dumping hundreds of posts with all sorts of mixed and varied concerns in the space of just a couple of days. I really don't like megathreads, I would encourage everyone to please start separate threads per single concern, and stay on topic in those threads, and then I may be better able to comment in a more focused way. (Again, I do think it's a pretty unique thing that you actually can talk directly to the founder, but I'm starting to see the appeal in disappearing behind a corporate team page...)

  • Welcome to the Construct 3 plugin SDK forum! Here we'll be providing information and support to third-party plugin developers interested in working with Construct 3.

    Note you must use Construct 3 r15 or above for the SDK to work properly.

    Current state of the SDK

    The full set of editor SDKs we plan to support are very broad and involve a very large API surface. To approach this large task, we are going to gradually roll out the SDK in phases.

    At first, the plugin SDK only supports single-global plugin types. (That means plugins that do not draw to the Layout View.) We hope to expand on this to drawing plugins, behaviors, effects and editor addons in future.

    SDK documentation

    We have provisional SDK documentation available here:

    https://www.scirra.com/doc/c3sdk/index.html

    The SDK documentation will eventually be hosted on construct.net, but the new documentation system isn't ready yet. Currently the documentation is hosted on scirra.com but likely will be moved in future.

    This should help get you going with developing Construct 3 addons. Again this only covers single-global plugins; we'll update the documentation accordingly as we roll out new features and make new APIs available.

    More help

    Please post to this forum if you have any questions. We'll try to answer you and if possible update the documentation to make it clearer.

    • Post link icon

    I would say that getting this community more involved would be a great start. Conducting direct polls and really having a way for supporters to give feedback.

    This has worked against us in the past. The multiplayer feature was massively voted for, but from the data we look at, very few people actually use it. So the hype effect is a big distorting factor in polls. I don't regret it, it was a super interesting project to work on, but it's something to bear in mind, and is the main reason I have avoided polls since then.

    Having said that, we do have a feature-voting system planned anyway but I am going to strongly caveat it with warnings that "votes are not a guarantee of implementation", for exactly the reason we had with multiplayer. Also I can easily imagine things like 3D becoming #1 voted features, and there are a wide range of reasons why we're holding off on that.

    [quote:13k6dztx]Giving roadmaps that are clear

    We have some more blogs coming up about our future plans. Again though roadmaps can come with downsides, if you don't carefully explain that they are not guarantees, just projects under consideration/in early development. However I do also appreciate that it would be good for us to do something along these lines still, again with caveats about what the precise development status is.

    [quote:13k6dztx]Construct does indeed publish to the platforms that are named but it really isn't clear about the extent of each platform's capabilities.

    Generally, it's as good as the browser engine is. Still I do appreciate prospective customers want to know what will and won't work. I think a lot of products have this problem where they support N platforms but X features only work across Y platforms, and can end up with pretty complicated support matrices. HTML5 is generally a good way to smooth over those gaps, but it's true that we probably ought to do more to highlight possibly problematic platforms which have several missing tickboxes. One problem though is it's really hard to have public messaging around that when you've signed an NDA...

    [quote:13k6dztx]But the biggest thing is exporters and getting the projects out to the masses.

    Yes, lots on the way here, as announced.

  • What waits? It shouldn't wait at all - the UI should respond immediately.

  • I'm not sure what you mean. There is no new conversion between pixels/tick and pixels/second. As ever, the pixels per tick is the speed in pixels per second times delta-time.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Hmm, I guess it makes sense to move it to the properties bar, yeah. Added to the todo list.

  • You can turn off the animations in settings if you prefer.

    • Post link icon

    Okay, wow, now a 17 page thread.

    I'm not sure what anyone here thinks we should actually do. We've already announced things like our own mobile app build service and new IAP/ad plugins for C3, so that is on the way. We've got Xbox One support just around the corner. Mobile support from what I've seen is pretty solid with WKWebView and Android 5.0+, all supporting JIT-compiled JS and hardware-accelerated WebGL. Maybe we could tweak the way we advertise certain things. Maybe some people have bugs, or unoptimised cases, in which case please file reports, or send me .capxs to profile for performance improvements (as ever, I always ask, and either get sent nothing, or just projects with silly performance-destroying mistakes, hence my skepticism).

    Do you want us to rebuild the C3 editor? I would go so far as to say that would probably ruin us, and waste a brilliant opportunity. Do you want us to build native engines? I've covered that in this blog with our rationale around that, which nobody ever really directly argues against, there's just vague accusations of how HTML5 is "poorly optimised" or something, which really is not the case given the potency of modern JIT compilers and the native-equivalent performance of WebGL.

    So what have I missed? What do you think we should actually do differently that isn't something we've already covered? If I can't make sense of any specific complaints or clear suggestions on what to do, then I don't see why we shouldn't just carry on as we are - I think we already have a strong plan for the future.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,776,012 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x42
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs