3 ms·

I have not played MUDs in a long time, but, when I did, I always just got by with Tintin++. I never went all the way and wrote an actual bot that could run una

I have not played MUDs in a long time, but, when I did, I always just got by with Tintin++. I never went all the way and wrote an actual bot that could run unattended, because there were so many different things that could really mess up your bot, or, at least cause it to act impolite, that it looked like more trouble than it was worth. Also, I wasn't that great at scripting with tt++. :P I was, however, (literally) a wizard with LPC.

pimlottc 6y ago
Yeah, I also got heavily invested in tt++ scripts but never fully automated. It was great back in the day but there were definitely some eccentricities that made advanced difficult - lack of proper lists, awkwardness dealing with empty strings, weird scoping and special variables, no dicts. I recently dusted off my old files and tried to get it running in the latest version but there were so many breaking changes that I just gave up trying to fix it. It would be fun to try to make a proper fully automated bot, though as you said, there are so many different contexts and possible text prompts itd be difficult to make it truly reliable. I wonder what the best approach would be - some kind of classic AI goal system or newfangled ML? (If I had the time to start over, I’d probably use Mudlet since it uses a proper scripting (lua) instead of something that got hacked together over time. Though it’s a bit GUI-reliant for my tastes)
- pmiller2 6y ago
  Yeah, tt++'s programming model is essentially a finite state machine with a single global scope. If that sounds hard to work with, it is. I think if I were starting over, I'd go with a client that's extensible in a real language, whether that be Lua, Python, Ruby, Scheme, elisp, etc., simply so I could take advantage of modern programming language features.

3 ms·

I have not played MUDs in a long time, but, when I did, I always just got by with Tintin++. I never went all the way and wrote an actual bot that could run una

by pmiller2 6y ago

pimlottc 6y ago
Yeah, I also got heavily invested in tt++ scripts but never fully automated. It was great back in the day but there were definitely some eccentricities that made advanced difficult - lack of proper lists, awkwardness dealing with empty strings, weird scoping and special variables, no dicts. I recently dusted off my old files and tried to get it running in the latest version but there were so many breaking changes that I just gave up trying to fix it. It would be fun to try to make a proper fully automated bot, though as you said, there are so many different contexts and possible text prompts itd be difficult to make it truly reliable. I wonder what the best approach would be - some kind of classic AI goal system or newfangled ML? (If I had the time to start over, I’d probably use Mudlet since it uses a proper scripting (lua) instead of something that got hacked together over time. Though it’s a bit GUI-reliant for my tastes)
- pmiller2 6y ago
  Yeah, tt++'s programming model is essentially a finite state machine with a single global scope. If that sounds hard to work with, it is. I think if I were starting over, I'd go with a client that's extensible in a real language, whether that be Lua, Python, Ruby, Scheme, elisp, etc., simply so I could take advantage of modern programming language features.