WackyToaster's Forum Posts

  • 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.

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

    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?

  • Since you overlay the pieces, you could make use of hierarchies

    construct.net/en/make-games/manuals/construct-3/interface/layout-view

    In that case you could e.g. put a hat (sprite) on the character. Different hats would be different animations.

    If you use sprite animations where the characters head position is different between frames, you might instead have to use a solution with every tick -> set position to imagepoint and define a "hat" image point on all the animation frames.

    Customizing color can use different approaches. The simpler solution would be that you can pick a selection of colors, rather than giving a custom color picker. So you would just create different animations for the different colors. The other option would be using effects like tint, set color or adjust HSL. Just keep in mind that effects do have a notable performance impact especially on mobile.

  • I did thought of this but i'm pretty scared about doing a layout with 200+ layers...

    Layers actually have pretty much no performance impact unless they are set to "force own texture" or there are HTML Layers inbetween.

    You can also create/remove layers at runtime, so you could just create the layer when needed.

    I used to think about taking a picture of the level selector right before entering any level, and put that picture as the background of the level's layout. Is there any event that could do this ?

    Yes, you can take a canvas screenshot before the level transition. Like this

    github.com/Wackytoaster/c3examples/raw/main/snapshotBackground.c3p

    There's a brief moment that the image takes to load, but you can hide that with some kind of transition animation (a fade for example)

    I thought these discussions are about things like Skymen hacking in the ability to have different sampling modes on different layers. Things that currently aren't possible.

    Well that too! The point is you would have to write your own push out solid code if you want to recreate it, even though the function exists in construct (and probably better integrated and written than I could). Right now you could probably access it even though it's undocumented... but with SDK2 it will be gated off.

    And I don't think there's a way to register a collision event without hacking. Aka one that will trigger onCollision conditions. Maybe I'm wrong tho I haven't touched the SDK in a while. I just looked into one of my hacky addons and I'm specifically calling a function from the platformer behavior _HandleAnimationTriggers() so that I can trigger onLanded() and similar. I guess that too will be gated off?

    If addon developers try to bypass it, then we will just create the same problem all over again - and we will have to take steps to mitigate that, to prevent the ultimate problem of customer projects being ruined. Once again, I am reduced to a warning, even though that has proven to be weak: if you find a way to bypass encapsulation, don't do it! It'll end in disaster, and we'll end up in a situation like this again.

    What about addons that are purely written for personal purposes? If I decide to write some hacky addon for my own game that I don't publish anywhere that shouldn't cause a problem, right? The only project that will break is mine, a risk I might be willing to take.

    The issue is always that advanced devs want access to certain aspects of behaviors and engine to mold it for their exact purpose. I still wish we had a way to modify build-in plugins/behaviors purely for our own purposes. If it breaks it's my issue to fix. If it gets updated it's on me to update it on my end. People have even said they're willing to pay extra for this if that's what it takes.

    But I guess there's little point in arguing about it so yeah, let's move forward with it and fingers crossed.

    Speaking of build-in addons, I don't know the current status but I do remember quite some build-in addons do use undocumented features (an example used to be the collision engine, which was added now tho but not fully). Will this not cause some issues at some point or are build-in addons handled differently in the first place?

    In my opinion that could be a good starting point for the API. On paper, I should be able to entirely re-build a build-in addon from scratch, only using the documented API. If something is missing, then it should be added.

    Examples from the platform behavior:

    collisionEngine.PushOutSolid()

    collisionEngine.PushOutSolidAxis()

    collisionEngine.RegisterCollision()

    All of these seem to be super useful, no? That should be added, and it should be added without me having to specifically ask for it, because realistically how am I supposed to be even aware those exist (apart from accessing the behaviors code on my own accord for some reason)

    I have been tempted by phaser in the past, I might be tempted again in the future. But there's also sunken cost in Construct and quite an amount of good will.

    I know some of you are upset, but only 1 in 50 of us ever publish anything we do in construct. The other 49 would not even know what this thread was about.

    This is probably part of why Ashley can move forward with this. The majority of people might not care, might not know or might simply be beginner hobbyists that just tinker around a bit. A very small percentage actually releases games (commercial releases that is), but arguably that should be the priority of a game engine. Ashley said that about 50% of users fall into the education sector, high chance those do not release games and that's already half the user-base. I doubt they care if some random addon exists or not. I have the feeling that the people who are vocal about all this are people that actually released something before, but that's just basically a handful of people.

    Just look at who replies to this thread, it's almost all all veteran users, some have been around well over 10 years.

    Not saying that the education sector/tinkerers don't matter, they are very much also important, but so are the people who make actual finished games with the game engine. And so are addon devs who very likely are also familiar with construct to a higher degree. Someone who's been with the engine for this long should have some weight in their opinion, and so far it seems to be quite negative...

  • Browser.Language: The browser's current language setting.

    From my experience this one will always be english, because the bundled browser defaults to english language.

    So it has to be one of the other two. I'd go with the UI language, because I've never personally set a game to a specific language from steam. I didn't even know this was an option. I've only ever changed it from within the game. This is only relevant for the first start of the game anyway (usually) so UI language kinda makes sense to me, since your steam UI is probably in a language you're comfortable with.