Hello Guest

Author Topic: Atlus accidental Merging multiple sprite collections and spritesheets.  (Read 3538 times)

DanTsukasa

  • 2D Toolkit
  • Newbie
  • *
  • Posts: 16
  • I love Games Design
    • View Profile
    • Team Ekko
Hey guys

I've an odd issue with my games atlas files getting confused.
In my game my main character has 7 different forms, for each form I've externally created a sprite sheet containing the different animations, all these sheets are in different subdirectories within the same project in a folder I've named 'Sprites'.

I open up my scene create a new sprite collection, import a sprite sheet and then set the x and y values to the correct numbers (256x256) and then rename things accordingly.
I then go to the Animation editor and pull together my sprite animations under different clips, clip 1 is run, clip 2 is jump, for example.

Everything here runs perfectly, the sprites are collected into an Atlus named 'atlus0 (possibly with a space before the 0)

I then do the same thing for another form, everything appears to work fine, but when I create a new animation and go to create a clip, it doesn't want to load the correct sheet, infact it appears that my second atlus overwrites my first.

What I mean here is that I can click the correct sprite collection from the animation editor, but it loads the wrong sprites.

I've tried naming it atlus0 and atlus1 but it doesn't appear to change anything, they just keep overwriting eachother each time

NOTES:

The folders are all named differently, the collection and animations are all named differently (though they contain the same number of frames and same sized sprites).

If anyone has any advice it would be hugely appreciated, I'm tearing my hair out trying to work out the best COA here.

Thanks

Dan

unikronsoftware

  • Administrator
  • Hero Member
  • *****
  • Posts: 9709
    • View Profile
Are you duplicating the sprite collection by any chance? If you are, you should open up the duplicate in the sprite collection editor, and then in settings, click "Clear References". Otherwise it will still be referring to the first objects data and overwrite that. Its the sprite collection data object that matters here. Names don't matter at all, as nothing actually uses names as a reference.

If this isn't what you're doing, we'll have to dig further, but the names can't cause the issue as they're not used anywhere.

DanTsukasa

  • 2D Toolkit
  • Newbie
  • *
  • Posts: 16
  • I love Games Design
    • View Profile
    • Team Ekko
I started everything again from scratch and it works fine again, I was copying the prefab about, considering the sizes and names are the same I assumed I could just change the spritesheet itself and it'd sort of update, but I hadn't considered the refferences.

So thats fixed now, its great.

The names can't even cause an issue if in for example, each of my 8 different sprites, all use a 10 frame 'run' animation, All named Run_001?

An interesting addition for the next 2dtk update is, if for example I have an animation relying on say my RUN frames 1-10, if I then delete the run frames, or rename them (I assume it must happen with rename too), then the animation clip can't be used, as soon as I click it it basically locks up the entire animation window, I can select another perfectly fine, but selecting the 'broken' clip breaks it, I can't even select it to click delete as it simply becomes one giant panel. This is horribly explained, but if it doesn't make sense I can take some snapshots.

unikronsoftware

  • Administrator
  • Hero Member
  • *****
  • Posts: 9709
    • View Profile
Names can't cause an issue, but if the sprites had the same names I think the interface wouldn't actually display them to select them. But, if you had unique names, and created the animated sprites, and then went in and renamed them all to be the same name, that would still work. The reference uses IDs and not names. The names don't really matter, but they kinda do for some of the UI stuff.

Some snapshots would definitely help explain the issue :) I'm preparing 2.0 for release, so I could definitely fix it for that release.