Exchanging moho files with intact image links

[box]

Hi, how can I exchange moho files with other animators so that the links to images remain intact?
Let say there are images which are inside different folders for organisation purposes. I save the moho file above these folders and all is fine. But when I send the moho file to another animator who has exactly the same folders on his harddisk, some of the links get lost, especially when there are subfolders, too.*
If moho saves the relative location of these files, exchanging files should not be a problem.
Of course I could put all stuff inside the same folder, but this would get quite large and difficult to deal with. Also, I can not do it with the Procect I am already in, it would mean to rename a lot of files and to reassign them all.
Can anyone tell me how to deal best with this situation?

(*Just the name of the parent folder containing all is different, but this should make no difference, I think.)

[Rasheed]

I always use ZIP archives to share my Moho projects with others. Seems to work fine.

[box]

Yes, but this would require to send ALL the stuff every time a change is made....

[Rasheed]

You don't have a password protected server for sharing files I presume. I guess that would be my next guess for a solution, with a concurrent version system (CVS) of course, just as open source software developers seem to use on their sourceforge projects. And WebDAV is a technology you might want to look into as well, because it allows you to treat a remote server as a disk volume on your desktop. And that is very userfriendly.

[rylleman]

I use my files on a couple of different machines and the solution I'm using is that I edit the moho file in a text editor (SciTe) where I replace all of the old paths (F:/projekt/) with the new one (D:/+PROJEKT+/), then saves the file with some new name and open it in Moho, now everything has it's correct paths.
Only thing is that you need to have the same project structure on all machines.

[box]

AH, rylleman, this is brillant.

So moho uses ABSOLUTE paths. It just seems to ignore a "wrong" link when the image file is placed in the same folder as the moho file.

I would have much preferred a relative path, but with a text editor you can handle this problem...

@ rasheed: I don't think that this problem is related to the use of webservers, since the link to the image refers to the absolute pathnames on the machine the file is created on. Except, when all files are in the same folder.

[macton]

I don't think that this problem is related to the use of webservers, since the link to the image refers to the absolute pathnames on the machine the file is created on. Except, when all files are in the same folder.

Moho only uses (usually) absolute file names if the image was is located in a folder above the folder the moho file is in. If the files are in subfolders of the folder the moho file is in, it should be relative.

You can see exactly what paths Moho is using by using the "List External Files" script.

If the files have been moved you can use the "Relink Lost Images" script to find and reconnect them.

The scripts are here:
http://www.lostmarble.com/forum/viewtopic.php?t=2448

See also these threads:
http://www.lostmarble.com/forum/viewtopic.php?t=2089
http://www.lostmarble.com/forum/viewtopic.php?t=1710

And in the FAQ:
http://www.lostmarble.com/forum/viewtopic.php?t=1314

[box]

It gets better and better!

But I could not get the script to work, I received an error like this:



What does that mean?

Thanks, Ralf

[macton]

What does that mean?

Looks like there was a bug. I've updated the script. Download it again and try it out.

Mike.

[box]

Sorry,




Mike, is it possible that scripts referring to file actions are not compatible with Mac OS? I get always such messages when trying scripts like these.

Anyway, thanks a lot for your effort.

[Rasheed]

Running the CC:Relink Lost Images script only gives problems in Mac OS X if your images are on a different drive than the boot drive. If your images are on the boot drive, there are no problems as far as I can see.

That os.getenv("OS") keeps giving nil values in Mac OS X.

Programming in Lua states the following:

The os.getenv function gets the value of an environment variable. It receives the name of the variable and returns a string with its value:

Code: Select all

    print(os.getenv("HOME"))    --> /home/lua

If the variable is not defined, the call returns nil.

Obviously, this value "OS" is not defined in the Mac OS X environment. Perhaps something similar is happening in this and other Lua scripts which use the os.getenv function (or similar functions).

System dependent features can be sooo tricky.

[macton]

Rasheed may be right... When I get a chance I'll have to test out everything on my OSX box and see if I can find any problems.

[7feet]

Macton - I think the problem here is that you tried to make the GetOS() function a little craftieras far as avoiding a nil everinment variable and all that. But in this case, I think that's the problem. The original I made

Code: Select all

function SF.getOS()
	local opSys = string.lower(string.sub(os.getenv("OS"), 1, 3))
	if opSys == "win" then
		return "win"
	else
		returnb "unix"

	end
end

looks to see if the OS is Widows, and if it's not assumes it's a *nix variant. Never had any problems with that part, and it's a safe assumption unless you've intentionally done something odd to you Windows OS environment variable.

In this script it the "CC_RELINK_LOST_IMAGES.getOS()" function all the way at the end of the script. Swapping in the body of the old function should probably tune that up if someone want's to try it.

To spell it out, open the script in any text editor and replace the "function CC_RELINK_LOST_IMAGES.getOS()" block with

Code: Select all

function CC_RELINK_LOST_IMAGES.getOS()
	local opSys = string.lower(string.sub(os.getenv("OS"), 1, 3))
	if opSys == "win" then
		return "win"
	else
		returnb "unix"

	end
end

resave the script, and that should do the trick. It's slightly kludgy, but it worked previously.

[macton]

To spell it out, open the script in any text editor and replace the "function CC_RELINK_LOST_IMAGES.getOS()" block with

Code: Select all

function CC_RELINK_LOST_IMAGES.getOS()
	local opSys = string.lower(string.sub(os.getenv("OS"), 1, 3))
	if opSys == "win" then
		return "win"
	else
		returnb "unix"

	end
end

resave the script, and that should do the trick. It's slightly kludgy, but it worked previously.

I think I'll look into a bit.
That was exactly what was in there in the last version when the problem was reported.

... and the last error above which was that it couldn't write the temp file into the home directory (~) implies that it decided unix just fine. But a write error into the temp file in the home directory is a little odd.

[Rasheed]

I downloaded the GUI application RCEnvironment to set your environment variables within a preference pane (using the System Preferences). I set the "OS" key to a "mac os x 10.3.9" value.

Now the

Code: Select all

returnb "unix"

returned this error:

So I fixed that error:

Code: Select all

return "unix"

and pressed <cmd><f5> to reload the scripts. After rerunning the script I got this error:

It seems the CC_RELINK_LOST_IMAGES.createSubDirList function creates an empty table, because there is a write error. I will try to debug this function and tell you what I've found. Mind you, I have only little programming experience and limited knowledge of Lua, so it may take a while before I can provide you with probable answers.

I think that the Moho application doesn't have any environment variables defined (at least not the OS variable), while the Windows version has (otherwise your script wouldn't run). I could be mistaking, because it is possible that Windows has defined these variables system wide.

So, a workaround for Mac OS X would be to use RCEnvironment to set the environment variables. It can also be done by creating a property list file in ~/.MacOSX/environment.plist, but I guess most Mac users will be a bit hesitant using Terminal (the resident CLI).

Edit: As it turns out, using this app also solves the problem of os.getenv("HOME") giving a nil value. I assume RCEnvironment does this without user interference.

Edit2: If you edit ~/.MacOSX/environment.plist manually or with RCEnvironment, in both cases you'll need to log out and log in to enable the property list.