Posts by blurymind

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.

    Shame that the version on steam doesnt work on linux via wine, but the one you download manually does work.

    It's a shame because had that not been the case, this would have worked on steam decks. I have a steam deck and I can tell you it would probably sell more fusions if they were "playable" or "verified".

    When I say the steam version doesnt work - what I mean is that playtesting doesnt work at all.

    If you took some time to figure out why the steam verion's playtesting is borked with wine, but not if you install it - and fix that - maybe you could make this usable on a steam deck?

    Thank you! I discovered that the steam version has a serious issue on linux, which the installer version does not have - playtesting doesnt work at all on steam.
    Please login to see this link.

    Please login to see this attachment.

    shame, since I was hoping to use fusion on the steam deck (SteamOS is arch linux based and uses proton to run windows apps/games), which I preordered

    I don't want to sling mud at this because I love spriter, but I want to express the key points why I think this kickstarter is coming short, from the perspective of a spriter 1 owner and a spriter 2 backer. Hopefully it will give you perspective of what's wrong.
    I read your update and sadly I think you have no idea. You think the video wasn't good enough or something. It's not that at all. You must remember the context around the release and think from the perspective of current followers and backers.

    - Your Spriter 2 campaign was excellent, but it has not yet delivered a minimum viable product (something that can export files to be used in a non untiy3d game engine with a runtime), after more than 3 years
    - Before launching this campaign you released some demos of spriter2 for bit giving us false hope that it is right around the corner, then you stopped releasing demos for a long time - rightly indicating that you have stopped working on it
    - You reveal in a new kickstarter that your resources are being spent on another product now - one to accompany the one you havent finished yet and might not release in another 3 years. So this is kind of annoying to spriter 2 backers in a number of ways!

    a. You are not working on delivering spriter 2 anymore. Instead you are working on something else now
    b. You are asking to charge people more money for spriter2 dlc and even working on the dlc instead of the thing people paid for - spriter 2. You are splitting functionality out to sell for more money before having finished the core functionality
    c. you are losing focus and building more stuff on top of something unfinished now - this is not indicating for good planning or well architected product
    d. In other posts you reveal that spriter 2's first runtime will be unity3d - the engine you made it in. This is kind of not spriter's userbase. Unity3d already has all the tools you offer in spriter2 - they are all built into it and available to all unity users without the need to buy editors.
    People who bought it want runtimes for other engines that dont have those features so well fleshed out like unity3d - you know c++, javascript runtimes. Not c#, not unity. Generic runtimes that can be wrapped to suit to different game engines - not specific runtime that works on one engine.
    e. Alchemist looks like a very basic game engine - its almost as if your core dev got bored making the runtime and decided to make his own half baked engine from scratch so he doesnt have to do the boring work of making a couple of generic runtimes. But the runtime really is the product - without it the editor is worthless. You cant export to anything people use. Dont try to make people use alchemist over the game engines they have spent years learning.
    f. Also dont shove more game engine logic functionality into an animation format runtime - it makes the runtime more difficult to port to different game engines and maintain.. It will be even slower and less likely to see the light of use on fusion and other non unity game engines.

    These are all the ways that this is rubbing me all wrong.

    Now dont get me wrong, I love spriter, but you guys are kind of missing the mark with this. It's undermining future kickstarters - as it is corroding trust in your ability to deliver a product and for us to ever use it in fusion or other non unity3d engine we know.

    My only advice is that you focus on completing a minimum viable product - spriter2 and regaining the trust of your supporters by releasing the damned thing with a javascript and c++ runtimes that can be wrapped in any engine - not unity3d. There are programmers out there who would make those wrappers for you - just put out the runtime(s) on github. Look at dragonbones as an example of that done right. Heck, make spriter2 export to dragonbones format and we'll use the dragonbones runtime instead. If you dont want to make a runtime and maintain it, use one that the open source community has been developing for years. Its license doesnt prohibit that like spine2d and creature do.

    Export to dragonbones and we'll use the dragonbones runtimes which already work on most game engines instead of having to write new apis and wrappers just to suit yet another 2d animation json format. An exporter will cost you much less time and resources and will massively shorten the path of most people using spriter2 in their favourite game engine! Making all these different json format parsers/runtimes is a massive waste of everyones time. Lets stop reinventing the wheel and start joinging in around one format that is open source and free of greedy licenses.

    Please stop wasting your precious resource on creating yet another game engine from scratch - or event worse - replicating stuff we can already do with a game engine. People on this forum and other forums you promote want to use spriter2 with the game engines they currently use. Thats your average backer.
    Make it work first, work on the dlc after.

    the problem is that the previous KS has not been delivered and there is no clear release date either (3+ years later), yet you are starting a new kickstarter that is building ontop of something that is late and not even delivered yet. Release an editor and a runtime we can use in at least one game engine that is not unity3d (which already has all the features buit in btw, so you are selling ice to Eskimos). A js runtime , a c++ runtime,whatever runtime and an editor2 that can export to it. THEN do a kickstarter that adds to it.

    This is the same as clickteam guys doing sale preorders for fusion 4 while 3 has no release date at the horizon :(

    Prove you can deliver, then do more kickstarters. I will not fund this until I see a js runtime and an editor for spriter2 that can export and is not a demo

    This is what I was talking about here:


    It's something I thought we could add but I'm not sure anymore if it's a good idea or just a loss of time with little or no interest.


    This is a F3 feature, this cannot be added in 2.5 (in 2.5 we can just add workarounds that allow you to copy objects to several frames like the one I was thinking about above).

    It sounds like a workaround that is definitely worth adding! It would be especially helpful in this case! I don't think it would be a waste of time at all :)
    I would use it for sure, it's better than manually copy and pasting across many frames

    For everyone using global objects it will save alot of time, but also reduce the chance of getting bugs caused by forgetting to paste something in some frame

    If we do this, the objects would be added to all the frames you select in that dialog box after you click OK (and their "create on start" option would be automatically unchecked). You would still need to manually add the objects to any new frame you add though, so this would help when you add the Create Object action but wouldn't be a perfect solution.

    For the moment, you have to put in each frame the objects that can be created in this frame.

    The way global events work is quit simple. First, the global events don't know the real objects. They just know object names and types. When Fusion builds the application, for each frame when it includes the global events, it links the object names and types in the global events to real objects that exist in that frame and have the same name and type. If the frame has no object with this name or type, the events are ignored.

    PS: not sure why you say "set to global", the objects don't need to be global. Objects that have the "Global object" option are not stored in a "global objects" set or somethng like that, this is just an option that says that when the object changes in the editor, it should be also modified in the other frames, and it should save it's values between frames at runtime.

    Where is that dialogue box? Is that a feature that is going to be added to 2.5+ or is it something I am missing?

    The biggest problem imo is that frames can not extend other frames. You have to copy stuff across and make sure all frames have the stuff you need them to have. One thing that could help a bit is perhaps treating new frames as something that is created out of a template rather than from scratch. When we see frames, they are like little apps of their own each, where as a lot of users would like to treat them more like the layout of a level- each layout sharing the same behaviours. I guess this is a point for making or using a custom level editor such as tiled in favor of using fusion's frames to do levels.

    Another idea is to somehow be able to automatically propagate a group of objects across all frames somehow - without requiring the user to copy and paste them. If we could use qualifiers to do that - set a frame to automatically import all objects that are marked by specific qualifiers would really really help here too

    The way it's implemented is that the global events (or even frame events) that refer to objects that do not exist in a frame are removed at build time when this frame is built. This allows to reduce the size of the application, to reduce the memory used at runtime, and avoids useless events to be executed in frames that don't need them. Adding all the objects created in global events in every frame would be not efficient at all.

    Maybe a solution would be that when you create an object in the global events, Fusion displays a list of frames in which this object doesn't exist, you select the ones you want, and Fusion automatically adds an instance of this object in those frames, with their "Create at start" option unchecked. This is the easiest solution I think.

    This would work with the Create Object action only, not Create By Name.


    Would this require to copy the object to all the frames that need to use it? In that case it defeats the point of creating it from the global event sheet.
    The reason I need this is to teleport a character between frames. In my case I want to also be able to teleport multiple active objects between frames, without the need to copy them to all the frames. My idea was to just create them, but that is probably not the way to approach it in fusion.

    So instead all the active objects I want to move between frames need to be copied to those frames, set to global and unchecked from create on start?
    Then create them whenever they teleport to that frame

    I've been playing with fusion's excellent spriter extension. For my purposes,I need to dynamically change the opacity level of one of the body parts of a character. Spriter's object loads body parts from another active object, which has them as frames in one of its animation clips. A body part is a frame.

    So I am wondering now, can I somehow change a frame's opacity, or trick it to somehow do that?

    I am running the 2.5+ version btw

    Could an effect be applied to it?