WackyToaster's Recent Forum Activity

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

    What's the point of addons that literally do the same as event sheets?

    I partially agree with this. The reality is there are things that are really annoying to do in eventsheets. Or that are complicated to a degree (especially for newer users) that abstracting it behind an addon is really helpful. Simplest example: The platformer behavior. You can code this entirely in events if you want. But it's also surprisingly complicated and it's really convenient to just use the behavior. As a tradeoff, you don't have 100% control over the code (which has been requested and denied frequently)

    Overboys suggestion is actually really good but at the same time I guess defeats the point of all this... which is to remove access to engine internals, period.

    It's the old "powerusers vs little Timmy" discussion again. Powerusers want to have full control and power, but little Timmy can't handle that power and might break his project and throw a tantrum, so powerusers will be put on a leash.

    It will probably show with time, how well this works out. Perhaps, maybe, it turns out better than we all expect (or I'm just huffing copium)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

    having it auto generated would be great

    Well... not like we can stop you.

    as well as co-operating with addon developers to ensure the v2 SDK covers all features where reasonable and feasible

    I do hope this will happen. And just to get it started (and it already was mentioned in this thread)...

    It would be easier to not handle 10 different files to make an addon.

    Imo this would be my priority. Because if it's not done now it's never gonna be done. Can it be done? I dunno, but man it's really annoying to juggle all these files. 13 of them... really? I remember whenever I made addons I actively ignored like 8 of them apart from changing the addon id. Surely this can be boiled down to maybed 5 files (including language files). To me it seems too convoluted as to what's happening. Why's there two instance.js for example, what's the deal with that?

    BTW if anyone wants to port my addons feel free. No idea if I have the urge to do the porting myself tbh...

WackyToaster's avatar

WackyToaster

Member since 18 Feb, 2014

Twitter
WackyToaster has 26 followers

Connect with WackyToaster

wackytoaster.at

Trophy Case

  • 10-Year Club
  • 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
  • Coach One of your tutorials has over 1,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • RTFM Read the fabulous manual
  • x17
    Quick Draw First 5 people to up-vote a new Construct 3 release
  • x5
    Lightning Draw First person to up-vote a new Construct 3 release
  • x10
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

23/44
How to earn trophies

Blogs