Very new to LambdaMoo

[Douglas Whyte]

I've created a LambdaMoo localhost to mess around with and learn how to code in this language, out of curiosity, is there a way to prevent a full reset upon shutdown of the localhost? I'm using an Ubuntu VM and Telnet connection to the default Wizard. Unfortunately I had a crash and lost a lot of the stuff I was messing around with. Is there a way to prevent this from happening again or can I expect to have this happen to me in the future.

[Just Johnny]

Hey Doug,

This is what checkpoints are about. The MOO is running in memory, checkpointing writes out the MOO to the whatever.db.new file. Crashes happen, and you just start up from the last checkpoint. :)

Good luck on your adventure!

~ Johnny

On April 2, 2020 at 1:17:52 PM, Douglas Whyte (douglas...@gmail.com) wrote:

I've created a LambdaMoo localhost to mess around with and learn how to code in this language, out of curiosity, is there a way to prevent a full reset upon shutdown of the localhost? I'm using an Ubuntu VM and Telnet connection to the default Wizard. Unfortunately I had a crash and lost a lot of the stuff I was messing around with. Is there a way to prevent this from happening again or can I expect to have this happen to me in the future.

--
You received this message because you are subscribed to the Google Groups "MOO Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to MOO-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/MOO-talk/db0b62be-9ea3-4ed5-a4e2-ef51c9c36dbe%40googlegroups.com.

[Gilbert]

Hi All....  There is somebody there, Is;nt there?  I last got involved with MOOs over 25 years ago.  I was curious to see if they were still around and perhaps get back into MOO coding, which I loved!  It all seems pretty quiet though.  LambdaMOO seems to be ticking over, but does not have the hundreds of people it used to.  In those days, we had serious lag issues due to the numbers logging in! 

Anyway, please reply if there is anybody alive out there and a question:

I was trying to use @dump <object> with id=<new id>, following the syntax in the help, but no joy.  I rember using yhis a lot when learning MOO code the first time around.

Gilbert (on LambdaMOO)

[T. van Dijen]

Hi Gilbert,

@dump should work just fine if you are a $programmer..

- Tim

Op 10-9-2020 om 20:14 schreef Gilbert:

To view this discussion on the web visit https://groups.google.com/d/msgid/MOO-talk/14ed8d67-8787-4615-b8a2-07e6a7eb2d74n%40googlegroups.com.

[Littlefield, Tyler]

Hi,

Moo is still alive and kicking, although I can't really think of any
good communities out there that are active/doing something. A lot of
people are using this for their own projects.

Try adding create to the end of your @dump.


Lots of people are using Toaststunt:

https://github.com/lisdude/toaststunt

which is a spinoff of stunt, which is itself a fork of Lambdamoo. The
two latter projects don't get many updates, but lots of cool stuff
generally happens on toaststunt that you might find interesting.

HTH,

[Steven Owens]

Hi,

Yeah, mostly I hang out on Lambda. I still miss moo-coding. Every now
and then I dabble in it, usually to fix something in my code or
occasionally just for a lark. I think there was something about it
that just really worked well. I wish I could get that same feeling
from more modern/popular/accessible programming.

I looked at Stunt briefly, I'm a bit curious about Toaststunt. One
thing that was a big issue in the past, and I wonder about today, is
scalability, i.e. how many simultaneous connections can the server
handle?

Steve

> --
> You received this message because you are subscribed to the Google Groups "MOO Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to MOO-talk+u...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/MOO-talk/aecd182a-8c0d-6e54-f726-2e1f4a408c58%40tysdomain.com.



--
Steven J. Owens
steven...@gmail.com
pu...@darksleep.com
412-401-8060

[Gilbert]

Moo is still alive and kicking, although I can't really think of any good communities out there that are active/doing something. A lot of people are using this for their own projects.

Try adding create to the end of your @dump.


Lots of people are using Toaststunt:

https://github.com/lisdude/toaststunt

which is a spinoff of stunt, which is itself a fork of Lambdamoo. The two latter projects don't get many updates, but lots of cool stuff generally happens on toaststunt that you might find interesting.

HTH,

Ty and Tim,
                Many thanks for getting back to me.  Good to know that there is still life in the old cow..  Most of the websites and link to resouurces seem to be broken, although I could still find the old material.

I was thinking of running at least a local MOO from the Lamdba installation.  I did a small installation onto a Raspberry Pi, a few years ago, just to see it I could.  It worked find, although it was a bit short on space to grow.  I will check out those descendants of LambdaMOO and might go for those instead.  Perhaps take it a it further than the in-MOO coding this time.

