skymen's Recent Forum Activity

  • Hi,

    does anyone have a good way to detect when the SOL is empty? Like I want to check when a given object type has 0 objects that fit into a filter. Right now I'm doing this, but I don't know if it's a good way to do it

    (The thought process being that if the SOL is empty, the condition will not run, and thus the else block will be true)

  • Hi,

    I feel this is a much better reply, and this is something I can perfectly align with.

    Again, I trust you with your expertise as you've repeatedly proven to make hard calls in good faith and I trust that you will abide by that once again.

    My main point during all of this was never to argue against what you feel is a move in the right direction, it's always been to convince you to be mindful of what you will hurt in the process. I am sure everyone here would love to help as time goes on to move towards a better designed SDK, so I just hope to see this move towards something that can still let us use the engine appropriately for our games.

    I just want to be able to keep using Construct for my games, that is all.

  • Again, I understand. But what am I supposed to do? Beg for features only for them to be added in 9 months on average?

    That's my entire point. There is no alternative.

    If C3 had a proper 3rd party addon versioning system like it does for vanilla addons, again that would not be as much of an issue. I could just make my addon for all the versions prior to the one that adds the feature in the future and all is well.

    But with both a restrictive SDK and a lack of versioning system, there is just nothing left.

  • The issue is not "not being able to customize the engine as much".

    The issue is the lack in alternatives.

    Currently:

    1) the documented API is not broad enough to cover every use case, especially for niche but very important features

    2) The ideas board is moving way too slowly to keep up with the needs of everyone, and there is no roadmap to even be able to tell in what vague direction Scirra is moving

    3) There is no proper channel of communication between Scirra and power users, so there is no way for us to help even if we wanted to.

    For years, this has left us with our only option being ignoring warnings and just using undocumented features.

    Let's take a simple example that has been hammered a few times in this conversation: my SetFOV addon. The addon is something like 6 lines long. C3 perfectly supports a variable FOV by virtue of it being editable in the editor. Changing it at runtime is as simple as updating the FOV value and updating the camera. This feature has been asked repeatedly pretty much ever since the 3D camera was released, yet it has still not been added by Scirra.

    In the future will we just be expected to sit down and possibly wait years for a feature so absolutely basic to be added, with no good way to even tell if it might be coming until it just appears one day?

    90% of my undocumented feature usage is for features you have partially exposed and so that I know you will absolutely maintain, but where the specific thing I need just isn't exposed for some reason. This is done with the knowledge that in the worst case scenario you might just rework the whole thing but you're not gonna remove it because the feature exists in the software (i.e. I know changing the FOV will not suddenly stop being possible because you completely overhauled the camera system, it will just need to be done differently)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Again, I understand your point and reasoning, but I frankly don't know how you can look at your userbase dead in the eye and say "this change you all unanimously find stupid is great for you actually".

    Maybe it will be in 2030 when the SDK v2 reaches a point of maturity where it's usable enough to make stuff with, but again the whole issue is we're all making games today not in 6 years. The scripting runtime came out years ago and it's arguably only reached "fairly usable" status this year. I have no reason to believe a complete rearchitecture of the SDK won't feel like 1000 steps backwards for the next 5 years.

    I still think a version range would be a good thing to do to neatly notify users that an addon might not be the right version installed btw, beyond all of this.

    + You say that people will be in development hell if they can't update due to a 3rd party addon but drastically changing the entire SDK structure sounds like the best way to make that happen on a large scale. Do you just expect people to port all of the addons to that new even more limited SDK for free?

    Hell, even if they wanted to, a lot of the most popular addons that have been commonly used for almost a decade at this point might straight up not be compatible.

    To me, this all sounds like the best way to create a mass exodus of users. Still, you seem dead set in doing things your way and there seems to be no words I can say that will convince you to listen, so all I can do is hope you keep your promise of actually doing your best to make that change be as non disruptive as possible for everyone. I will keep giving you the benefit of the doubt and trust your decisions, but you don't make it easy.

  • Hi, I feel the main point Ashley is raising is about addons breaking down the line for no good reason and users being mad about it and complaining to Scirra.

    IMO this would be fixed by just letting addon devs specify a version range for which addons are made for, and have the editor warn you that the addon may be unstable if the current version falls outside the range (with a button to continue at your own risk)

    That way, addons that can neatly fit within the SDK can just be infinitely usable, and addons that can't will let the users know.

    Add to that a field with a proper way to contact the developer that would be shown on that popup AND if the addon fails to load in the editor and it should be fine. It would also make it easier to use C3 with unstable addons as right now if an addon fails to load the editor crashes.

    + That would let you count these out of support range addons as a form of deprecated addons and you could hide them in the object selectors with a context menu option to show them regardless.

    I feel this would alleviate some of the concern and I personally would be perfectly fine building my addons for every stable version that comes out

    Also, about the text thing, unless I am mistaken this is still only me you're talking about and my stance has been clear on this. Break my addons if you want, I'll deal with it when I can. It's not like it's the first time you've repeatedly made deep changes within the text rendering + Animate Text uses litterally 0 undocumented features that you did not promise to provide. It's only just a call to WrapLines to get the line count back, and set typewriter progress to use C3's typewriter code instead of my own if possible but it fallsback to my own typewriter if needed. I have good reasons to assume that even if you throw out all of the text rendering code and redo it from scratch you will still have a way to get line count.

    99% of the code is my own and completely relies on BBCode and used the exposed SetText action to achieve everything.

    The only way for you to break AnimateText is if you decide to stop supporting BBCode, or stop supporting text.

  • I think you need to understand our stance on this Ashley while you are working on software architecture and striving to have something that will still work in 10 years, we are not.

    We are making games, and ask any game developer out there, from AAA to indie and they will all tell you that designing games like a software is itself a recipe for disaster.

    You are making a game engine, so I get that you need to have it work as long as you can, but at the end of the day you are making it for a crowd that actively depends on being able to break and hack stuff. You might think this decision is sensible for you, but it will be very hurtful for the bottomline of your userbase.

    If we reuse your car manufacturer analogy, that's like specialising in making cars used in rallies and complaining that people wanna mess with all the car parts. You can lock that down, but then the rally drivers will just look for another manufacturer. Sure you will be able to keep your parts secure but people actually competing will stop buying them.

  • I understand the reasoning, but also you need to understand why stuff like that happens in the first place.

    I have been making addons for 7 years now, and the overwhelming majority of the issues I encountered making addons for C3 has been the fact that the C3 addon SDK is very limited. I don't think anyone would be too worked up if the exposed SDK was more extensive.

    In fact most of the new addons made by Scirra use non exposed features. You also run into the same issues we run into and I don't think it's fair to say that for us it's not allowed because programmer god said so.

  • Jumping on this topic as well. Obfuscating the runtime will ABSOLUTELY break most of the bigger 3rd party addons, it will break a LOT of scripts and in general it is extremely hostile to any advanced user of the engine.

    To me this sounds like shooting your own foot with a shotgun because a fly landed on it.

  • If there is no editor for c3ide2, what exactly does it do for you?

    It still does the same thing, the only difference is that you fill out a much simpler JSON format and the framework compiles everything to a proper c3addon.

    In general, it offers more or less the same capabilities as C3IDE, but loses some of the editor capabilities (like dropdowns instead of a list of accepted values written in a comment). In exchange, it offers way more freedom to change about anything you need inside the generated addons and the structure of things.

    For example, I have used it to make it so scripting runtime can be auto filled by the framework for you, instead of having to define all ACEs a second time for the JS scripting side.

    In the same vein, I have used it to simplify the process of working with DOM side scripts, external scripts, C++ wrapper extensions etc, all of which C3IDE doesn't and can't support because of the way the editor has been designed.

  • C3IDE is pretty old nowadays and I don't think will be maintained in the future. I would recommend switching to C3IDE2 that has been completely remade to be faster to dev with and easier to maintain. C3IDE2 doesn't have an editor yet, but there are plans to make one in the future, however I can attest that it is overall smoother to use than C3IDE was.

    github.com/ConstructFund/c3ide2-framework

    github.com/ConstructFund/c3ide2-cli

    Also, I recommend doing addon work in two main passes. First you do the editor side where you define all the ACEs and properties of the addon, and then you do the runtime side where you actually implement the addon itself. Nowadays C3 can (or at least is supposed to) reload addon files from the dev server when you hit preview. I don't think this updates the editor side, but it does update the runtime side.

    An optimal workflow would be to open an empty project and save with your addon added, and keep reloading C3 and that project until the addon is set up. Once that's done, implement the actions you wanna test, and press preview every time you wanna test your implementation.

    C3IDE was also not really designed with that workflow in mind, as it assumes you will be implementing the runtime part of each action immediately after defining them. The new framework cleanly separates the two.

    Also, the new framework was designed to be used with all the advantages VS Code comes with, including generative AI to autofill repetitive tasks for you, so if you have Copilot, writing addons can be done much quicker as well. I would say to be weary of doing that because often Copilot can fill in the wrong things, and you can easily end up spending more time fixing its problems than actually just writing the code yourself. Keep that in mind if you plan to use it.

    Since the framework doesn't have an editor, creating new addons and starting the web server have been moved to the CLI instead. You can still do the process manually if you prefer though. Also each addon comes with an individual dev server script in case you prefer to work that way.

  • No, because in the case of "node templates" I might prefer to have the info of how many inputs are required directly on the node.

    Also, I want to get the parent by ID, if I have to check every parent, find the correct output that leads to current node, and then check the value, it makes something that's SUPER simple become so tedious it makes no sense.

skymen's avatar

skymen

Member since 3 Aug, 2015

Twitter
skymen has 102 followers

Connect with skymen

dedragames.com

Trophy Case

  • 9-Year Club
  • Entrepreneur Sold something in the asset store
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Popular Game One of your games has over 1,000 players
  • x34
    Coach One of your tutorials has over 1,000 readers
  • x2
    Educator One of your tutorials has over 10,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
  • x7
    Quick Draw First 5 people to up-vote a new Construct 3 release
  • x3
    Lightning Draw First person to up-vote a new Construct 3 release
  • x2
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

22/44
How to earn trophies

Blogs

  • Skymen

    Sometimes I do some cool stuff in Construct. Sometimes I like to talk about it.