skymen's Recent Forum Activity

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

  • To be clear Overboy, I don't mean having them linked to the same values Outputs use. I mean having a second list for inputs like this

    This is a super quick mockup, as long as we can "name" inputs I think it's good enough

  • It wouldn't make sense to link an input to a value, so the way it works right now is good, a whole Node can have different input Nodes !

    I think linking inputs to "IDs" would let you get a parent by ID, instead of by whatever is already there.

    I can see a few reasons why this would be cool, but it's mainly for UX and just letting things be more open IMO.

    Just in general, having more control over how the input field works is good.

    Could also make it so we can write graph structures where instead of seeing this as a node structure, we treat everything as siblings and so any node can be linked to from either side.

    Let's say I use this as an FSM, having every single link go out from the node from the left side can be pretty painful.

  • Nodes can't have multiple inputs AFAIK

    They can, it's just that you can't link an input with a value the same way you can with outputs

  • In the example the output values are used as raw text, but they don't need to be used like that all the time. They could be ids to a dictionary. With a few events it would be relatively easy to pick up the real values from the dictionary using the ids from the node outputs.

    I disagree on that point, because being able to save and load flocharts at runtime would be amazing for moddable content. Also in some languages it might be required to split a given dialogue message into 2, or remove one option entirely (for any reason that might occur during localisation) and having the option to have separate flowchart files one can load can come in very handy.

    Although, for most projects linking to a dictionnary will still be the best use case, having the alternative would be great!

skymen's avatar

skymen

Member since 3 Aug, 2015

Twitter
skymen has 100 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
  • x2
    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.