I just received my copy of Teaching Literature in Virtual Worlds
This very interesting collection of articles, edited by Dr. Allen Webb of Western Michigan University, includes a chapter by me "On the Building of Worlds".
Very cool, if I do say so myself.
The articles discuss many of the Worlds created at Literary Worlds, which is hosted at Western Michigan here: http://brn227.brown.wmich.edu:7000/
Ciao
KJ
Thursday, November 3, 2011
Friday, October 14, 2011
New AJAX updating Room files available at the Barn
I have put the files for the new room up at the Barn.
You can get the zip file here:
http://www.encore-consortium.org/Barn/files/objects/EnCore/rooms_with_ajax.zip
The zip has two files one, ahah2.js, is the javascript that handles the AJAX communications. This file should be put in a directory called edit_area in the root of your encore directory. The other file is an @dump of a room with the auto updating capabilities for the objects list.
This room has a property called js_base_url which is used if you cannot store the ahah2.js file in the encore directory. As long as the directory you have access to is on the same server as the moo it will work.
It is currently set to my directory at Literary Worlds so make sure you change it to your directory or set it to 0.
Let me know if you have questions or problems and also how it works for you if you try it out.
If you just want to see this room in action you can check out the test room at Literary Worlds by logging in as a guest at: http://brn227.brown.wmich.edu:7000/
Once logged in @go to #5446
There is a box there you can pick up and drop to see the update in action.
Enjoy
Ciao
KJ
You can get the zip file here:
http://www.encore-consortium.org/Barn/files/objects/EnCore/rooms_with_ajax.zip
The zip has two files one, ahah2.js, is the javascript that handles the AJAX communications. This file should be put in a directory called edit_area in the root of your encore directory. The other file is an @dump of a room with the auto updating capabilities for the objects list.
This room has a property called js_base_url which is used if you cannot store the ahah2.js file in the encore directory. As long as the directory you have access to is on the same server as the moo it will work.
It is currently set to my directory at Literary Worlds so make sure you change it to your directory or set it to 0.
Let me know if you have questions or problems and also how it works for you if you try it out.
If you just want to see this room in action you can check out the test room at Literary Worlds by logging in as a guest at: http://brn227.brown.wmich.edu:7000/
Once logged in @go to #5446
There is a box there you can pick up and drop to see the update in action.
Enjoy
Ciao
KJ
Monday, October 10, 2011
New Experiment: Room contents display enCore V4
Continuing along on my experimentation with the user interface in enCore v4, it occurred to me that one of the issues I've had is how the room display is static, relative to the text side. Where this can be an issue is with a busy class all logged in at once. The text side is flying with all the comings, goings and chatting amonst the class members, while at the same time the room display, with the list of contents and exits, is frozen. Only a look command or click on the look icon will refresh it.
Several times I have entered a room with people chatting and they did not notice me entering because the text message scrolled past, lost in the chatter, and at the same time the list of the rooms contents didn't change either. They were quite surprised when I started talking!
How to get around that?
Here is my latest experiment... AJAX, Asynchronous Javascript and XML. This is the underpinnings of the infamous WEB 2.0 jazz we've been hearing about for years now. I found a small javascript file called AHAH, Asynchronous HTML and HTTP, which is a simple implementation of AJAX that only deals with html rather than XML. You can read about it here: http://microformats.org/wiki/rest/ahah
What this javascript file does is allow us to update PARTS of a webpage on demand or automatically without reloading the whole page. For my experiment I had it update the contents display of the room every second. The javascript calls a verb on the room that sends back the current list of objects in the room. The code then checks to see if the contents have changed since the last time and if so it updates the list in the display.
Very cool.
I had to change the SPANs with classes to DIVs with ids, which needed a bit of CSS gigerypokery to line up, but that was it.
The javascript file is very small so does not add any delay to the page when first loaded.
A pleasant surprise was the way the code was able to access the verb on the room, it did not need any path info at all, it knew the host it was being called from and simply returned the verb output without complaint. (Not sure why that works frankly)
This tool should have great use for interactive objects, since pieces of the display can change without having to refresh the whole lot. Think of communication devices, games, viewports, graphics displays etc. According to the notes with the javascript there can be multiple instances of the updaters on the same page.
I will try to put the code into a package for the Barn in a bit.
Several times I have entered a room with people chatting and they did not notice me entering because the text message scrolled past, lost in the chatter, and at the same time the list of the rooms contents didn't change either. They were quite surprised when I started talking!
How to get around that?
Here is my latest experiment... AJAX, Asynchronous Javascript and XML. This is the underpinnings of the infamous WEB 2.0 jazz we've been hearing about for years now. I found a small javascript file called AHAH, Asynchronous HTML and HTTP, which is a simple implementation of AJAX that only deals with html rather than XML. You can read about it here: http://microformats.org/wiki/rest/ahah
What this javascript file does is allow us to update PARTS of a webpage on demand or automatically without reloading the whole page. For my experiment I had it update the contents display of the room every second. The javascript calls a verb on the room that sends back the current list of objects in the room. The code then checks to see if the contents have changed since the last time and if so it updates the list in the display.
Very cool.
I had to change the SPANs with classes to DIVs with ids, which needed a bit of CSS gigerypokery to line up, but that was it.
The javascript file is very small so does not add any delay to the page when first loaded.
A pleasant surprise was the way the code was able to access the verb on the room, it did not need any path info at all, it knew the host it was being called from and simply returned the verb output without complaint. (Not sure why that works frankly)
This tool should have great use for interactive objects, since pieces of the display can change without having to refresh the whole lot. Think of communication devices, games, viewports, graphics displays etc. According to the notes with the javascript there can be multiple instances of the updaters on the same page.
I will try to put the code into a package for the Barn in a bit.
Saturday, August 6, 2011
New Xpress Program Editor coming along nicely
Good Day All
I have continued to mess around with my revised Program Editor for V4 enCore.
My latest experiment has worked pretty well, surprisingly.
This version has added the ability to insert Breakpoints into a verb so that execution of the verb will stop and the values of selected variables will be spooled out to the programmer. The programmer then has the option to continue the execution of the verb or to kill it. This is most useful when troubleshooting looping code as the Breakpoint can be used to allow a kind of step through, examining the loop as it executes.
I have a version of my Ewebbed enCore package that includes the new editor. I will be putting this up at the Barn shortly.
While the new editor works OK, it is pretty rough and I'm sure there are some gotchas so the usual cautions about using beta class software apply :-) I would be interested in any comments or suggestion you might have so please send them along.
I would also really appreciate anybody who has a good handle on verb and html security to take a look at the way I've set this up, to make sure I haven't left any massive security holes anywhere. The Checkpoint and Breakpoint verbs must be Wiz owned which always makes me a bit nervous.
Ciao
KJ
I have continued to mess around with my revised Program Editor for V4 enCore.
My latest experiment has worked pretty well, surprisingly.
This version has added the ability to insert Breakpoints into a verb so that execution of the verb will stop and the values of selected variables will be spooled out to the programmer. The programmer then has the option to continue the execution of the verb or to kill it. This is most useful when troubleshooting looping code as the Breakpoint can be used to allow a kind of step through, examining the loop as it executes.
I have a version of my Ewebbed enCore package that includes the new editor. I will be putting this up at the Barn shortly.
While the new editor works OK, it is pretty rough and I'm sure there are some gotchas so the usual cautions about using beta class software apply :-) I would be interested in any comments or suggestion you might have so please send them along.
I would also really appreciate anybody who has a good handle on verb and html security to take a look at the way I've set this up, to make sure I haven't left any massive security holes anywhere. The Checkpoint and Breakpoint verbs must be Wiz owned which always makes me a bit nervous.
Ciao
KJ
Wednesday, June 29, 2011
Revising the User Interface in enCore
Here is a "blast from the past". At least this one is in the current century.
This is a post I made to the enCore mailing list way back in 2005.
What is interesting to me is that many of my comments seem to still apply. If anything they are more applicable now. Plus I know way more about how enCore works so it is actually feasible to do this myself.
So many projects so little time :-)
Thanks for reading.
KJ
=================
http://mirror.lardbucket.org/encore/0002.html
From: Kevin Jepson
Date: Wed Aug 17 2005 - 16:12:20 CDT
Good Afternoon Folks
Ok, here is one way I think we could easily change the interface to bring back some of the immersive qualities that we have been talking about.
Note: "easily" is relative, Daniel might not agree :)
The following is a crude cut and paste mock-up using my version 4 EnCore MOO.
You'll notice that it is pretty much a standard version 4 layout when set for horizontal.
This horizontal layout is important, IMHO, because it ties into the scrolling text structure, unlike the vertical one which forces the user to switch "back and forth". This layout does reduce the graphics space available for illustrations within the room description a bit without scrolling, though.
The list of users shown on the right hand side could also be a version of the "Who Frame" that Daniel has added to V5.
If a hidden frame was used for that a similar hidden frame could be used for the contents. While that would reduce the space for the description even more it would fix the layout. That way when moving, objects, people and exits could easily be updated and kept current without loosing them in the refresh or to the vagaries of the rooms decorations.
The "Exit Frame" lists the obvious exits of the room and makes them clickable. The key thing here is that the link is the DIRECTION of the exit. A user can also type that direction in the chat to move as well. The exit frame would update only when the user moves and could be updated by the look cmd.
I would also make sure that exit messages were turned back on so that the users would get feedback on their movements and those of others.
This isn't really a big change but I do think it would drastically change a users perception of the "space" in which they are "moving".
This is a post I made to the enCore mailing list way back in 2005.
What is interesting to me is that many of my comments seem to still apply. If anything they are more applicable now. Plus I know way more about how enCore works so it is actually feasible to do this myself.
So many projects so little time :-)
Thanks for reading.
KJ
=================
http://mirror.lardbucket.org/encore/0002.html
From: Kevin Jepson
Date: Wed Aug 17 2005 - 16:12:20 CDT
Good Afternoon Folks
Ok, here is one way I think we could easily change the interface to bring back some of the immersive qualities that we have been talking about.
Note: "easily" is relative, Daniel might not agree :)
The following is a crude cut and paste mock-up using my version 4 EnCore MOO.
You'll notice that it is pretty much a standard version 4 layout when set for horizontal.
This horizontal layout is important, IMHO, because it ties into the scrolling text structure, unlike the vertical one which forces the user to switch "back and forth". This layout does reduce the graphics space available for illustrations within the room description a bit without scrolling, though.
The list of users shown on the right hand side could also be a version of the "Who Frame" that Daniel has added to V5.
If a hidden frame was used for that a similar hidden frame could be used for the contents. While that would reduce the space for the description even more it would fix the layout. That way when moving, objects, people and exits could easily be updated and kept current without loosing them in the refresh or to the vagaries of the rooms decorations.
The "Exit Frame" lists the obvious exits of the room and makes them clickable. The key thing here is that the link is the DIRECTION of the exit. A user can also type that direction in the chat to move as well. The exit frame would update only when the user moves and could be updated by the look cmd.
I would also make sure that exit messages were turned back on so that the users would get feedback on their movements and those of others.
This isn't really a big change but I do think it would drastically change a users perception of the "space" in which they are "moving".
Thursday, June 9, 2011
Javascript, moo code and webpages Oh My!
It seems that sometimes a bad Internet connection is a good thing.
I've been on a sort of "Busman's Holiday" out to Vancouver Island and the Sunshine Coast over the last two weeks. During that time we have generally had an Internet connection of some sort, but it has almost always been a bit intermittent.
Normally this state of affairs would be sub-optimal for me to be sure.
This time however, I took the opportunity to apply myself to learning the esoteric art of JavaScript coding... Don't laugh, I have never had to do anything with it before now!
What got me thinking about this was how well the Edit Area Javascript package worked when I integrated it into the Xpress Program Editor in V4 enCore. You can see some screen shots of the editor here . The Edit Area Javascript package was created by Christophe Dolivet and can be downloaded here .
The Edit Area system adds a lot of nice capabilities to the enCore editor without using much if any MOO code. I figured "how hard could it be to do something like that?" Heh...
After two weeks of reading from one of those 2" thick 4lb dead tree chunks, that purports to be "everything you need to know", and lots of experimenting on a copy of my Ewebbed enCore package running in a Virtual Box copy of XP on my Ubuntu EEEpc Netbook (?!?), I managed to add a "debugger" to the program editor.
I've been on a sort of "Busman's Holiday" out to Vancouver Island and the Sunshine Coast over the last two weeks. During that time we have generally had an Internet connection of some sort, but it has almost always been a bit intermittent.
Normally this state of affairs would be sub-optimal for me to be sure.
This time however, I took the opportunity to apply myself to learning the esoteric art of JavaScript coding... Don't laugh, I have never had to do anything with it before now!
What got me thinking about this was how well the Edit Area Javascript package worked when I integrated it into the Xpress Program Editor in V4 enCore. You can see some screen shots of the editor here . The Edit Area Javascript package was created by Christophe Dolivet and can be downloaded here .
The Edit Area system adds a lot of nice capabilities to the enCore editor without using much if any MOO code. I figured "how hard could it be to do something like that?" Heh...
After two weeks of reading from one of those 2" thick 4lb dead tree chunks, that purports to be "everything you need to know", and lots of experimenting on a copy of my Ewebbed enCore package running in a Virtual Box copy of XP on my Ubuntu EEEpc Netbook (?!?), I managed to add a "debugger" to the program editor.
Friday, May 6, 2011
Tinkerers Rules
Sometimes you come across something that encapsulates ones whole view of a subject into a single image.
This comic by David Malaki of Wondermark does that for my view of coding for MOOs.
Much of what I have learned and the projects I've done have been glorified "tinkering". This is a pretty good set of rules all told.
Thanks for reading.
KJ
This comic by David Malaki of Wondermark does that for my view of coding for MOOs.
Thanks for reading.
KJ
Sunday, April 17, 2011
Shiny new Ewebbed enCore Package available at The Barn
I have just uploaded a revised version of my Ewebbed enCore package to the Barn for download.
This version incorporates the new Xpress Program Editor and also includes a copy of the Neil Fraser's MOO Inspector. You can download the complete package from this link.
The instructions and some documentation is here:
For those of you who are not familiar with the Ewebbed enCore package allow me to explain.
One of the hurdles I had when first learning to code for LambdaMOO based systems was the lack of places to experiment. Pure text based systems were pretty rare and open ones that allowed new users to be programmers were even rarer! So I went looking for a way to easily setup a local MOO to play with.
One of the hurdles I had when first learning to code for LambdaMOO based systems was the lack of places to experiment. Pure text based systems were pretty rare and open ones that allowed new users to be programmers were even rarer! So I went looking for a way to easily setup a local MOO to play with.
Sunday, April 10, 2011
So What?
Some days it doesn't pay to get excited about new things.
Doesn't pay, that is, if by "pay" I mean that others share in my excitement.
When I discover something new, a new tool, a new way of doing something, I tend to want to share that discovery/excitement with others. When that new thing is related to a somewhat esoteric technological system, like MOO programming for instance, I suppose I shouldn't really be surprised if most of the people around me do not share the excitement.
At least I would hope that other people who use the same system might be able to use it too.
Working with Virtual World systems, especially relatively archaic ones like MOOs, which are designed to be shared and used by others, means that if nobody uses them there is no feedback. It is literally like tossing ones work out to sea in a bottle, hoping somebody finds it.
My enjoyment of working with these systems should remain even if nobody else ever uses it.
I guess that is the key, as long as I am interested in it then it is worth my time to pursue. If other people subsequently have a use for the stuff I'm doing that is great too.
I'll just keep right on sending those bottles out on the Cyber Sea.
Hopefully you will find something here worth your time as well.
Thanks for reading.
KJ
Doesn't pay, that is, if by "pay" I mean that others share in my excitement.
When I discover something new, a new tool, a new way of doing something, I tend to want to share that discovery/excitement with others. When that new thing is related to a somewhat esoteric technological system, like MOO programming for instance, I suppose I shouldn't really be surprised if most of the people around me do not share the excitement.
At least I would hope that other people who use the same system might be able to use it too.
Working with Virtual World systems, especially relatively archaic ones like MOOs, which are designed to be shared and used by others, means that if nobody uses them there is no feedback. It is literally like tossing ones work out to sea in a bottle, hoping somebody finds it.
My enjoyment of working with these systems should remain even if nobody else ever uses it.
I guess that is the key, as long as I am interested in it then it is worth my time to pursue. If other people subsequently have a use for the stuff I'm doing that is great too.
I'll just keep right on sending those bottles out on the Cyber Sea.
Hopefully you will find something here worth your time as well.
Thanks for reading.
KJ
Subscribe to:
Posts (Atom)