OpenMLTD / MLTDTools

Tools for THE iDOLM@STER Million Live! Theater Days (MLTD/MiriShita/ミリシタ) / 偶像大师百万演唱会剧场时光工具箱
BSD 3-Clause Clear License
142 stars 17 forks source link

Broken Camera #36

Open kdru opened 4 years ago

kdru commented 4 years ago

I've downloaded new version of miritore and tried to export camera for alliance stardust, it was completely broken 5 camera with new tool 2 camera with old one

hozuki commented 4 years ago

Looks like 67ab03650211baf7a3b075ac461dacade80e0383 broke the camera function (d038fb978463037ceb874f39d23cf28dff16aba2 works, 0.3.0.71). I'll fix this asap.

kdru commented 4 years ago

But meanwhile, Fermata in Rapsodia camera works fine o: better than in old version

hozuki commented 4 years ago

I finally found the cause. The bug was introduced in 145c0925ec30535cc5e4bcd197ddcc601dd103fc (not 67ab03650211baf7a3b075ac461dacade80e0383).

Starting from this commit, the new motion asset searching flow is:

  1. Test asset name.
    • Is this motion for default (no appeal), special appeal, another appeal, or gorgeous appeal? If so, add it to the result collection.
  2. Are all 4 motions found? If so, return early.
  3. Are there any more motions? If so, go to step 1; otherwise return.

In contrast with the new flow, the previous flow only searches for 3 appeals (no gorgeous appeal). For now, most of the motion bundles do not have a gorgeous appeal; only the 39-person version of Thank You! has it. So most of the time, all of the motions in a motion bundle will be read.

So, how to determine the appeal that the motion belongs to? By looking at its ending. For example, if it ends with _cam, it should be the one for default.

Unfortunately, some MVs use more than one camera. アライアンス・スターダスト (Alliance Stardust) is one of them. It has two default camera files: cam_alstar_01_cam and cam_alstar_02_cam (so that there are several split screens in the MV). Using the old flow, cam_alstar_02_cam will never be read because all appeal motions will be found before it. However, with the new flow, both of them will be read (since they both end in _cam). And guess which one is returned? cam_alstar_02_cam because it appears after cam_alstar_01_cam and the former gets replaced! Therefore, in the end, the camera animation exported is the one for secondary camera, not the main camera.

How to solve this problem? My solution will be adding a "camera number" dropdown so you can select one if it exists.

But, since I'll be occupied in the next two or three weeks, I can't make commits of major changes in this period. Please use build number 0.3.0.71 as a temporary solution, if camera or dance animations go wrong like this. That version does not support appeals but the camera logic is okay (i.e. always exporting the default animation). This problem will be fixed eventually.