Wonderblog
Project Wonderland Virtual World Toolkit Blog
Updated: 3 days 7 hours ago
New Project Wonderland Blog
As one of our first steps following the news last week, we're happy to report that we have relocated the Project Wonderland blog. The blog is now on WordPress with the following URL: http://blogs.projectwonderland.com. See you there!
Good News and Bad News
I know everyone likes to get the bad news over with first, so I'll start with that. We found out on Friday that development resources are no longer being applied to Project Wonderland.
The good news is that those of us who have worked so hard to bring this project to life still wholeheartedly believe in it. A core group of the Wonderland team intends to keep the project going. We will be pursuing both for-profit and not-for-profit options that will allow us to become a self-sustaining organization. Having anticipated this possible outcome, we already have some promising irons in the fire.
As a first step in this next phase of the project, we will be releasing a Wonderland v0.5 Preview 3 release early next week.
There is so much great momentum behind Wonderland. To our knowledge, there are currently three companies offering Wonderland-related products, and eight companies offering Wonderland world-building services. There are countless exciting university projects and a number of corporations that have seen the advantages of Wonderland over other platforms. We are seeing new people posting on the forums almost every day.
Any concrete help you can give us would, of course, be welcome, but what we are asking for now is your moral support and your continued participation in our thriving community. Let's stand together in our determination to keep this project moving forward.
If you would like to contact me privately, please feel free to do so at nicoley @ dev.java.net.
Community Test Today
In case you don't read the Wonderland forum, I wanted to let people know that there will be a community test today at 10am PT / 1pm ET. We'll be using the following server:
http://wonderland.sunlabs.com:8080/
The test will run approximately an hour and will be conducted like a regular event with speakers. Here's the agenda:
- Introduction and Networking
- Opening Remarks, Nicole Yankelovich
- University of Oregon Research, Kathryn Aten & Taryn Stanko
- Scripting, Morris Ford
- Particle System, Ryan Babiuch (aka Jagwire)
- Debriefing
We ask that everyone who joins the test please do the following:
- Wear a headset - no open speakers please
- Join the IRC chat at: irc://irc.freenode.net/wonderland
- Use the new error reporting feature if necessary (Help --> Error Log --> Error Report)
- Send error reports to: dev@wonderland.dev.java.net
Hope to see you there.
Nicole.
Tooltips in Wonderland
Last week I posted a new module to our (brand new!) Module Warehouse. It's the Tooltip module. I originally wrote this module as an example of how to develop Cell Components (which are called Capabilities in the UI). I really do intend to write a tutorial around this example, but for now, I decided to upload it to the Warehouse. You can of course get the code too: it's in the unstable/ section of the wonderland-modules project (see this tutorial for instructions on how to download this, and other, module source code).
The Tooltip module displays a tooltip in the HUD when a user hovers over an Object in the world. To add the Tooltip Capability, right-click on the Object and select Properties... from the context menu to bring up the Object Editor. Then click the '+' in the lower left-hand corner of the Object Editor (see picture below). Choose the Tooltip Capability from the dialog which appears and click OK. Then in the Object Editor, select Tooltip in the Capabilities list, enter the tooltip text on the right and click Apply.
The following shows how to display some simple text in the tooltip:
What's cool about the Tooltip Capability (if I do say so myself), is you can enter HTML text as well. Just enclose your text in the <html>...</html> tags. Although the available support for HTML is limited, I've tested some common tags like <br> (to achieve multi-line tooltips), <b>, <table>, and even <img>.
The pictures below show an example of displaying formatted text in a tooltip:
Language Learning in Wonderland
Today's guest blog post is from Dr. Michael Gardner of the Digital Lifestyles Centre in the School of Computer Science & Electronic Engineering at the University of Essex in the UK. Dr. Gardner and his colleagues are one of the earliest adopters of Wonderland. You may recall his work on the MiRTLE project to create a mixed-reality teaching and learning environment. In today's article, Dr. Gardner describes a new language learning project his team is working on in conjunction with their Department of Language and Linguistics.
The SIMiLLE project at the University of Essex has just completed a formative evaluation of a virtual world designed to support second language (L2) learners. This is based on the use of the Project Wonderland platform. We are currently using Wonderland version 0.5, Preview2.
The following video demonstrates the formative evaluation trial that was completed in December 2009. Here, the group of language learners log into the SIMiLLE virtual world and are split into pairs. Their task is to explore the world and organise a visit to London. To do this they must visit various sites in the virtual world including a train station, and they can also make use of in-world tools such as shared web browser and notepads.
The participants were five student volunteers recruited from the Department of Language and Linguistics at the University of Essex. All participants were speakers of English as a foreign language at upper intermediate level. The participants’ mother tongue included Arabic, Turkish, and Thai. All participants were computer literate, but none of them had any experience using 3D virtual world environments.
The tasks were designed following a needs analysis procedure in consultation with the various stakeholders including language tutors and students of English as a foreign language. As a result, the role-play task was based on a real life scenario which students in the UK would probably encounter on a regular basis. As part of the evaluation we will be looking at the practicality and acceptability of the platform, the authenticity of the experience, the language learning potential, and the overall impact on the teaching and learning processes. In relation to the core objective of providing participants with opportunities for L2 development, the task did provide learners with opportunities to practise listening, speaking, reading and writing in the L2. They also engaged in negotiation of meaning; they had opportunities to pose questions, make requests, ask for information, clarification, and practice functions such as agreeing and disagreeing.
The participants reported that it was easy to interact in SIMiLLE and they identified the following characteristics as contributing to a positive experience:
- The training documents were useful and helpful in enabling independent use of the world.
- SIMiLLE has the potential to help students learn about UK cultural aspects.
- The role-play task simulates real-life activities and can, therefore, prepare them for their stay in the UK.
- The environment has potential to simulate real places.
- They found the opportunity to use in-world applications such as sticky notes and Web browser motivating and potentially useful.
- They also considered the ‘sharing’ of those applications an asset to promote interaction.
- The use of avatars might help ‘shy’ students to interact more freely than in a face-to-face situations.
- The use of avatars can help individuals to ‘explore different identities’.
The results from this formative stage are being used to refine the world and design a longer trial in conjunction with the International Academy at the University of Essex.
The SIMiLLE project is funded by the Joint Information Systems Committee in the UK.
Dr. Michael Gardner
First Community Module Submission
Craig A.D. Walters from the Department of Chemistry at the University of the West Indies in Jamaica made my day today. He is the first community member to contribute a module to the new Wonderland Module Warehouse. His module, called "Magnetic Susceptibility Measurements," models something called the Gouy Magnetic Susceptibility setup. On the Project Wonderland at the Chemistry Department, UWI-Mona web site, Craig and his collaborators write, "In our teaching laboratory the Gouy experiment can take upwards of several hours to complete and with a class of over 100 students this is a major timetabling problem."
Jonathan, Jordan, and I tried out the Wonderland version of the experiment and it took just a few minutes to run through the steps. We didn't understand much about the chemistry involved, but we did get the gist of what was going on. Jon, of course, figured it all out first and used his telepointer to show Jordan and I how to step through the experiment and view the results. My one request for enhancement would be to network the application so that everyone in-world could see the experiment as it's taking place.
It's exciting to see Wonderland being used to teach real science. Great contribution Craig!
Module Warehouse Featured in New Wonderland Web Site
We are pleased to announce that we have unveiled a new Project Wonderland web site today. This web site, which you can access by navigating to ProjectWonderland.com, will now be the main portal for the project. Developer-focused content (e.g. wiki, forums, subversion) remains on the java.net open source developer site, but most other content has now been migrated to the new portal. Please spend a few minutes exploring the site to see some of the new content and learn how to find the pages you depend on.
Module Warehouse
Module Warehouse
The most significant new feature is the Wonderland Module Warehouse, where you can download modules in their binary form that have been created either by the core team here at Sun or by the community. As you may know, modules (similar to "plugins" in other systems) add functionality to the core platform and can be easily installed using the Wonderland Server Admin web console.
To get to the Module Warehouse, click on the large green "Browse" button on the home page. You'll find that the Sun Labs core team has already seeded the Warehouse with a selection of modules. We invite you, members of the community, to use the Module Warehouse to share your custom extensions to Project Wonderland with others. On the Module Warehouse page, you can browse available modules by category, search for modules using keywords, or submit your own module (complete with instructions on how to do so).
(As a note: We have compiled and tested all of the modules in the warehouse against the latest version of the software--aka the 'trunk'. You can get the latest software in binary form from the nightly builds).
We would be happy to hear your feedback on the new site and we look forward to seeing the Module Warehouse collection grow with your contributions.
Project Wonderland Forum Back Up
After 10 days, our discussion forum is back up. It's great to start hearing from community members again after such a long dry spell.
There is also progress to report on restoring the wiki. The wiki software has been upgraded to eliminate the problematic security issue, but we're still waiting for the current data to be restored. As of now, the data from August 21st is there, so that doesn't include most of the 0.5 documentation and tutorials.
I'm hoping that before the Sun Labs team leaves for the week-long holiday break starting on Friday, that the site will be back up and running in its entirety.
Java.net Situation
As many of you probably know, the Project Wonderland open source site has been experiencing an extended outage on java.net. The site was attacked by hackers who apparently exploited a security hole and did considerable damage. The news today is unfortunately not encouraging. The service provider, CollabNet, says they believe it will take at least another 24 hours before we can expect to see the forums and wiki back on-line. The one bit of good news is that the whole site is not down. You can still access the home page, the binary download page, the source code repository, and the issue tracker.
We are by no means the only open source project impacted by the outage. Sun has sent a number of employees over to CollabNet to help with the process of getting things back up and running. In the mean time, we will use the blog to keep you up-to-date on the situation. We apologize for the outage and will continue to pressure CollabNet to restore service as soon as possible. Let's keep our fingers crossed that we haven't lost too much data.
Update: I have learned today that the outage has occurred on a portion of the java.net system that is not operated by CollabNet. Since I have minimal information on the topic, I'll refrain from saying more. We'll have to wait for the people in charge of java.net to provide us with a detailed account of the outage and what they have done to correct the problems.
Groovy Wonderland
Our guest blog post today comes to us from Douglas Finnigan of the School of IIT at Temasek Polytechnic in Singapore. In addition to his superb introductory tutorials (Wonderland Development, Basic Concepts and Wonderland Development, Intro to Modules), Douglas has been working on ways to simplify Wonderland programming using Groovy. In this article, he also describes a simple particle system that can be used for weather simulation.
For the past six months, I’ve been part of Sun’s Co-Space project in Singapore, using Wonderland to develop a framework to run and visualise simulations inside a virtual world. An early piece of work was to read the Yahoo! weather RSS feed and visualise the local weather conditions. I was interested in getting dynamics to work in Wonderland, and had already experimented with cloth, so decided to use particle systems for the weather. All we needed was to show basic weather, such as rain and snow (not that it ever snows in Singapore!), so I decided to create a few simple particle systems which could be swapped in and out depending on the weather condition-code number. My first thought was to hardcode each particle system in Java, but this kind of went against the grain. I wanted a way for someone to add, update and load a particle system without having to dig in and modify the module’s source code.
Which is where Groovy came to the rescue.
Groovy has what are called Builder classes, for the (relatively) easy building of hierarchical data models, with built in support for XML, Ant build files, Swing development and more. You can also create your own builders for customised model building. So, after some trial and error in getting Groovy to work with Wonderland (via Netbeans and a fair bit of Ant hacking), most of the module’s code is now written in Groovy. Groovy classes are compiled to byte code, and as long as everything is built in the correct order, Groovy-Java integration is problem free.
The way the Groovy weather module works
is that particle systems are defined in a simple, declarative-style
markup script. For JMonkeyEngine particles, some attributes are
simple primitive values, while others, such as the various influence
types, are objects, which must also be defined in the script. So, the
basic script structure is:
A simple example is given at the end.
The classes for reading a script, parsing the data, generating an object tree, making sure the correct methods are called with the right arguments, and then putting this all together to create a particle system object, are all written in Groovy. Scripts are stored on the server, and loaded via url whenever a new weather code arrives from Yahoo!. Scripts can be modified and re-loaded without having to stop and start the Wonderland server. Actually, to speed things up slightly, scripts are pre-processed into a hashmap of particle system objects – this can be improved, but the project was just a simple demo and is now happily retired. (Although since this basic framework can be used to define and create other objects, not just particle systems, it may get resurrected at some point.)
The question is probably: why Groovy? My answer is: speed. Not runtime speed, but development speed. Groovy has an incredible amount of support for IO, list and String processing, meta-programming and reflection (a crucial part of this project), and the removal of great swathes of boilerplate code. For example, reading and extracting data from the Yahoo! weather feed took only five lines of code. In another project, the use of Groovy closures has been invaluable. It would now be very painful to go back to Plain Old Java. The only real drawback is the lack of compile-time error checking, which I can live with. (Scala, which is type-safe, might be even better than Groovy, though I haven’t looked at this yet.)
Rather than extend this entry beyond its allotted shelf-space, I hope to add a tutorial on integrating Groovy with Wonderland soon. (Note, this isn’t about using Groovy as a scripting language for Wonderland, but as part of module development.) I’m constantly amazed at how well designed Wonderland is, especially for extensibility, and the integration of Groovy is yet another example of this. Many thanks to the Wonderland team for their great work, and also for the opportunity to share this blog entry with everyone!
Appendix
Simple example:
Node(prefix: "com.jme.scene", args: "rootNode"){ attachChild { ParticleMesh (id: "pSystem", args: ["snow", 1500]) { localTranslation ([0.0, 8.0, 0.0]) startSize 0.075 endSize 0.055 startColor ([1.0, 1.0, 1.0, 0.5]) endColor([1.0, 1.0, 1.0, 0.0]) Texture ("snow.png") renderState { BlendState { blendEnabled true enabled true } } geometry { Ring { outerRadius 10.0 } } emitterTransform { TransformMatrix (args: "quat") { Quaternion (id: "quat", args: [0.7071f, 0.0f, 0.0f, 0.7071f]) } } addController { ParticleController (id: "contr", args: "pSystem") { repeatType Controller.RT_CYCLE controlFlow true speed 0.10 addInfluence { WanderInfluence { wanderDistance 0.75 wanderRadius 0.01 wanderJitter 0.01 } } addInfluence { BasicGravity { gravityForce ([0.0, -0.01, 0.0]) rotateWithScene true } } } } } }dot Wonderland: Redux
Way back in v0.4, I wrote a blog, dot Wonderland, that described the contents of the "dot" directory that held meta-information, configuration information, and cached assets for Project Wonderland. It was meant to be an under-the-covers peak into some operational details for those who were interested and users, who like me, just love to twiddle with files every once in a while. I've been meaning to update that blog post for v0.5, so here we go.
In that earlier blog, I posted an important disclaimer that is worth repeating: modify the .wonderland and .wonderland-server directories at your own risk! Since the information contained in these directories are implementation details and not part of any public API, anything posted here is subject to change without notice.
The .wonderland-server/ directory
In Version 0.5, the files associated with the Project Wonderland server and client are now kept in two separate directories: .wonderland-server/ and .wonderland/, respectively. The structure of the .wonderland/ directory has not changed much since v0.4, so the information described by the dot Wonderland blog is still mostly correct. There are some changes, and I'll talk about those in another blog.
In this blog, I'd like to focus on the files pertaining to the server, in the .wonderland-server/ directory. First off, Project Wonderland keeps files for each revision of v0.5 in separate directories. If you are working with the main line source code (aka the 'trunk'), then files are stored beneath the 0.5-dev/ directory. If you are working with 0.5 User Preview 2, then files are stored beneath the 0.5-preview2/ directory. Once v0.5 is finalized, I'd imagine the files would be stored under the 0.5/ directory.
Keeping the files for each of these sub-versions separate really helps development: we can run and debug each of these different subversions on our development machines at the same time. Users who upgrade from, say 0.5 User Preview 1 to 0.5 User Preview 2, need to manually copy some files if they wish to keep state across these sub-versions. Hopefully the details contained in this blog will make this process a bit easier.
Log files, runtime state, worldsIf you take a look at the ~/.wonderland-server/0.5-dev directory (here, '~' denotes the user's home directory), you'll see three subdirectories: log/, run/, and wfs/.
Log FilesThe log/ directory is perhaps the easiest to explain, so let's start there. The directory is only one level deep and contains a bunch of text files (with the .log file extension) -- they are the log files for various Project Wonderland server components. The primary one is the web server log, the latest of which is web_server.log.0 (older versions from previous times the Project Wonderland server was run can be found in web_server.log.1, web_server.log.2, etc).
There are three other log files that always appear in this directory: one for the Darkstar server (darkstar_server.log), one for the Voice Bridge (voice_bridge.log), and one for the Shared Application Server (shared_application_server.log). You may also view these web files via the Web-based Administration UI.
A fourth log file (darkstar_server_snapshot.log) is only created if you take snapshots of your world (see WFS: The Wonderland File System in v0.5 for more details).
Worlds and SnapshotsThe wfs/ directory contains all of the initial worlds and world snapshots. Each is stored as a collection of XML-formatted files. The structure of the way these XML files are stored on disk is defined by the Wonderland File System (WFS). WFS has evolved in v0.5 since earlier releases, and the WFS: Wonderland File System in v0.5 blog succinctly describes the contents of the wfs/ directory.
Not mentioned in the blog, however, is the recordings/ directory that you may see underneath the wfs/ directory. The recordings/ directory contains the state stored by the Event Recorder, an experimental module that performs 3D recordings inside the virtual world.
The run/ directoryI left the run/ directory as last to describe for a reason: it's fairly complicated. This directory contains all of the installation information for the Project Wonderland server (including its various server parts, including the Darkstar server, Voice Bridge, and Shared Application Server). It also contains the "live" state of the virtual world (in the form of BerkeleyDB, an embedded database), an up-to-the-minute persistence mechanism that is implemented by the Darkstar middleware layer. The run/ directory also contains the content area for the embedded WebDav server that is bundled with Project Wonderland.
Here's the directory listing that I current see in ~/.wonderland-server/0.5-dev/run:
content/ docRoot/ webserver/ darkstar_server/ shared_application_server/ wonderland.version deploy/ voice_bridge/ wonderlanddb/ derby.log webdeploy/
Perhaps it's best to start off by describing which directories you can ignore for now: docRoot/, webserver/, darkstar_server/, shared_application_server/, deploy/, voice_bridge/, wonderlanddb/, and webdeploy/. These directories either contain information regarding the implementation of Project Wonderland's modular server architecture (i.e. deploy/ and webdeploy/), it's embedded web and application server (i.e. doctRoot/ and webserver/), or one of the server components that help implement the virtual world (i.e. darkstar_server/, shared_application_server/, voice_bridge/, and wonderlanddb/).
This leaves the following directory: content/. This directory serves as the content root for the WebDav repository. (WebDav, if you are not familiar, is simply an extension to HTTP, and let's us manage content on the web server remotely by clients). Some of the content stored in this directory is visible to ordinary users via the Project Wonderland client: the Content Browser (Tools -> Content Browser) displays all of the content found beneath the system/ and users/ directories here. For example, if a user drags-and-drops a model or an image or a PDF file into the Project Wonderland client, it gets uploaded to his/her space beneath the users/ directory.
The content/ directory also contains other information that is not visible to ordinary users, but is nonetheless important. It is information that is needed by the client software, so placing it in the WebDav content area was natural and eased its distribution. In fact, all modules installed into Project Wonderland are stored beneath the modules/ directory, and more specifically, the modules/installed/ directory. Feel free to browse the modules/installed/ directory for a bit: it's layout is relatively simple. You'll see a directory per module and the contents of the module JAR file expanded beneath that directory, along with some XML-formatted text files that describe the module. There is no other hidden registry of installed modules: its existence in the modules/installed/ directory is all that is necessary. (Incidentally, if you are ever in a position where you'd like to manually remove all of the installed modules in the system, simple clear out the modules/ directory and restart the server. On the flip side, to install a module, it's best to go through the normal mechanisms, e.g. the Web Administration UI).
The final directory beneath content/, the checksums/ directory, contains checksums computed for various assets in the system. These checksums are computed when a module is installed and is used by the caching mechanism in the Project Wonderland client to determine when it needs to download a new asset, for example.
Migrating Important Data from One Version to the NextIf you've built a world, in say 0.5 User Preview 2 and want to migrate the state of that world to, say the latest trunk, then the information above should provide you with the means. By and large, it's a simple matter of copying the proper files from one directory to another. I've tried this out myself by building a simple world in 0.5 User Preview 2 and then migrating the files so that I have the same world if I want to use the most recent Project Wonderland codebase (the trunk).
Using 0.5 Preview 2, I first installed the Clickable Link module (from the unstable/ section in the wonderland-modules workspace) [1] and created a simple world in 0.5 User Preview 2. I dragged-and-dropped a PDF file, which created a PDF Viewer in-world. I added a Sticky Note. I imported a 3D (.kmz) model using the Insert -> Model menu item and uploaded it to the server, placing it in a module named SatelliteModel. I then took a snapshot of the world (to preserve its state) and exited the client and killed the server.
Next, I ran the server using the trunk codebase. This populated the ~/.wonderland-server/0.5-dev/ directory. I then installed the Clickable Link module [1]. (I'm just using Clickable Link as an example; you will need to re-install any modules you had installed manually when using 0.5 User Preview 2). I then killed the server for the time being.
As a next step, I manually copied over key directories from the 0.5-preview2/ directory into the 0.5-dev/ directory. Here's what I did:
- Copy the SatelliteModel/ directory in the ~/.wonderland-server/0.5-preview2/run/content/modules/installed/ directory to the ~/.wonderland-server/0.5-dev/run/content/modules/installed/ directory. Since I imported the model via the Insert -> Model menu item, it packaged the model into a module and installed it on my server. This first step copied that module from my old installation to my new installation. (You should do this for any model you installed this way). Related to this is Step 2. Note that models that have been dragged-and-dropped into the world are uploaded to WebDav, and migrated in Step 3 below.
- Copy the SatelliteModel/ directory in the ~/.wonderland-server/0.5-preview2/run/content/checksums/modules/ directory to the ~/.wonderland-server/0.5-dev/run/content/checksums/modules/ directory. When modules are installed, the system computes checksums for certain of their assets. Since I manually copied the module from the previous installation (Step 1 above), the checksum-generating step did not occur for my new installation. Manually copying the old checksum computation should be sufficient.
- Copy the users/ directory in the ~/.wonderland-server/0.5-preview2/run/content/ directory to the ~/.wonderland-server/0.5-dev/run/content/ directory. This copies over all of the content that was uploaded to the server when I dragged-and-dropped content into the world. (If you placed content in the system/ directory, you may wish to copy that over too). Update: Actually, if you've created system-wide Placemarks via the Web Admin UI, you will need to copy the system/ directory for sure.
- Copy the snapshots/ directory in the ~/.wonderland-server/0.5-preview2/wfs/ directory to the ~/.wonderland-server/0.5-dev/wfs/ directory. This copies over the snapshot I took after I created my world in 0.5 User Preview 2.
After these four steps, I restarted the server running the latest Project Wonderland codebase and restored to the snapshot I took in 0.5 User Preview 2 that I copied over to my new installation. After I restarted the client, I saw the world as I left it in the previous version of the software.
While these manual steps should not take too long to do, a migration tool to perform the migration automatically would be a big help. If you are interested in writing such a tool, I think it would make an excellent contribution from the community.
[1] When I wrote this blog, the Clickable Link module was kept in the unstable/ section of the wonderland-modules workspace. It has since been promoted to the stable/ section and is now bundled with Project Wonderland.
Reviewing Wonderland Code In-World
As the Wonderland core team, we spend a lot of time using Wonderland. We use it for meetings, we use it for collaborative work, and we even use the world for socializing. But this week we tried something new: a group code review in Wonderland.
Code reviews are an on-going process that we usually work on asynchronously: I email out the code for review, and the reviewers get back to me once they have gone through it. While this is effective for small changes, in this case we wanted to review a large amount of code with the whole group. So we decided to get together in world and discuss the code together, almost like a reading group.
The biggest challenge was getting the code into world. We could have brought a NetBeans editor into world, but that would force everyone to have the same view. Instead, we used Drew Harry's slide spreader app to display PDFs of the source code. We found it works much better when everyone has their own view of the source. That way we can assign people to break out of the main discussion and answer specific questions before joining the main group again. And by using the spatial layout, we can always see at a glance where everyone is. Here is what it looks like in-world:
Overall, it worked pretty well. We were able to explore the code both as a group and individually. And seeing the code sweeping off into the distance definitely gave a sense of how much there is to review!
There is still plenty of room for improvement. We had to make the slides very big to make them easier to read, but this makes it hard to align your view with the slides. It would have been great to be able to see the code in the HUD. Also, there is no syntax highlighting and no ability to jump to other parts of the code, which would have sped things up significantly. All this got me thinking it would be nice to have a lightweight shared code viewer -- maybe based on JSyntaxPane -- to use in world. Sounds like a new module to write...