Inconsistency with transformation removal (reopened from FileAccess page)

[Feliphysics]

Original issue: "Removing a transformation on kiki simply removes kiki's mesh, while removing a transformation on one of my custom minis (which don't use the AssetBundle format, but the obj/mtl format) does nothing. Both these problems get corrected with a board reload, after which the transformation will have been correctly removed. For all I know this could be intended behaviour, it should also be easy to reproduce, if it's needed I will upload a log file. This happens with both new and old transformations."

Log of the issue (which should have diagnostic mode on): Player.log

Procedure followed during logged session:

1. started the modded game (I left active only CMP and dependencies);
2. opened up a campaign that had my test board as default board (having 2 pre-applied kikis and 4 pre-applied custom transformations);
3. removed half of the transformations;
4. reloaded board;
5. removed the other half;
6. reloaded board;
7. transformed a mini into kiki and removed the transformation;
8. closed the game.

[LordAshes]

The removal of the mesh (leaving only the base) is the expected behaviour. Really this function does not need to be used since transforming into something else does not require removal first. However, I will look into it. Would it be possible to get one of your custom assets which is causing the problem, since you have identified that kiki behaves as expected?

Lord Ashes

http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail Virus-free. www.avg.com http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, Jul 18, 2021 at 6:30 PM Feliphysics @.***> wrote:

Original issue: "Removing a transformation on kiki simply removes kiki's mesh, while removing a transformation on one of my custom minis (which don't use the AssetBundle format, but the obj/mtl format) does nothing. Both these problems get corrected with a board reload, after which the transformation will have been correctly removed. For all I know this could be intended behaviour, it should also be easy to reproduce, if it's needed I will upload a log file. This happens with both new and old transformations."

Log of the issue (which should have diagnostic mode on): Player.log https://github.com/LordAshes/TaleSpire-CustomMiniPlugin/files/6837046/Player.log

Procedure followed during logged session:

1. started the modded game (I left active only CMP and dependencies);
2. opened up a campaign that had my test board as default board (having 2 pre-applied kikis and 4 pre-applied custom transformations);
3. removed half of the transformations;
4. reloaded board;
5. removed the other half;
6. reloaded board;
7. transformed a mini into kiki and removed the transformation;
8. closed the game.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LordAshes/TaleSpire-CustomMiniPlugin/issues/6, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGQ5Y6HE2HV72Y4COEIU6YDTYNIZHANCNFSM5ASSAW3Q .

[Feliphysics]

I did not realize kiki's behaviour was correct. In that case this is really not something I would ask you to waste your time over, my initial idea was to use the original vanilla mini as a cheap and fast way to let an npc polymorph between two states, using the vanilla mini as one of them. The mesh not vanishing is completely irrelevant. Anyway, just in case you ever happened to need it here is one of my models, they all cause this "issue": asterios.zip

Unless there is anything else tomorrow I will close this issue, as always thanks for the help and thanks for your time.

[Roxfall]

I have noticed that doing ctrl-M -> ok on a custom mini does not update it if you are updating it to the same folder (it does not check whether mesh or textures got updated). The workaround is to do Ctrl-M -> remove first, then do another Ctrl-M -> name -> ok. Is that related?

[LordAshes]

Yes. This is as "as designed". CMP gets requests through Stat Messaging which works on message changes. When you change mini A to transformation Z, for example, the information gets written into the mini's Stat Block (a portion of the creature name hidden from the user). Each update cycle, Stat Messaging checks each mini's Stat Block against its recorded last value. If the Stat Block is different then it looks for changes and informs the subscribed plugins about the changes. However, that means if mini A is transformed into Z then the Stat Block for that mini has that information. If a second request somes to transform mini A into transformation Z then the request is written to the Stat Block but to Stat Messaging it looks identical to the last request and thus it does not see the request.

This could be fixed by adding a Guid or timestamp to the request but that would complicated the process (because plugins would then have to remove that portion) for very little gain. Typically there isn't a need to transform something to something it already is. The only time that such an action is useful is during test which, as you stated, can be accomplished with the remove first work around.

Lord Ashes

http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail Virus-free. www.avg.com http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, Jul 18, 2021 at 7:54 PM Roxfall @.***> wrote:

I have noticed that doing ctrl-M -> ok on a custom mini does not update it if you are updating it to the same folder (it does not check whether mesh or textures got updated). The workaround is to do Ctrl-M -> remove first, then do another Ctrl-M -> name -> ok. Is that related?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LordAshes/TaleSpire-CustomMiniPlugin/issues/6#issuecomment-882136156, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGQ5Y6B4JGDPVOYIHLGP33TTYNSRXANCNFSM5ASSAW3Q .

[Feliphysics]

That potential "fix" sounds like much hassling over little rewards, and the mesh not disappearing is really nothing more than an inconvenience, as such I will close the issue. Thanks for the in-depth explanation