Ruskul's Recent Forum Activity

  • Basically the title.

    I want to be able to add common aces to a project in order to get around the limitations of behaviors and families not being able to be nested. Since I have a number of families that need access to raytracing, and some of those families have the same objects in them, alot of objects end up having 3-5 los behaviors on them and a similar number of custom movement behaviors.

    Nested families or ECS would solve this issue, but apart from that, being able to add common functionality to all objects is also a way to deal.

    Without duplicating code, my current workaround (event sheet ecs) is cumbersome and result in object count bloat, necessary and abundant "foreach" loops with picking byuid, and event sheet overhead increase, resulting in poor performance.

    > I already know of at least one easy way to hack around the sdk2 limitations and expand the api to include whatever internal calls I want anyway - its just "slightly" more bothersome than just installing a plugin - until someone releases tool to automate it. At which point, poor little Timmy IS going to use that hack.

    >

    It's probably best not to do this, this could incite more stricter changes to the API's which would not help anyone, and just create a worse ecosystem for construct, and create a worse relationship between addon devs and the folks making the engine.

    I think there is plenty of time, to migrate and test, and request api changes. before v1 gets sunset. I worry statement like these will just antagonize the dev's instead of bringing positive change.

    I agree. I have no intentions of doing this. I already cleaned up most of my behaviors to avoid internal api use, and have stayed clean since. Most reasons for using internal calls arenʻt as applicable to me now as in previous years, due to better api around collisions, and the addition of particular features.

    I mention it because the major reason for sunsetting sdk1 will be irrelevant if such hacks are adopted, which I believe they will be unless every need of users can be addressed in sdk2. Due to the size of the construct team, I find that incredibly unlikely. Even getting feature additions, like vector math or expanded collision support natively takes forever if at all ever. (using a behavior to resolve collisions, or raycast has severe disadvantages over common ACES, for example, given how you canʻt nest families and such forces poor practices when it comes to architectural design.

    Ashley - Sorry, I donʻt seem to be able to find the rule in the link provided.

    Either way, you are right, and I apologize. I meant that statement as hyperbole, and not literally - which I agree is in bad faith to the conversation at hand. I meant that despite listening to us, you chose a path that I disagree, nor do I understand the reasoning from my perspective.

    You have obviously spent a great deal of time decidedly NOT ignoring us, and myself, and I am grateful for that. So sorry for being boorish these last few days.

    Thank you for the time you have spent dealing with this.

  • Awesome, that is very helpful. When I am really screwing around , I manage to crash the editor several times an hour. Lol. This is usually my fault entirely, but when its not, it also probably is. This should speed up the number of times I can crash in a single sitting :D

    I was going to also bring up what piranha305 mentioned as that is currently an issue at the moment for me, and frustration there led to my last few posts. It seemed from other forum posts there was no intention of porting over the event sheet classes.

    -----

    Honestly though, It still seems like letting sdk1 slowly vanish organically by virtue of blasting warning signs not to use sdk1 would more than solve the problem, we could have cake and we could eat it too. Anyone using sdk1 gets no support. Warn them in the editor on load, etc... problem more than solved. We all move on to sdk2 and live happily ever after.

    I just don't the current move. You say this way solves the issue of people coming to you crying when their project breaks, but all the crying we are doing here is completely ignored. Its like poisoning the beehive to prevent hornets from attacking them, who cares about any of the bees. The fact is, there will always still be hornets tomorrow, so even the bees of tomorrow won't be safe.

    I already know of at least one easy way to hack around the sdk2 limitations and expand the api to include whatever internal calls I want anyway - its just "slightly" more bothersome than just installing a plugin - until someone releases tool to automate it. At which point, poor little Timmy IS going to use that hack.

    Then once again, we will have a bunch of plugins that will all break just as soon as each update happens and we will be right here again.

  • Well, right. I get that, but I am saying that other engines also don't force you into a proprietary model, which the marketing language implies. It is a comparative statement that is misleading. It should just highlight constructs strengths, not rely on making a comparison that isn't relevant.

    Gamemaker is the worst of the lot, and in most ways construct has an objective advantage over it. But even it doesn't require gsml at this point.

  • Whaaaat?? How do I do this thing?

    I'm using the downloaded app version, and I know you can do: editor.construct.net/? safe-mode on the web, but not sure about the app.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The title.

    Downloaded v2 sample-behavior running r392.2 and construct crashed hard with no way to salvage except to delete all local data and go fresh.

    Why is it again we can't uninstall an addon causing a problem? You get the red screen of death and cant do anything but delete everything. Not too bad unless you have 2 addons to reinstall.

    The only reasonable thing to do is keep sdk1 AND if chosen, to continue developing sdk2.

    I'll use sdkv2 for newer stuff, BUT I am NOT rewriting all my sdk1 scripts.

    The responsibility is on Ashley to either create a migration tool to automate this, or to still support sdkv1. Pegging it to a LTS version isn't good enough, especially since this is software as a service.

    Ashley - 6 months ago on the official sdk:

    ...documented, supported APIs. If you use those, we promise to support them indefinitely. That's why part of my advice is to stick to those."

    To be clear, obviously I don't want to make one big change that breaks everything deliberately - that would be irresponsible. But the problem is this could happen anyway for some other reason, such as simply by accident, or due to some major upgrade. "

    6 months later Ashley : Proceeding to make a change that breaks everything deliberately. Claiming he was:

    "forced to act" and "can only apologize"

    Calling Ashley out.

    We all have a right to be upset, frustrated, and highly aggravated.

    Ruskul I posted this topic about a month ago to talk about the sound volume, and that issue has been satisfactorily resolved. If you insist on talking about color spaces here, I personally have nothing to say about it, and I'm not going to argue with you now either because that was never my purpose.

    Cheers.

    And I posted about a month ago and added nothing about color theory in my most recent reply except in response to what you said.

    If you insist on arguing that you aren't arguing while telling someone to post elsewhere, I honestly think it would be more convenient for you to create a separate thread, because I'm not going to argue about that here as that was never MY purpose.

    Cheers

    Ashley - I have read through it, Which is why I know you have not played in good faith. In many cases just like now, you sidestep the real argument. Just now, I was very specific and you only actually addressed the least important points and ignored a major point - primarily that of the promise you made. The language you chose to use, does not reflect the situation or your power of agency...

    Nobody forced you into this path, you chose it. That is your prerogative, but saying you can "only apologize" is a blatant falsehood, so don't even. You can't pretend that you care more about the users affected by this than your own agenda, and that is fine but don't act like it is different. You have proven this in action.

    If this is the path you've chosen, then own it. Don't apologize, because true apologies imply a desire to change, and it is clear you are not budging on this, nor will change.

    But all and all, you still haven't addressed the point about the promise made. No amount of rationale unbinds you from a promise you made. If you at least made a tool to auto update scripts, that would be one thing, but you haven't. Long term construct compatibility is now the worst on the market of all major engines.

    I have never been told by a developer "this is the way" to then be told 6 months later, basically go fish yourself and "sorry" for the inconvenience.

    Also, the manual still sucks for scripting. It is still the worst on the market, and now even worse.

Ruskul's avatar

Ruskul

Member since 23 Nov, 2013

Twitter
Ruskul has 2 followers

Trophy Case

  • 10-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • x6
    Coach One of your tutorials has over 1,000 readers
  • Educator One of your tutorials has over 10,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

17/44
How to earn trophies