WackyToaster's Recent Forum Activity

    Would love them to hire a developer to make plugins full time, even if its outsourcing some work to talented devs in the community, like they've been doing with example files.

    I actually want that but for effects. Shaders can do so much magic.

  • You try to load "AJAX.LastData" as a string, not as a value. Do it without the ""

  • Construct uses somewhat different syntax for Arrays. Try

    {"c2array":true,"size":[3,3,1],"data":[[[255],[0],[0]],[[0],[255],[0]],[[0],[0],[255]]]}
  • You don't have to be technically competent, you have to become technically competent :)

    construct.net/en/make-games/manuals/construct-3/plugin-reference/array

    So it will look something like this

    choose(rgb(Array.At(0,0),Array.At(0,1), Array.At(0,2)), rbg(Array.At(1,0), Array.At(1,1),....))

    Check the console for errors (F12 in chrome) it will tell you if your ajax is working or not.

  • This would be how you load it into the array. Then check the documentation of ajax and arrays (and maybe some of the build in example projects)

    But you'll have to fix a couple of things with your file. IIrc it has to be hosted on https otherwise the request fails. You may also need to set CORS (google it). Also Construct arrays look different, so look that up also in the documentation.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • You'll have to put the file somewhere (e.g. a server) and request the file via ajax. The file could be for example a dictionary or array.

    1. Load file via AJAX

    2. Load it into array/dictionary object

    3. Access the values as per the documentation

    For a dictionary it would look something like this

    choose(rgb(Dictionary.get("r1"),Dictionary.get("g1"),Dictionary.get("b1"), Dictionary.get("r2"),.....))

  • Your best option probably is to hide this with a loading screen. You can also create them in batches, e.g. create 100 sprites every tick, which will create overall 6000 sprites in a second at 60 fps. You might still wanna hide that behind some transition/loading screen but it should at least mitigate some of the lag.

    Are you by any chance trying to do this on mobile btw? Because I can spawn 5000 sprites practically instant on my PC. It's a beefy one but still, 5-15 seconds freeze I can see happening on a phone.

    By ignoring the warning in the SDK, I am afraid you must carry some of the responsibility.

    Sure, but at the current state I cannot really do much. I deprecated it, unlucky. Only thing I can say is that, perhaps, there is a case to be made for an official implementation that more or less replicates the addon. Even though it basically just solves some inconveniences, but convenience is king and imo that's what many addons actually do. In the end the addon just enables/disables groups but much more convenient than can be done with events.

    Either way, I really do understand your concerns. But in the end it does take away some of our power and control over the engine. Giving power is easy but taking it away is not gonna go smoothly (as you can tell by the reaction)

    For OS version changes, I am not very knowledgeable on mobile exports, but if you don't go through Scirra's server it should be doable to make your own thing. And I think the minimum supported version is a value to change in the app manifest? Anyway, this one I don't know for sure because I'm not a mobile dev, but everything else you can reasonably just keep doing it by digging in the right places.

    Last time I bothered with mobile you could quite easily use Cordova CLI to build your app. In the end the build service probably doesn't do anything too fancy in the background. It's a little bit like all those webservices that convert video and such, which are all just running ffmpeg on the server, but conveniently packaged and plastered with ads.

    Past a certain point of noise and anger, Ashley will just close the gates of communications and nothing will have been achieved. This has happened in the past, and it's counter productive for absolutely everyone.

    Yeah I think by now everyone should have voiced their concerns and/or vented their frustration. Ashley clearly will not change his mind, our options are to make the best of it we can or abandon Construct. I'm still optimistic and as of yet nothing actually happened other than the announcement/first beta release of SDK2. There's at least 12 months worth of updates still ahead that will support SDK1 if I'm not misreading the milestones. A lot can happen in that year.

  • Both seem to be working fine on my end. Btw I would recommend to redirect the domain to either of them in general (either with or without www)

    So essentially they are breaking all the addons now so just in case in the future if engine changes break the addon, they are technically not at fault?

    Let's be fair here, they want to avoid engine changes to break addons in the first place, at least that's the promise behind this. And addons that don't use undocumented features need some porting, I'd not call them broken per se. No doubt, it's sucky still... but at least they CAN be ported. The group handler plugin will be actually broken with no replacement, period.

    That's not sound logic, because engine change always have a chance to break your project regardless? Which is why if u have a game that's going to be released you stick with one version to mitigate those risk factors?

    That is very true, but I kinda feel like doing version freezes is not common practice at all. And even then it still creates problems. If I have an addon that breaks after r391 and Ashley fixes a bug in the engine in r392 that I ALSO really need fixed for my game... I can have one or the other, if I really really need both, the project dies right there.

    None of this is ideal, I don't know what ideal would actually look like.

    Well... let's try something. Here's one of my addons, "group handler".

    construct.net/en/make-games/addons/159/grouphandler

    - It uses undocumented features, although relatively simple in nature

    - Somewhat popular with 1000+ downloads (aka could be used in several thousand projects)

    - Last updated 6 years ago (still working as of today btw.)

    - Solves certain usecases for group enabling/disabling (mostly in terms of convenience)

    - Can sort of in part be done with events, but not really

    Of course feel free to point the finger at me since I ignored the warning and now the addon is going to implode with literally no alternative. You couldn't stop me, I can't stop you, let's call it even.

    I know this is the exact thing you want to avoid. Because if you ever changed something about how groups work in the engine, the addon could also have broken. I still think it's a neat addon that offers a neat set of handy features. It would never have existed in the first place if I couldn't tap into the engine (which is kinda sad to think about because again, I think it's a neat little addon)

    So what's the course of action now? What do we do? Of course it inevitably has to be deprecated... then what?

WackyToaster's avatar

WackyToaster

Member since 18 Feb, 2014

Twitter
WackyToaster has 25 followers

Connect with WackyToaster

Blogs