I was aware of CoolMUD/ColdMUD, back in the day and even saw a pretty good Star Trek RPG that was obviously being used as a test-bed.  If I recall correctly, it had not just live disk-based databasing, but multple inheritance in the objects (more than one parent) which seemed to foffer all sorts of opportunities.  The last I read was that ColdMUD had spawned another project (Genesis?) but it had not seemed to have gone anywhere.

I am recenty retired from what became a non-technical career, so am keen to re-develop my coding skills in several areas, just as a hobby.

I do have the programmer bit in LambdaMOO and have tried adding 'create', that some of the other utorials and guides suggest.  No luck though.  Here is what I have tried, so far:

For an object I own (a $thing):

@dump #117323
@dump #117323 with id=#999
@dump #117323 create  with id=#999

All get me the 'I don't understand..' message.  I tried asking in-MOO, but everybody seems to be asleep.

Gilbert

[Gilbert]

Hi Steve,
           Yes, it certainly was an issue when these things were more popular.  I recall that there wawas a queing system: 'We're currently full.  Try again later' sort of thing.

One thing I recall seeing (back in the day) was an interst in cross-MOO portals.  I.e., as a character,  you move seamlessly from one MOO server to another, with the same character.  I think the intent, at the time was more to do with establishing a cross-MOO community, rather than a meta-MOO.  I know nothing about the underlying mechanics of that, although I can start to build a list of issues in my head.  It would mean that the load would be shared across servers and the whole thing might appear to be one landscape.  Perhaps this is already done in commercial development like 2ndLife.

It would be nice to see a distributed environment in the open-source community.  Would you transfer a package of character specif data from on MOO to another or store all character data ina central server  and call it in as a character moves across server boundaries?    I doubt that there is the need for such a system, but it would be tecnically interesting.

Gilbert

On Friday, 11 September 2020 at 02:03:22 UTC+1 steven...@gmail.com wrote:

[Tristan Bussiere]

Hello,

There are still quite a few (relatively) active MOO communities out there! You can see a list here: https://www.mudstats.com/servertype/moo

Currently the above link appears to be down, but Mudstats intermittently goes in and out of service; it may be back up by the time you read this. Another list that is updated by hand as opposed to the automated Mudstats spider is: http://moolist.com/

For MOO resources including object dumps, databases, programming guides, miscellaneous tutorials and list archives, you can go to https://www.lisdude.com/moo. This is a still-maintained mirror of MOO documents and it's updated rather frequently.

To my knowledge, the most active community of MOO programmers and builders is ChatMUD. While LambdaMOO still remains the most popular MOO in terms of users, many of them are very idle and over the years it's become more and more difficult to have real-time programming-related conversation and collaboration with a large number of users at once. CM is heavily in development and in flux, but there's a respectably solid number of programmery and technical types that frequent it with high availability. Smaller MOOs like Waterpoint are still around although you may run into the problem of also not getting an immediate response from many people there.

ChatMUD: chat.moo.mud.org 7777 (TLS: 7443)

Waterpoint: waterpoint.moo.mud.org 8301 (TLS: 8302)

As a sidenote since you mentioned Cold/Genesis, I thought it worth mentioning that Lisdude also hosts a resource page for this: https://lisdude.com/cold/. Further discussion regarding this should be directed off-list as it technically isn't MOO (MOO being used as a loosely unofficial way to refer to LambdaMOO and its derivatives).

ToastStunt has been updated with a threading library that is used by many of the builtin functions that have potential for being resource intensive. As a result, high numbers of users and resultant tasks executing heavy operations is much more feasible in 2020. The primary limitation in terms of simultaneous connections is file descriptors and whatever your defaults are in ulimit.

Hope this helps.

To view this discussion on the web visit https://groups.google.com/d/msgid/MOO-talk/76618c2a-e5e3-4b70-8536-548fe552dfd4n%40googlegroups.com.

[Jo Jaquinta]

>Would you transfer a package of character specif data from on MOO to another

>or store all character data in a central server  and call it in as a character moves across server boundaries?

*Way* back in the day on our College MOO I engineered a system a little bit like this, but between different *parts* of the MOO. When you left the "normal realm" (a room that descended from the vanilla room object) for the "fantasy realm" (a room that descended from the root fantasy room object) it would do a number of things. If it didn't already exist, it would create a child of your player object that had all the additional data on it needed to operate in the fantasy realm. (We called it "your fantasy soul" :-) ) When entering the fantasy realm it would then switch your active player object to that object, and back again when you left. It could also have a different name and description. Your inventory would also swap. So you would have your "fantasy objects" that you could only access while in the fantasy realm, and normal objects could not be brought into the fantasy realm.

