Bug when adding additional cues to locked design?
-
AuthorPosts
-
Blackbat
Joined: Jun 2019 Posts: 7 Location: United Kingdom NewcomerI recently finished a design with several hundred cues, addressed it for firetek and locked all the addresses. I now find myself wanting to add a couple of additional shell cues and have come up against what I believe to be a bug, which can be replicate in a much simpler example.
If I have a design with just two positions, cakes and shells, with 2 cues on each and each of the two positions is defined in its own section, then address it for firetek using the criteria “each module is restricted to a single section and —” and “each slat is restricted to a single position”, the result is two modules required, one for the cake section and one for the shell position, with one slat on each. So far so good. If I now lock the address of all four cues, and then add an additional shell cue and re-address, I would expect the new cue to be the third cue on the shell module slat. What in fact happens though is that a 2nd slat is assigned to the cake module (module 1) and thus the new shell cue ends up on 1-02-01, rather than 02-01 03 which is where it should be assigned.
I’m thinking this is a bug with sections. If I repeat the exercise using fireone addressing with no slats then the 3rd shell cue again gets added to the cake section.
DrewFinaleJoined: Dec 2019 Posts: 557 Location: United States SilverHi Blackbat, the simple show your described that reproduces the issue is fantastic. We call this a Minimal Test Case (MTC) and it’s exactly what we need to help us efficiently fix the problem. Please send your MTC show file to support@finale3d.com along with any step by step instructions needed to reproduce the issue and we’ll take a look at it ASAP.
WillJoined: Feb 2018 Posts: 59 Location: Palo Alto NewcomerBlackbat, I am working on the bug fix for the issue you brought up. As Drew mentioned, the fact that you sent a perfect Minimal Test Case and gave a clear explanation in your email made it easy for me to reproduce the problem and track down what was going wrong. The problem is that sections don’t work exactly how we describe them with respect to locked events, but I didn’t realize the difference could actually violate the implicit constraint that modules are constrained to a single section. Nobody has ever pointed this out, over many years, which makes your simple Minimal Test Case all the more impressive. I’ll circle back when I have a workaround or fix.
WillJoined: Feb 2018 Posts: 59 Location: Palo Alto NewcomerBlackbat, we just finished fixing the bug for the issue you brought up. The issue was that modules were not implicitly constrained to sections for locked events on modules with slats. Thank you again for the MTC. The fix will come out in a beta next week. In the meantime, a workaround is to add the constraint, “Modules constrained to a single Custom Script Field” and then copy the position names of the event rows into the Custom Script Field of the same rows.
BlackbatJoined: Jun 2019 Posts: 7 Location: United Kingdom NewcomerThat’s fantastic Will and DrewFinale! Many thanks for resolving this amazingly fast :-).
-
AuthorPosts
Please login to reply to this topic.