1. Q: Can I use the EditiPackager in a project that is already started?

A: Yes, you can because EditiPackager simply adds a new tool to the iShell Editor.

2. Q: When I remove the EditiPackager plugin, why do I get a warning message "Corrupted File" when I try to open the project?

A: The iPackager adds extra configuration information to your project file (the .run file). If you need to remove this information, open your project file in a Text Editor. Here is what you will see:

 

SOURCE CODE 3

cInfoConfiguration

with

Flags is $00000004;

Copyright is "";

Comment is "";

end,

ciPackagerConfiguration

with

Flags is $00000004;

fLocationMediaDB is "Media/MediaDB.DBB";

end

 

Change this to:

 

SOURCE CODE 4

cInfoConfiguration

with

Flags is $00000004;

Copyright is "";

Comment is "";

end

 

Don't forget to remove the comma (,) character after the last end symbol..

3. Q: I just iPackaged my title for the first time, but when I run my title I got an error message that it "can't find the media xxxxxx". Why?

A: This means that your title can't locate the MediaDB.dbb file. Be sure you have placed it in the right media folder. For more information see chapter 3: Quick Start.

4. Q: Is it still possible to store media in a folder?

A: Yes. iPackager lets you control which media you store in the MediaDB. If iPackager can't find the media file in the MediaDB, it will look for it in the standard MacOS folder. As you can see, we haven't changed much about the way you work with iShell.

5. Q: How much extra memory does the iPackager library use?

A: As you have seen, iPackager generates 3 files: "MediaDB.DBB", "MediaDB.IN1" and "MediaDB.IN2". The "MediaDB.DBB" contains the actual media, "MediaDB.IN1" contains the search data for the MacOS platform and "MediaDB.IN2" contains the search data for the Windows platform. The files MediaDB.INx are read into memory during startup to allow a fast lookup. So to find out how much memory iPackager uses, take the size of one of the "MediaDB.INx" files and add an extra 50K.

6. Q: Can the size of the Search Index files be influenced?

A: Yes, they can. The size of the Search Index depends on the number of media and also on the length of the longest file name. If you use short names and don't use too many subfolders, your index files will be smaller.

7. Q: Is there a limitation on the MediaDB size?

A: The number of media stored in the MediaDB can't be greater then 65,535. This is just to keep the search index as compact as possible. If you need to surpass this limitation, please let me know. The MediaDB.DBB file itself can't be larger than 4 GB. This isn't a problem because the MacOS doesn't support files larger than 2 GB. The number of different File Types can't be greater than 256.

8. Q: Is it possible to store other Media types in the MediaDB?

A: Yes. As long as all the data of your media is stored in the datafork of the file, it can be stored in the MediaDB.

9. Q: What happens when the MediaDB is not stored in the right folder?

A: When the iShell title can't locate the MediaDB (for the MacOS this means if it can't locate the "MediaDB.DBB" file and the file "MediaDB.IN1") it will function as a normal iShell title and will use the files stored at their normal location. So, this means you can use the same application to work with the iPackager data or with the normal media.

10. Q: Does the Media database have to be named MediaDB?

A: No, the only thing that is important are the file extensions. DBB, IN1 and IN2. (for example, "DATA.DBB", "DATA.IN1", "DATA.IN2" are all okay). However, don't forget to also change the name in the Location window in the Project Palette.

11. Q: When I create a MacOS-only title, do I need the file "MediaDB.IN2".

A: No, you don't need it. For a Windows-only title, you don't need the file "MediaDB.IN1".

12. Q: What versions of the Compilers are used to build the libraries:

A:

o PPC Libraries are build with Apple "MrC" compiler version 3.0.1

o Windows Libraries are build with Visual C++ 5.0

13. Q: Some media files and screens don't appear in the generated media list file. Also when I do check project the '+' sign is missing for these media.

A: Check Project (and also iPackager) can locate URL's that are being used by standard commands like Browse, Switch, etc.... and new plugins that support this URL mechanism. You are using a plugin or a script that doesn't support this. Please contact the plugin developer on this.

Interim Solution:

Create some where on your main screen an event that never will be called for example, a disabled picture and then create a mousedown event. Then add a browse command for each of the missing screen. Usually you don't have to add all the screens, because some of these screen will call the other screens. So just add the main screens, so you are sure they all can be located.

14. Q Is my iShell title really going to run 2 to 4 times faster?

A: 2 to 4 are average speed enhancements, For example a screen with 1 big picture (200 kBytes) and 20 small pictures (24 Kbytes each) you can easily get a speed enhancements that is 4 times faster. On the opposite when you have 2 or 3 media's on one screen you won't see a big enhancements. We also noticed that most of our clients start building in other way their iShell titles because now a screen with a lot of small media opens very fast. Also QuickTime opens QTVR movies slow, so don't expect iPackager to enhance screens that contains QTVR movies.

15. Q How long does it take to accelerate my 200-screens based title?

A: Most of our clients didn't had to much problem in using iPackager, after a few minutes they had their first title accelerated. For those of you who are creating a 200-screens based title with 6204 media's, I can tell you that it takes about 17 minutes on a PowerPC 7200 32MB to accelerate your title. QTVR movies can take most of the time to incorporate in the MediaDB, sometimes even 5 minutes.

16. Q I just made my first title and when I check it on my ZIP drive on my Windows machine I don't see a speed gain?

A: A zip drive isn't the right device to check speed. You have to check it on a CD-ROM.

All the CD-ROM players have the same problem yes even those new 24x speeds. When they have to move to another location on the CD it takes about 1/5 of a second to move to that new position. A zip drive doesn't have this problem it moves fast from one position to another. If you want to verify speed you should check on a CD. When on your screen there is only one picture you won't see a big difference. But when you have a dozen of pictures on the same screen the CD-player has to move a lot and then you will notice the difference.

You have to know that on a DVD, the device that will replace the CD-ROM, the problem is even worse...