The aim was to also have other realms, e.g. a sci-fi realm, and also to allow limited inventory transfer. If one realm recognized an object from another realm, it could let it stay in your inventory, or could be replaced with an equivalent object. (Magic swords becoming ray guns, etc.) If there was no recognition between realms, the transfer didn't happen. That allowed things to grow in an incremental way and allowed each realm to maintain its own integrity.

It was a long time ago, but it was the first significant object-orientated design that I worked on. I might even have some of the code lying around somewhere. :-)

In the context of this conversation, a cross MOO system might work similar to that, where the player's activity transferred. Their context would only transfer if there was a mutual understanding between the servers about the context objects. Otherwise what you had would be unique to that server.

Totally do-able, if there was the interest. Sadly the only people jazzed about text-based on-line communities these days are the visually impaired.

In Second Life you did have frequent transfer between servers. (Each sim could be on a different server.) There was seamless overlapping. However, all servers used the same data-store, and the same logic. So it was a different problem set than faced by a MOO. For a while we had cross operation between Linden Lab's public Second Life servers and IBM's private servers (my day job is with IBM), but it was buggy and I really, really, really screwed up my inventory via it. :-(

Cheers,

Jo

To view this discussion on the web visit https://groups.google.com/d/msgid/MOO-talk/bb2a96e2-5a4c-4a23-a860-fefac2243b0dn%40googlegroups.com.

[Steven Owens]

On Fri, Sep 11, 2020 at 8:26 AM Gilbert <gjl...@mail.com> wrote:

> Yes, it certainly was an issue when these things were more popular. I recall that there wawas a queing system: 'We're currently full. Try again later' sort of thing.

Yeah, that was because of lag. Then again, it's been what, 25-30
years? Machines are more powerful now...

I'm going to stick this up here, so it doesn't get buried below, then
respond to your comments:

If anyone's curious, ages ago I built MMCP, Moo-to-Moo-CoPy,
documented in $note #60980 on LambdaMOO. It's essentially a more
structured version of @dump that, given an object, produces a huge,
hairy mess of lists-of-lists-of-lists, along with code to reconstitute
an object from that hairy mess. At one point I had a prototype
working between two MOOs, one of the big things of course is that the
MOO needs to be compiled with support for outbound connections, and
you need a player object on one of the MOOs to accept the incoming
connection. If I recall correctly, somebody had built a simple generic
networking set up that I plugged into.

> One thing I recall seeing (back in the day) was an interst in cross-MOO portals. I.e., as a character, you move seamlessly from one MOO server to another, with the same character. I think the intent, at the time was more to do with establishing a cross-MOO community, rather than a meta-MOO. I know nothing about the underlying mechanics of that, although I can start to build a list of issues in my head. It would mean that the load would be shared across servers and the whole thing might appear to be one landscape. Perhaps this is already done in commercial development like 2ndLife.

> It would be nice to see a distributed environment in the open-source community. Would you transfer a package of character specif data from on MOO to another or store all character data ina central server and call it in as a character moves across server boundaries? I doubt that there is the need for such a system, but it would be tecnically interesting.

Yeah, it'd be interesting but you'd have to figure out the purpose and
design the solution to suite.

For the most part those systems used smart MUD clients, very much like
an HTTP redirect, i.e. you would hit a portal or whatever on MUD1, it
would send a string that your client would intercept and interpret as
a command to exit and reconnect to MUD2.

There are various obvious limitations with this, though you could
easily work out a system to address them if you assume all of the MUDs
are running some kind of base layer code to facilitate it. First,
your player object on MUD1 just disconnects and sits there. Second,
you need a player object on MUD2. Third, possessions, etc, don't
transfer over. Fourth, most of those portal systems had no provision
for where you appeared in MUD2. Fifth, there is/was very little
coordination between the muds at the time.

It'd be much more straightforward to build something like this today,
but it ultimately boils down to how much information and control you
want to share between the muds. If it was purely for scalability
purposes, i.e. the same people control all the MUDs/MOOs involved,
then you'd stukk need to work out some back-end, OOB features for
sharing/replicating data between the muds, specifically:

a) player accounts,
b) object inventories,
c) object prototypes (e.g. ancestors),
d) managing state

