what is a best way of sharing scripts (MonoBehaviour classes) between projects.
thanx in advance.
Scripts should be okay to copy and paste in the finder. Dont drag and drop as that just moves them. copy and paste.
AC
yes, that is fine. But I am talking about centralizing the scripts, so that you don’t have to hunt down every copy of a given script in order to update it.
The point is to have exactly one copy of each script, and have all the projects that utilize it reference that single copy.
is there a way for this? or copy-paste is the best available option?
thanx all.
firas.
scripts have to be in the project folder. but you can create a set of scripts as a package like the Standard Assets (or just maintain a folder and copy them into assets like T said). but no if you update it in one project, it won’t update in others because you’re working with the file in the project folder.
Can’t you do something with symlinks at the OS level? I haven’t tried anything along those lines myself, but I don’t see why it wouldn’t work.
I was thinking the same thing with the symlinks. These aren’t exactly the same as OSX aliases so you’ll have to try and see which works. Aliases are easiest to create since you can do it through the GUI. If you end up needed a real UNIX symlink or hardlink, open the Terminal and use the ‘ln’ command.
The syntax is as follows:
Symlink: ln -s </path/dir-to-link-to> </path/alias-name>
Hard link: ln </path/file-to-link-to> </path/alias-name>
The difference between hard and sym links is that a symlink is marked as a link and can be moved/removed without moving/removing the original file. A hard link creates another entry in the file table that IS the file, but can’t be used for directories. It shows up as the actual file, but if you delete it from one dir, it will be deleted from the others as well.
Note that the directories must be full paths starting at the root level. Also ‘man ln’ will show the manual entry for the ln command for more info.
Jeff
hello guys,
I found a neat way to centralize reusable MonoBehaviour classes.
I code the classes, compile them, and add the dll generated by the compilation to the assets folder of my project. then whenever I need a behaviour I subclass the behaviour as a script in the assets folder, may be customize it a little, and then attach it to game objects.
hope it helps.
firas.
Symlinks don’t seem to work, but hardlinks do.
wow… i have never used a hard link before. I’ll have to look into it. Thanks for this info guys. This could really help clean up my Unity Projects. Without reusing assets from a centralized repository, asset proliferation - and asset evolution - is very difficult to keep under control.
This ended up not working very well…if you edit one of the linked scripts, the link gets overwritten with a new file. I made quite a mess before I figured out what was going on 
I know this thread is old but the way I’ve found to do it is through SVN externals.
Create a separate repository from your project that contains all the scripts you would like to share in all your projects. Then inside your project repository on a folder inside of Assets set an external property (google for more info) that references your shared scripts repository.
Presto you edit a shared script in one project, commit it and it’ll be updated in the other project the next time you update.
One thing to look out for is that externals always reference the latest version of files even if you get out an old version of your project. The way around this is to explicitly set the revision number on the external reference property with the -r option. This will then retain a history of what shared versions you were using but the downside is you have to bump this number in every project every time the shared scripts are updated. However this can be a good thing because it allows you to update scripts without having to worry about breaking your other projects. You can simply upgrade the other projects when you get around to it, or simply leave them on the old version of the shared scripts.
Anthony, about externals and nested svn:
I read on google “You could certainly setup such a scenario by hand—using svn checkout to create the sort of nested working copy structure you are trying to achieve. But if this layout is important for everyone who uses your repository, every other user will need to perform the same checkout operations that you did.”
My structure being small enough, doing this on all users is not a problem (the set-up part). You confirm it would work? (no externals here)
My question is: when we update/commit the root of project, will it then also update/commit the nested repository inside it or would you have to go in each and check there also? If I understood your reply well, with externals you are bound to set the revision to update manually each time, which is a pain, so I would prefer more user set-up but easier update/commits on all nested repository.
Thanks in advance
Any elegant solutions for this yet?
i like your user icon it is cool star trek rocks.