A text Myst Online project

[Christopher]

I think a better way would be to write a demonstration age and set the accsesslevel for the person you want to show it to CREATOR. This person should then be able to also edit/look into the code of the age. Maybe a CREATOR flag with readonly accsess would be helpful.
That's, of course, not yet possible, but maybe it could be implemented.

Christopher

[Pavitra]

I think a better way would be to write a demonstration age and set the accsesslevel for the person you want to show it to CREATOR. This person should then be able to also edit/look into the code of the age. Maybe a CREATOR flag with readonly accsess would be helpful.
That's, of course, not yet possible, but maybe it could be implemented.

Christopher

I don't think that ability to view the code is based on access levels. A player has access.CREATOR on their personal instance of every age, but that doesn't confer the ability to peek at the code. That is, source code permissions are per-world, and access levels are per-instance.

[Christopher]

I don't think that ability to view the code is based on access levels. A player has access.CREATOR on their personal instance of every age, but that doesn't confer the ability to peek at the code. That is, source code permissions are per-world, and access levels are per-instance.

In theory you should have access.OWNER on your personal instances... Also if you can set access.CREATOR for other players and they can see the code after that, it would be possible for groups of players to build an age together... I don't know if and how easy this would be to implement. It's only a suggestion

Christopher

[Pavitra]

I don't think that ability to view the code is based on access levels. A player has access.CREATOR on their personal instance of every age, but that doesn't confer the ability to peek at the code. That is, source code permissions are per-world, and access levels are per-instance.

In theory you should have access.OWNER on your personal instances... Also if you can set access.CREATOR for other players and they can see the code after that, it would be possible for groups of players to build an age together... I don't know if and how easy this would be to implement. It's only a suggestion ;)

Christopher

The documentation indicates access.CREATOR, and my own testing confirms this.

[belford]

The datetime and timedelta objects are Python native classes, described at http://docs.python.org/3/library/datetime.html. However, I haven't exposed most of their methods in the script environment. Feel free to request more of those features.

Yes, the access level stuff is confusing. I probably shouldn't have used "CREATOR" as a label -- it has nothing to do with world-creation. The intended meaning has to do with group scopes, except I haven't implemented group scopes yet.

(It will be analogous to the MOUL process of "creating a neighborhood" -- which actually creates a group of related instances, such as the GZ. This will be possible in Seltani; the group scope will potentially include instances of every instanceable world. You would have "creator" access to all of them, and you could start assigning "member" or "owner" access to other players. However, this does *not* grant you code-editing rights.)

[belford]

I have now added the on_enter and on_leave hooks. You can put most any code in there -- but not move() statements; that would lead to some nasty recursive traps.

I've added a bit of polish to Seltani District. You can now stand in the rooftop garden and hear people link into the ferry dock. If you're watching the dock, you can even wave at them. :)

[belford]

Other recent comments:

Being able to see code in the world: I wound up putting just enough sneaky stuff into my Ages that I decided not to publicize the code. I figure there will be some sort of wiki someday, and we can put code samples into that.

I don't plan to support multiple players co-editing a world. If you want to organize shared authorship for a world, you can coordinate having a shared player account too -- it won't be your biggest challenge. :)

However, maybe I should have a world flag that says "anybody can see the code".

Tablet use: I have only tested it on my iPad, where it works nicely. The system doesn't use any weird browser features except for websockets. A few people have reported websocket failures (on various browsers and computers). Best I can suggest right now is to go to http://www.websocket.org/echo.html and try the demo (press the Connect button, then Send). If that doesn't work either, then you have some kind of network issue that blocks websockets.

[Pavitra]

The signboard at the dock currently says "Turn right to find some Ages that I’ve created.". Could this be changed to read "Turn right to find some Ages that we’ve created."?

More substantially, some way to correctly handle verbs for players with the "they/them" pronoun set. [$are] would be helpful; so would a [$s] that evaluated to the empty string for "they" players and 's' for all others. Most powerful (but most difficult to use) would be a variable along the lines of player.plural or player.pronoun, so that we could build our own logic.

(Example usage: "[$Name] ducks into the cupboard. A second later, [$they] return[$s] with a handful of cookies." This would become "they return", "she returns", etc. as appropriate.)

(Oh, and a capitalizing [$Name] token, so that a name doesn't have to look like a name.)

...And as long as I'm at it, a pony a way to communicate data between different scopes and different worlds.

[belford]

I've updated the signboard -- good call.

I thought about the "they/them" issue a while back. Then I set up the very first message with a pronoun -- "[$Name] pops a jelly bean into [$their] mouth" -- and tested it with the "them" pronoun. "Fred pops a jelly bean into their mouth." Totally fine! (Assuming you accept the singular "them" in the first place.) So I dropped my plans for "is/are", etc.

However, your example is also correct. If I had written "[$They] pops a jelly bean into [$their] mouth", I would have needed a different verb. So I'll add this to the list.

Capitalizing name token: I assume you're thinking of cases like "the Doctor pops a jelly bean into her mouth."(*) This is obviously tricky, because there's also "e. e. cummings pops a jelly bean into her mouth." Whether the name should be capitalized is somewhat contextual. In any case, the system is always going to generate lines like "the Doctor says 'Hello.'" so I think that people will choose names that fit in that format.

Communicating between different worlds: definitely important. It will have to require two-way cooperation, though. (World X cannot affect world Y unless world Y is specifically build to accept changes from world X.) I haven't yet come up with a scheme that's easy to deal with.

(* I know what you're about to say, but I think the Doctor would be totally okay with substituting jelly *beans* for jelly *babies* if she were visiting the States.)

[Pavitra]

I don't see an easy communication model either. World and scope addressed by ObjectIDs, hopefully some sort of local variables or aliases to make the code cleaner, world.scope.prop... I can imagine a usable model, but not one on the caliber of usability that Seltani has demonstrated so far.

...Or what if we drop the idea of addressing worlds and scopes directly by literals? A function that returns the scope corresponding to a given player ID, like scope(player). Instances could read their own scope and world IDs directly. Copy a link from your booklet to the realm-properties page to make the the link's world addressable by name -- world('Dusty Hill') -- from within the copied-to world. (Obviously this would not confer permissions to access anything usefully; that would be separate.)

Meanwhile, in "things I can actually do", there is now an intermittent bridge in Tsani-Tsina, and a guestbook and a boot counter in Terelin.