"Managing state" is a catchall for issues like sticking the player
object in MUD1 in limbo or something, when they bounce off to MUD2,
and conversely pulling the matching player object on MUD2 out of limbo
and placing it wherever the portal sends them.

Steve/Puff

> To view this discussion on the web visit https://groups.google.com/d/msgid/MOO-talk/bb2a96e2-5a4c-4a23-a860-fefac2243b0dn%40googlegroups.com.

[Twoshrubs]

Hello Gilbert,

I hide here in the shadows. I miss the good old Moo'ing days.. I used hang around a couple of UK based Moo's back about the same time period. Cannot remember the names as it was a lifetime ago, one was Lord of the rings based and the other was Discworld based. For some reason back then I had a passion for animating veggies(mostly cabbages).. lol, the follies of youth eh!

Sorry I cannot help out with the commands as I havent been on a Moo in alot of years but it looks like plenty of people can help :)

Stay safe,

Twoshrubs

[lisdude]

It looks like you're a $builder in LambdaMOO. To use @dump, you'll need to become a full-blown programmer or use a feature (I consider it an exploit, but it was confirmed to be a feature years ago) that allows you to change your parent to $prog and use (some of) the verbs available there.

I'd recommend the first option. You can find the information to get going in 'help programmer-bits' on LambdaMOO.

The second option is also easy, but you'll be some kind of quasi-programmer monstrocity. To go this route, simply: @chparent me to $prog

Have fun!

[seve...@gmail.com]

Hey Gilbert -

You could check out ChatMUD which does have a good amount of people on in its active community: http://pubclient.sindome.org/player-client/?gh=chatmud.com&gp=7777

Slither

[Littlefield, Tyler]

For what it's worth:

player data could very easily be stored as a restful API that each MOO would use to authenticate and validate players before getting a player ID and returnning that number. Toaststunt has CURl support, or you could exec curl to make the API call.

If all MOOs worked together, maybe even by exposing their own API, you could very easily make the MOO that handled the connection just proxy the new connection for where the player went. enter a portal from a->b->c? cool, a disconnects from b, then hands over the connection to c. Toaststunt's proxy protocol support makes this super easy and you could still translate across the data.

We also have JSON for translating and compacting data into something that can be deserialized at the other end easily.

My point mostly in all of this is that we've progressed 30 years. Bandwidth isn't really the issue anymore, and lots of improvements to MOO have been made in the performance department, along with compiler optimizations. I was doing some simple profiling with my game and had about 50000 entities running around without much issue at all, once I tuned things a bit. There were also other things going on in the background. There are still certainly some issues, but offloading a lot of work to threaded builtins makes a huge difference.

--

Take Care,
Tyler Littlefield (he/him/his) Tyler Littlefield Consulting: website development and business solutions. My personal site My Linkedin @Sorressean on Twitter

[Gilbert]

to TwoShrubs.

Yes, that certainly is helpful.  LOts for me to chase down there.  I must have missed the discworl MOO.  Damn it.

Gilbert

[Gilbert]

Hi All,
      Last night, I had a go at installing LambdaMOO (yes, I now know there are better servers, but I hought I would start easy).

I followed the 'no frills' instructions at:

https://twat.ca/how-to-install-a-lambdamoo-1-8-1-server-with-lambdacore-database-on-ubuntu-12/

Basically:

First, I installed a C compiler (gcc)

cd ~
(I was connected as root, if that makes any difference)
wget http://lambda.moo.mud.org/pub/MOO/LambdaMOO-latest.tar.gz
tar -zxvf LambdaMOO-latest.tar.gz

cd MOO-1.8.1
./configure

apt-get install byacc

make

wget http://lambda.moo.mud.org/pub/MOO/LambdaCore-latest.db.gz
gzip -d LambdaCore-latest.db.gz

./moo LambdaCore-latest.db new.db 7777 &

This all went very smoothly (although, I may well have missed an error message in all that output).  'Too good to be true', I thought. And, of course, it was.

Tried t telnet to the server, but could not connect.

The MOO is running on a Ubuntu desktop and I am using putty from a Windows PC on the same home network.

I have looked around for a trouble-shooting doc on running the LambdaMOO server, but while there are a lot of documents of varying vintafes out there, I could not find anything that was concerned with running the server.

I confess that I have forgotten what little I knew about Linux and am getting back up to speed, so make no assumptions that I have a clue what I am doing here.

Does anything obvious spring to mind?

Gilbert

[Gilbert]

Woo Hoo!  My MOO is running aftr all.  I just ran the moo script again and I was in business.

Gilbert