Merging Worlds

[arty-fishL]

I have successfully come across a good way of merging worlds. This involves actually sticking code, events, variables, objects etc from one world into another .

WARNING - advanced

For a simpler, safer and probably better way of just linking worlds see my World Loader Tool.

This method avoids ambiguity be having each world as a separate object, rather than bundling all the stuff from each world into one world. This works kinda like it would with Java projects and packages, each dev has their own package so class names don't get mixed up.

To better describe this I am going to set up a scenario (based on a real question).
Task:

I'm teaching a course using Alice.
The students are working on a project as a team.
How can they merge together various parts of the project?

1: Firstly for each world to be merged the "world" object needs to be renamed. Each student should open up their world and give it a unique name. In this case each student should right click on "world", select "rename" and type in their name, plus extra initials if there are students with the same name. The result should be that each world object has a unique name.


2: All students should save their work and pass it on to the teacher so the teacher can merge the worlds, only when all the worlds are completely finished.

3: Now comes the laborious part, depending on how many worlds are to be joined. The students could do this part if the teacher can't be bothered and the students are trustworthy, but tbh if the teacher made such a decision as to merge them in the first place then they have placed this burden on themselves.
To make this less complicated I highly suggest creating a new folder and placing all the merge files in it.

4: Using 7zip, or another archiving application the teacher should open the first world and extract only the file called "elementData.xml"

5: Using a basic text editing program, preferably one that does xml formatting (like Notepad ++) the teacher should open the file they just extracted.
If a program that does not format the xml is used then the teacher will have a much harder time doing this, much harder. Notepad ++ is free, light and awesome anyway.

6: On line 2 the word "World" should be replaced with "Model". So the line reads:

<element class="edu.cmu.cs.stage3.alice.core.Model" name="studentx" version="2.001">

NB - "studentx" is the name of the student here, and subsequently the world, in every case "studentx" on line 2 should be different and unique to whatever the student called their world, if you change it you will ruin the whole merge.




7: The line that reads

    <child filename="renderTarget"/>

should be completely removed (it should be line 3).

Find (ie CTRL+F) the word "sandboxes" and replace it with "parts".


8: The file should be saved and put back into the world open in 7zip (or other archiving program) from whence it came, overwriting the "elementData.xml" already in it.

9: Steps 4 to 8 should be repeated for each world. If anything is done wrong then the whole process is ruined, so don't get impatient .

10: Each world should have its file extension change from .a2w (Alice world) to .a2c (Alice class/model)

10: A new blank base world should be opened in Alice. Save this as whatever the whole project is to be called.

11: Have the folder with all the worlds to be merged open next to Alice. Select all of the world files (now with .a2c extensions) together and drag them all onto the Alice window. Alice should go about importing every one.
If any message dialogs pop up just click "Yes" or "OK".
Click to view full size image:


12: Save the world before advancing.

13: Check everything is there. There should now be seperate objects, each in the same structure as all of the worlds saved and imported.
Test the world.
The code will most likely have to then be adapted to run everything when required, or to move stuff out of the way if it all imported on the centre.


Unfortunately anything stored in a group will not be visible in the object tree as only world objects can have groups, so, although its tidy to use groups, refrain from using them when doing this please.

Any questions, then just ask .

[Mr Kidnapper]

Hm. I recall being able to do it manually fairly easily. Extract a2w, copy folders, in the event of name collision rename, and copy-paste the proper

<item criterionClass="edu.cmu.cs.stage3.alice.core.criterion.InternalReferenceKeyedCriterion">

to their correct sections with all folders represented under the main element

<element class="edu.cmu.cs.stage3.alice.core.World" name="world" version="2.001">

Didn't need all this studentx stuff. In fact, that's how I made the spotlights for the VTOL.

In terms of scripting, you could detect the code

<property componentClass="edu.cmu.cs.stage3.alice.core.Sandbox" name="sandboxes">
<property componentClass="edu.cmu.cs.stage3.alice.core.Group" name="groups">
<property componentClass="edu.cmu.cs.stage3.alice.core.Response" name="responses">
<property componentClass="edu.cmu.cs.stage3.alice.core.Behavior" name="behaviors">
<property componentClass="edu.cmu.cs.stage3.alice.core.Variable" name="variables">

reading for the next </property>, and copypasta all the code inbetween to their respective sections. To proof yourself from namecollision, you can do this on a line-by-line basis, and go through the section looking for repeated names, and add a "1" or something to it in that event.

[arty-fishL]

No, that's what Gloo does, this is completely different.

For a start "studentx" is just the name of any student, it was just an example for the given scenario, it could have been Tim or Bob.

In the case of a teacher having to cater for a lot of worlds being merged avoiding ambiguity is impossible, due to the sheer amount of things being added. Events and other things that cannot be manually named are automatically named "event0" and such. That means there will be a definite overlap of event names. Just renaming objects or events like you said is not an option. This wrecks the code by making object references invalid and summoning all sorts of potential errors.

In the case of VTOL lights this was not merging worlds, but adding children to objects, a situation where ambiguity can be controlled.

The idea here is that each student has their own package, like Java, so when they are bundled together who done what can be kept track of, therefore improving maintainability and readability, which are required to be of good standing order as things are sure to need refinement upon merging.