Mike at BrashMonkey

You could have all the enemies separate, but have the specific grapple animations include enemies... maybe one "dummy" enemy that can hive their body part images replaced on the fly via a character map to look like any enemy? Or have a copy of each grapple animation to handle each enemy. Then when a grapple move is triggered, you'd make the real enemy disappear and play the animation that has that enemy built in. Then when he animation finishes, make the enemy visible again and in the proper place and animation to seamlessly continue where the animation left off. The benefit of separate Spriter projects for enemies vs player is it will be logically more easy to distinguish which Spriter object is which, as it would be a totally different one instead of having to check a variable or something else to figure out what instance of the same Spriter object is the player or the enemy. You're looking to make a complicated game, and any solution is going to be tricky one way or the other, but any of the methods you are considering should work.

I suggest you check the full list of them. There's always the ones to actual languages like C and Java script. I'd have said Unity, but right now there seems to be compatibility issues with the latest builds of Unity. I'm looking into that. https://brashmonkey.com/spriter-runtime-apis/

The engine with the best Spriter support currently is Construct 2, followed by Construct 3. In my personal opinion, Construct is among the easiest yet most flexible authoring systems to learn to create 2d games. There is a free edition of Construct 2 which has limitations, the most important being it only allows 100 events, BUT it does allow the installation of plug-ins such as the Spriter one, and I've made an entire platformer game engine within that 100 event limit, complete with Splash and game over screens, menu, system, etc. To my knowledge the free version of Construct 3 is more limited. https://www.scirra.com/store/construct-2

I think it's because you are calling functions... the functions don't know which enemy you are referring to as it's not a sub-event of the original event that detected the collision wit ha specific enemy. I suggest you re-structure the logic to use sub events instead of functions. This also seems to be a purely Construct based issue (not a bug, but learning the intended use/logic structure) and not specific to Spriter.

We'd need to see the code, not the running game to be able to possibly help.

Can you clarify what you mean by "The Spriter exporter"? Ideally, please record your screen while showing your attempt and the resulting issue or a series of screen grabs. This should help us figure out the cause of the problem much more easily. Though I must say I know nothing at all about Phaser, but hopefully someone else can be helpful in that regard if necessary.

I'm glad you were able to recover most of your work, and that you'll be using something with version control from now on. Do you happen to have the older version that still has the corrupted animation? we might be able to figure out how to fix that animation. It might also help us figure out how it got corrupted in the first place. thanks.

Hi Seth, Unfortunately I'm no expert, but hopefully I can help you get the attention of someone more experienced with using Unity and Spriter2Unity. I suggest you post directly in the thread dedicated to Spriter2Unity or at least rename this post's title to include "Spriter2Unity", and ideally post a screen recording showing your process and ask people if you're doing something wrong or if there's some kind of compatibility issue going on. If no one else responds to you in a timely manner, you can zip up your Spriter project and email it to mike@brashmonkey.com and I can see if I can figure out how to get it to properly import and show up. The only other thing I can think of at the moment is make sure you're not using any of the Spriter features in your animations that Spriter2Unity can not properly convert during import. Also, sidenote: "upload" means to send something somewhere on the internet or at least to another computer, so your use of the word was causing me confusion at first.. you should likely edit your post and replace the word "upload" with "import". cheers.

Do I understand you want to set a bone to be the first bone in the hierarchy that other bones will then be a child of? It's my understanding you can left click and drag in the hierarchy window to move a bone to anywhere in the hierarchy, but there's no way to drag a bone to make it the parent of all existing bones and images if they are not already assigned as children to another bone in the chain. (Unfortunately this will only work properly if you don't have any additional key-frames) What you want to do is: Make sure you're on at zero in the timeline create your new bone you want to be the parent to the other bones click the hierarchy tab to reveal the hierarchy window and drag the current most foundational bone (the current bone that is already the parent of all the other images and bones) onto the new bone. This will make it and all it's children subordinate to the new bone.

Can you please zip up the entire project (spriter file in a folder with all the images it uses) and send it to mail@brashmonkey.com so we can take a look? Also, have you been saving using some kind of version control? Though corruption issues like this are extremely rare, for any large project made with any tool or tools, it's critical to be able to revert to slightly older versions of the project if something goes wrong. thanks.

Hi Gustovo, Sorry to hear you're having this issue. To my knowledge you're the first to ever report this particular problem. I think the best solution is to try and figure out why Mojave is not communicating the proper screen dimensions to Spriter on your system. Have you tried changing your screen resolution to see if another resolution works properly with Spriter or if changing it and changing it back would somehow fix things? Apparently people have run into many general problems with Mojave (based on my quick search results): https://www.google.com/search?safe=active&rlz=1C1CHBD_enFR841FR841&ei=xWXNXJj0NqGMlwS1p7ngBg&q=mac+mojave+program+not+fitting+on+screen&oq=mac+mojave+program+not+fitting+on+screen&gs_l=psy-ab.3...65402.65593..65768...0.0..0.54.101.2......0....1..gws-wiz.......0i71.TIm4OsFiqQo Hopefully you'll be able to find a good work-around or Mojave will be updated with greater compatibility. In the meantime, it seems you're working in a very high resolution. Is this for a video game, and if so,m do you really need the character to be so large? Working at this size could easily lead to either performance issues or failed export of animations, especially in Gif format. If you have Spriter Pro you can create a clone of your Spriter project, scaled down to a smaller size... if you don't have Spriter Pro you could zip up and send your project to mike@brashmonkey.com and I can scale it down to whatever scale you'd like.

Very glad to be helpful.

That looks like a bug, but I've never seen this behavior before. Could you zip yo the spriter project and email it to mike@brashmonkey.com and I'll try to figure out what's causing this?

It's not the quality of the images that is the issue, it's their pixel dimensions, resulting in a total frame size+number of frames that's making the system run out of memory during the process of generating the GIF. Are you working at a needlessly high resolution?

without us seeing the Spriter project there's not much we can do. It likely has nothing to do with bones and more to do with the resulting number of frames or the resulting size of a frame. GIF animation format was never intended for large or really smooth animations. We'll need to see the animation you're trying to export and the settings you're trying to use. Most people with crash issues while trying to export GIF animations have accidentally put an image really far away from the center point of the frame at some key-frame that the resulting frame-size would be many thousands of pixels high and wide, which causes the GIF creation routine to run out of memory. The second most common cause is just using overly high resolution images or trying to export at a high FPS which would also result in an out of memory crash. If you'd like, please zip up and send your entire Spriter project to mike@brashmonkey.com and I'll take a look.