This content has been marked as final. Show 3 replies
If you are dragging items into the LDM, then I assume that the Stage shares a cast with the LDM. In this case is there any reason why it must be an LDM? Why not use a filmLoop? Here's a neat trick:
vFilmLoop = member(5)
vFilmLoop.media = the score
the score = vFilmLoop.media
You could use this to place the items inside the filmLoop, so that you can use its rect to crop the view port, and then make the Stage big enough to show all the items in the filmLoop, set the score to the media of the filmLoop, and print the Stage. As soon as you've done that, you restore the original score, and hey presto, your filmLoop is back in its view port again.
If you can handle my verbose Director 5 newbie Lingo, you might have some fun with this article:
Thanks James. You’re right, the main movie and LDM share a cast of parts. There’s no reason why the document object has to be an LDM. I was hoping the LDM would offer me a layer of abstraction, the goal was to create an API for window management (scrolling) and object manipulation (place, delete, move, group, rotate, etc…) but at this point the division of labor between the main movie and LDM is less clean than I wanted. I’ll look into film loops and see if it offers a better solution than LDMs.
If I have to stay with LDMs it should be possible to write a transform handler that scales and translates all sprites to fit on stage, print the stage, then put them back. It sounds messy but for now that’s my only idea if I stay with LDMs.
Sorry to resurrect an old thread. This project went cold but it’s back again and printing the oversized LDM is still an issue.
The ability to scale a film loop would provide a solution to printing, however, if I switch from an LDM to an interactive film loop is there some sort of document object model or communication (like tell) that will allow me to manipulate sprites (mostly loc and rot) within the loop? I read through your very informative tutorial and I noticed you move objects by shifting the reg point or rect of the cast member rather than changing the loc of sprites in the loop. Cool trick but what happens if the cast members are models dynamically assigned to sprite channels as the user throws these objects onto the stage? Wouldn’t modifying the member would move every instance of that member, not just a specific sprite?