Distributing COS files
How to make COS files available for others to use in their worlds, without everything going hideously wrong.
If you've chosen to spurn the .agent PRAY file and just distribute your file as a COS file there are some things you should know what will ease this process and make the world a better place!
As you probably know, COS
files placed in a folder in the bootstrap directory are used to create new worlds,
so if someone places your COS in the bootstrap every time they create a new
world they will get your CAOS creation.
This has some advantages over .agent files in that they do not need to be individually
injected, and will appear in every new world automatically, but ironically this
can be a disadvantage too. If you are overwriting a COS file that shipped with
the game then you better hope you didn't make any mistakes ... and you better
make sure you provide a means for the player to get back the default behaviour
... because if there are any problems they will occur with *every* world created
and could lock the user out of the game.
There is a little publicised
function of the bootstrap folder that could help with COS distribution, specifically
it works like this:
-When a new world is created
it takes the COS files in *all* bootstrap folders to create a world ... and
it keeps an internal list of which folders it used to create the world.
- Next time you start a world it will check to see if any new folders exist
in the bootstrap folder (folders which it didn't collect COS files from), and
if there are new folders it will add the COS files in this to the world. NOTE:
it only checks whether the folder has been used before, not whether the contents
have changed.
This means it is possible
to create a COS file that can be added to all the worlds a user has, not just
new worlds, by creating a new folder within the bootstrap folder.
So how does this help the
user?
If you intend to create
a COS file for others to use you should provide instructions (or use an installer)
so that the user creates a new folder in the bootstrap directory
named after
the object in question. Then whenever a world is opened the COS will load
its contents into the world. Where this is an improvement over just placing
it in the 001 World folder is that it is now easily identifiable by the user,
and they can delete that folder if they want to get back to a default state.
Why take this approach?
At CLabs we have to deal
with the support issues that arise from 3rd parties ... and in some cases we
have to restore a users world to its default setting if they cannot identify
what has been added. To do this we will provide the user with a ZIP file containing
all the default COS files in the bootstrap, and so all 3rd party COS will be
removed.
If 3rd party COS are kept in a named folder then it makes it much easier for
the user, and also for support, to find out what is causing the problem.
Is there anything to watch
out for?
Yes. If you intend to distribute
a COS that overwrites an existing default COS then you need to write the install
part in such a way that it stops execution of the original object and then removes
it. If you just recreate the default COS in a new file and place it in the folder
in the bootstrap you will find that you then have 2 versions of the object (which
is probably not what you want). This method is much better than asking the user
to manually remove a file from the Bootstrap folder, because they can easily
get the world back to its default state by removing your new folder.
So in summary:
- Install new COS files
in a seperate folder beneath the Bootstrap directory.
- Write it in such a way
as to make it simple for the user to get back the default world and provide
instructions.
- If you intend to change
an existing object, write the COS so that it removes the original object and
creates a new one.
Topic Keywords: agent caos creatures3 dockingstation pray world tutorials
