The Machine

Found this comment in a thread on the PiLuD: free talks on Programming Language Design Google group.

https://groups.google.com/group/pilud/about?hl=en

"OOP is best used to model the program like a big machine - gears, stacks, queues, sensors and actuators, signals and data. If you do this, then a lot of problems are cleanly avoided."

David Barbour   Very apropos to MOO code programming.

I'm in print!

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

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

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.

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

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".

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.