Best posts made by Ashen-Shugar

@skew said in Quiet Room:

If you're using TinyMUX (which I know you are), there's no way to squelch the connect/disconnect (and the leave/arrive?) messages unless you have @Chime's fork. Which a certain cephalopod has just recently informed me has had a very minor update to handle some SSL something something something.

MUX 2.12 seems to already have arrive/leave handled by blind (on target player or location).

So to add this functionality to connect/disconnect, you need to edit netcommon.cpp in three locations.

One to handle connect/reconnect
One to handle disconnect
One to handle partial disconnect

You look for this section:

        if (  loc != NOTHING
           && !(  Hidden(player)
               && Can_Hide(player)))

And modify it to this:

        if (  loc != NOTHING
           && !(  Hidden(player)
               && Can_Hide(player)) && !(Blind(loc) || Blind(player)))

You should then be good to go.

Ok peeps.

This is my suggestion. We hold classes on how to mush.

This will include passing knowledge of coding for those specific 'classes' and for learning how to socially interact with others in a mush medium. This would include social and RP mushes.

Coding is a no-brainer. We would talk about both softcoding on a mush and hardcoding on a mush. Those of us who are experienced will talk about things to watch out for on advanced systems. For those who are active with Evennia or AresMUSH we could do similar. While I know python and ruby I don't know either codebase well enough to talk about coding for those, so others will have to take over that spot. But then that's why I'm reaching out to you all

Now, I want to specifically touch on the social interaction. This is a very dangerous kettle of fish as each person has their own style and each mush has their own needs.

So my thoughts on social interaction is a study on what not to do over what to do.

Basically pass on all the faux paus and mistakes we've all been through. Things not to do. Like when you went too far in administering a game and chased people off. Or those times you wish you put your foot down harder than you did. Basically have a course on what you learned with 20/20 hindsight so others can learn from our mistakes.

Because I think if we instill into people what not to do. Finding what they can do will be all the more easy and enjoyable for them.

I think having scheduled training sessions on a central calendar where people can show up would also help bring in new people. One of the biggest things for new people is the steep learning curve, so let's combat that.

Thoughts?

Edit:

Because it honestly was such a great idea, I quoted @apos post here:

@ashen-shugar I personally might further divide it up into useful sub topics for social like, "How do you get involved in stories", "How do you handle conflicts you find oocly frustrating", "What are the differences between MU RP and other rp formats", etc. That might keep people's input more focused.

@Seamus said in Client-Side Spacing:

@faraday Maybe it is code ignorance. A looking fear of a security risk.

It can be, but the idea has merit.

What do people think about adding a SPEECH_PREFIX and a SPEECH_SUFFIX attribute on themselves that if met when anyone is issuing a say or pose at your location it will issue the speech_prefix, the message, then the speech_suffix?

There would be no method to identify the player doing it and it wouldn't evaluate functions, only %-substitutions.

This would be a hardcode mod.

Thoughts?

@Lilli

Bit delayed, but hypothetically Rhost should compile cleanly on any unixy system.

There was a bug with latest ubuntu with our openssl identifier that would think openssl was installed when it really was not. Mind you, it doesn't require ssl at all, it just enables it if it detects it. It enabled it erroneously on newer ubuntu systems (14.04+ apparently).

It's been successfully compiled on all flavors of Linux, FreeBSD, OpenBSD, Mac OSX Lion up to Yosemite (not tried the latest, anyone willing to give it a go?), Solaris, AIX, it used to work on HPUX, not tried since, like, the dawn of dinosaurs, and even got it working with CYGWIN on Windows (I still need to shower for that). Think someone got it working on a PS2 and rasberry pi for kicks, but I never saw it running so take with a grain of salt.

I know people on MUS*H (The PennMUSH dev site for those not in the know: gungnir.pennmush.org 4201) or on the Dev Asylum (The RhostMUSH dev site for those not in the know: iweb.localecho.net 4201) offer free hosting, some on local systems, some on raid-capable deduped systems.

They tend to host anything you want, Penn, Mux, LP, Circle, Smaug, Rhost, Diku, etc etc long as it likely won't be a security risk and eat the server while grunting like an alien hybrid. I'd just openly ask around, and you may be surprised on what servers are available for hosting.

As for requirements for Rhost, I've done my best to make sure they're as minimalistic as possible:

You need a ksh/bash/dash for a shell and standard unix tools (grep, awk, etc)
You need a compiler (gcc or clang)
You need libcrypt (which should be standard)
openssl dev packages (optional, skips digest/ssl if not found)
libpcre (optional, it uses it's on internal code if not found)
mysql (optional, ignores it if not enabled)
sqlite (optional, ignores it if not enabled)

And as it can integrate with external processes, binaries, and scripts, likely whatever else you may want to integrate with Rhost.

So, minimal needs, to whatever you want to throw at it I guess.

Good luck

--Ash

@Sunny said in Dune Coda Stuff:

@Ataru

There IS a way to fix it. I don't remember what it is, but it is possible, never fear. Somebody will be able to tell you how to do it, as someone was once able to tell me.

Until then...someone else may have done this before. I feel your pain. ^^

If it's a RhostMUSH, you can use a conf file parameter to reset #1's password.

add to the netrhost.conf file:

newpass_god 777

It resets #1's password to the default 'Nyctasia'.

Once you've @rebooted your system for this, you should naturally remove this entry from your netrhost.conf, or it'll keep repasswording #1

@Thenomain said in Client-Side Spacing:

@Ashen-Shugar

Why split date and time when there is timestamp available?

I'm thinking enactor dbref may also be good, a quick and dirty nospoof.

Also a pony.

Because it was easy to do, and some people may find date superflurous over time.

Also, dbref#'s added, though if the enactor is tagged 'spoofing' then the dbref# will return as #-1.

@Vale said:

I have a rather old Rhost flat file for a MU* I would like to bring up, but I don't have strong server side skills at all. It may be a simple install or possibly trickier, but I'll be happy just to see it working.

Would anyone out there be willing to help me get this running?

Put the flatfile where you know where it is. Let's say for giggles your home directory is:
/home/farble

The flatfile should be called netrhost.db.flat

So the flatfile location will be /home/farble/netrhost.db.flat

Pull the latest Rhost source:

git clone https://github.com/RhostMUSH/trunk Rhost

Compile the code:
cd Rhost/Server
make confsource

This will pull up this menu:

                       RhostMUSH Source Configuration Utility

------------------------------------------------------------------------------
[X]  1. Sideeffects        [X]  2. MUSH/MUX u()/zfun  [X]  3. MUX inc()/dec()
[X]  4. Disabled Comsys    [#]  5. ANSI SUBS (menu)   [X]  6. crypt()/decrypt()
[X]  7. +help hardcoded    [X]  8. MUX @program       [ ]  9. COMMAND flag
[X] 10. ~/_ attributes     [X] 11. Reality Levels     [X] 12. a-z setq support
[X] 13. Enhanced ANSI      [X] 14. Marker Flags       [X] 15. Bang support
[ ] 16. Alternate WHO      [X] 17. Old SETQ/SETR      [X] 18. Secured Sideeffects
[ ] 19. Disable DebugMon   [ ] 20. Disable SIGNALS    [ ] 21. Old Reality Lvls
[ ] 22. Read Mux Passwds   [ ] 23. Low-Mem Compile    [ ] 24. Disable OpenSSL
[X] 25. Pcre System Libs   [X] 26. SHA512 Passwords
--------------------------- Beta/Unsupported Additions -----------------------
[#] B1. MySQL Support      [ ] B2. Door Support(Menu) [ ] B3. 64 Char attribs
[ ] B4. SQLite Support     [X] B5. QDBM DB Support    [#] B6. LBUF Settings (Menu)
------------------------------------------------------------------------------

Keys: [h]elp [i]nfo [s]ave [l]oad [d]elete [c]lear [m]ark [b]rowse [r]un [q]uit
      [x]tra default cores (MUX, TinyMUSH3, Penn, Rhost-Default)
      Or, you may select a numer to toggle on/off

Please Enter selection:

It pulls up a nice menu and just selection various options you want. The default values are nice, but you likely want B3, B6 (drill down and select 8, 16, or 32K lbufs. 64k works, but can have issues as some older routers have a 32K tcp buffer and packets can be lost).

Any other option should be fine to play around with but the rest are usually fine for defaults.

Hit 'r' (run) to run with the options and compile the code.

Once it's compiled, modify your netrhost.conf file to change the port, mud name, master room, and anything else you need to that matches up with your flatfile.

Once you have modified your netrhost.conf file, you have two ways to load the flatfile.

Option 1. (from the game directory)
./Startmush

This will prompt you if you're starting a new game (as it detects no flatfile) and when you say 'Y" it will prompt you for the FULL PATH AND NAME of your flatfile. In the above example this would be /home/farble/netrhost.db.flat

Option 2. (from the game directory)
./db_load data/netrhost.gdbm /home/farble/netrhost.db.flat data/netrhost.db.new
./Startmush

Either option works, but for both instances you need to give it the full path to where you have the flatfile.

It should automatically load your RhostMUSH flatfile regardless of the age it is. Rhost's db format hasn't changed in 25 years. We believe in backward compatibility.

That should work! If you have issues, head to the RhostMUSH dev site and someone there (who's not idle * grin *) will be able to help you.
Rhost devsite: iweb.localecho.net 4201

Good luck!

I use an ssh client to connect to my server to use tinyfugue

@Sparks said in Client-Side Spacing:

I also do think there could be an argument made for functional expansion; if I had the origin command in a register, I could do interesting conditional things like add out-of-band data for the client to process. Like adding a conveniently, consistently parseable string saying 'this is a page from <X>' with a begin/end tag, so that even multi-line pages could be pulled into a specific spawn.

Of course, at that point, you're making this wildly more complicated, but it's still a personal pipe dream... to have a way to snag multi-line outputs for client-side processing. And if we're discussing adding user-specific formatting hooks that have a chance to alter output, making them conditional based on the origin command and enactor makes me happy.

And..... done.

This is optionally available in the latest RhostMUSH 4.0 engine with the @admin (config) parameter posesay_funct enabled (default disabled).

The SPEECH_PREFIX and SPEECH_SUFFIX attributes only work for connected player types, and will not work if the attribute is set NO_COMMAND.

If you trigger the cpu alert (by blowing away the cpu alert) it naturally logs the attempt then sets the attribute NO_COMMAND for safty sake.

So, you got your pipe-dream. Enjoy

One thing you may consider doing is storing the DNS name and/or IP into an attribute and continously concating the data with something like setunion() with whatever IP/dns they connect from again.

Then when you do a search search against that field.

One thing that's hard to identify with alts is frankly those who don't want to be found will be hard to find.

A lot of users who hide who or where they come from will use public proxies.

Things like TOR, hidemyass, or similar sites.

And while it is fairly easy to block people who use these sites, identifying who is using it is a quite a bit more problematic.

So the best you can hope for is just log all the sites they connect to, store it in an attribute like _SITES on the player, and write code to search that variable.

As others have very well stated earlier, doing searches on subnets while a good grenade throw on who may be the same person, is iffy on if it's the same person.

A group of individuals could even be using the exact same ip.

An example would be if a group of mudders are mudding from Microsoft.

All of them logging in. All their IP's will likely be exactly the same, because they're going out through the corporate PROXY DMZ system which NAT's their IP to an outbound IP address that's exactly the same.

Similar issues for a group of people in a single house using the same router, or any number of other things.

So if you ever block IP's, keep in mind while you're fairly confident it's the same person, there's a small possibility others will use that IP address as well, so always balance the cost of doing it against the effect of having them gone

@WTFE said in UX: It's time for The Talk:

@Groth said in UX: It's time for The Talk:

Sidenote: @WTFE strictly speaking and syntaxical sugar aside. Mushcode has the same lamba support as any other string based scripting language as it can pass along arbitrary strings and call eval()

So leaving aside the part that makes lambdas useful (and you haven't addressed closures) it's just like having lambdas!

Lua:

function addxplus3(x)
  local z = x + 3
  return function (y)
    return z + y
  end
end

add5plus3 = addxplus3(5)
print(add5plus3(3))  -- 11
x = 100              -- what happens when we change "x"?
print(add5plus3(3))  -- 11

MUSHcode:

???

From my reading of it, there's no convenient way to do the equivalent in MUSHcode. Doing that code in MUSHcode would be about as painful and as error-prone as doing the equivalent in, say, Rexx or in C. It's doable in both those languages because ANYTHING you can express in one Turing-complete language can be expressed in another modulo hardware limitations, etc. (if you'd like I'll put up the Rexx version), but it's painful, it's error-prone, and thus it's something that's going to be avoided as a result.

"Store this function as a string and call eval()" (roughly how I'd do the Rexx equivalent) is theoretically very similar to the above, but its the very lack of that syntax sugar is why nobody would ever actually use it.

Syntax is nothing. Syntax is everything. Both statements are true.

It's one of the reasons I introduced execscript() to Rhost so that you could execute external scripts, schema, binaries, programs, executeables, or whatever and feed back the result as a native function. To bypass some syntactical hell that's prevalent in mush code. While it's powerful, it does have serious limitations when all you can do is feed it a block of crap and split up the args based on pre-built filters and handlers.

I mean sure, I've added dynamic functions, variables, declarations, redefinitions, empowerment and depowerment localization of variables, syntax, and functions, and a global handler of the same. But boil it down, and it's still mush code and still has the limitations of the interpreted parser.

The beauty of execscript() is it lets you step out of the box and do... anything else.

I'm currently working on a STEP-like API so that you could actually do curl/web calls right from the shell to execute code within the mush to both send and receive results.

Goal is to be able to do low-level cross-platform/cross-software plugins that work right into the mush.

It's always possible to work around limitations, it just sometimes takes a hell of a lot of scotch to do it.

@Apocalycious said in Reality Levels and WOD Realms:

@Hexagon
I logged in to check, and HM has rlevels:

Level: real         Value: 0x00000001   Desc: desc-interpreter
Level: shadow       Value: 0x00000002   Desc: shadow-desc
Level: invis        Value: 0x00000004   Desc: desc-interpreter
Level: twilight     Value: 0x00000008   Desc: desc-interpreter
Level: all          Value: 0x0000000f   Desc: desc-interpreter

The Hedge was not actually an rlevel, just a different grid. The Shadow one was useful because the rooms were all the same in the Shadow, but it allowed for different descs in shadow/real. Extensive use was made of it, and most of the main grid rooms and many builds had shadow-descs set.

If I recall correctly, early on the Twilight one did make people invisible except to other people in Twilight. I never made much use of it (and it didn't get used very much in general), so I don't remember if those policies changed with time, or what they changed to. I don't remember the invis one getting used at all.

While Cajun Nights isn't active at all anymore, it is still up and will give a very good idea of how things work with realities. It uses them to extreme conclusions for massive amounts of manipulations.

Reality levels: (30 configured)
------------------------------------------------------------------------------
    Level: Real         Value: 0x00000001   Desc: _Desc
    Level: Umbra        Value: 0x00000002   Desc: _UMBRADESC
    Level: OUTTIME      Value: 0x00000004   Desc: _Desc
    Level: AWARE1       Value: 0x00000008   Desc: _AWAREDESC
    Level: AWARE3       Value: 0x00000010   Desc: _AWAREDESC
    Level: AWARE5       Value: 0x00000020   Desc: _AWAREDESC
    Level: AWARE7       Value: 0x00000040   Desc: _AWAREDESC
    Level: AWARE9       Value: 0x00000080   Desc: _AWAREDESC
    Level: MIND1        Value: 0x00000100   Desc: _AUSPEXDESC
    Level: MIND2        Value: 0x00000200   Desc: _AUSPEXDESC
    Level: MIND3        Value: 0x00000400   Desc: _AUSPEXDESC
    Level: MIND4        Value: 0x00000800   Desc: _AUSPEXDESC
    Level: MIND5        Value: 0x00001000   Desc: _AUSPEXDESC
    Level: MIND6        Value: 0x00002000   Desc: _AUSPEXDESC
    Level: SPIRIT1      Value: 0x00004000   Desc: _SPIRITDESC
    Level: SPIRIT2      Value: 0x00008000   Desc: _SPIRITDESC
    Level: SPIRIT3      Value: 0x00010000   Desc: _SPIRITDESC
    Level: SPIRIT4      Value: 0x00020000   Desc: _SPIRITDESC
    Level: SPIRIT5      Value: 0x00040000   Desc: _SPIRITDESC
    Level: HIGHUMBR     Value: 0x00080000   Desc: _CONCEPTDESC
    Level: WRAITH       Value: 0x00100000   Desc: _WRAITHDESC
    Level: TELEPATH     Value: 0x00200000   Desc: _TELEPATHDESC
    Level: SYNERGY      Value: 0x00400000   Desc: SYNERGYDESC
    Level: HEARING      Value: 0x00800000   Desc: _MURMUR
    Level: OBF1         Value: 0x01000000   Desc: _AUSPEXDESC
    Level: OBF2         Value: 0x02000000   Desc: _AUSPEXDESC
    Level: OBF3         Value: 0x04000000   Desc: _AUSPEXDESC
    Level: OBF4         Value: 0x08000000   Desc: _AUSPEXDESC
    Level: OBF5         Value: 0x10000000   Desc: _AUSPEXDESC
    Level: ALL          Value: 0x1fffffff   Desc: _DESC

    Enhancement: @lock/user works as a Reality Lock (type 1).
------------------------------------------------------------------------------

As for how to set things up 'properly' with Reality Levels, that's an open question that requires an open answer. There really is no 'right' way to do it or that many 'wrong' ways.

In essence, realities allows you to share the same physical space by applying virtual layers over the top of it.

Another good example is layered GIF's when you work with photoshop or gimp. You have one layer which is the background. The next layer is the plants and trees, the layer after that the weather like leaves that blow around, the next layer maybe fog on the ground, then the next layer animals flying or walking and the next the people who walk around.

6 complete layers, each one absolutely separate from each other, but with the right 'permissions' allowing each layer to interact with any of the other layers however you want. That's a bit like reality levels. You can modify the @rxlevel and @txlevel on the fly (there's sideeffect functions as well) so someone can switch realities by somthing simple like walking through an exit, or issuing a $command or any number of other things. And with locks (if available) you can dynamically define realities based on conditionals on top of it.

Lots of flexibility.

@Groth said in UX: It's time for The Talk:

@Ashen-Shugar said in UX: It's time for The Talk:

It will take thinking outside the box and finding a way to do external tags to and from the mush to send async data to and from a mush to an outside application.

Can this be done? Absolutely. A lot of applications do this already, and they're nothing more than an extensive TCP/IP engine, so why can't mushes?

The answer. Of course they can. It just takes coding to wrap the feature set around this. Then once the feature set is done, hand it off for others to interface to it who have a bigger understanding of GUI, or html tools, or what have you.

It's really easy to set things up to send data to and from the mush to an outside application. However if we're going to change the mush protocol and require new clients to be written, why do we even stay with telnet? If we switched from telnet to http/json we could have smart clients who are given information as data rather then raw text. It would know what represents the exits, what represents the players, what represents a pose and what's a command echo etc.

That's exactly what I'm going to do. I'm making an API that hits a separate port that allows HTTP GET and POST responses to PULL and PUSH data into and out of the mush.

Syntax via curl as a rough example (and yes, this is currently a working example on my dev site as I work with this):

curl -X POST --user "#123:MyPassword" -H "Exec: &FOO #345=bar;@emit whee;page wizard=test" http://mymush.com:12345

In the example, #123 is the dbref# you want to interface with (which can be room, exit, player, or thing, any valid dbref#), the MyPassword is the SHA2 hashed password for the API handler for that object (different from @password). It also defaults to localhost only unless you specify the API IP's (wildcarded) allowed for that dbref#, and it requires an API @power to work. The port 12345 is a separate port from the main mush port, and tags the connection API.

Using -X GET will work with functions only but should allow you to fetch pretty much any data within the game. Return values will be in a header -H "Return: <value>"

But that's the general design flow as it stands right now. Still a lot of tweaking and work, but the general under-hood work is already done. It uses headers only (no data), and uses standard HTML send/responses so anything that encapsulates url should work with it. So a fully working API engine.

@Hexagon said in What is your preferred method of function creation?:

I have seen some objects that run their own @startup that scans and registers functions. I assume it should be possible to create an object that scans all objects in a location, such as an auxiliary room, and registers the functions.

I would be interested to hear how others have handled it, and any lessons learned along the way. It seems like a measure of control versus duplicated work.

I would say it depends on the codebase.

Penn's a bit harder for organization of where objects, attributes, functions, etc are.

MUX and Rhost are a bit easier to identify where they are with @function/list.

For my own use I tend to use an object with a single @startup that parses attributes based on prefix if it's /priv, /pres, /local, etc and sets up the user function table on startup.

Rhost also has a way for normal users to define functions on the fly themselves that are sandboxed to them and their own belongings via @lfunction.

So it depends greatly on the codebase that is being used.

@_Haven_ said in Guest Names:

@Thenomain Is it? That's great! Thanks for the info. It really put my mind at ease about switching!

As a general follow up on things that 'break' when switching from MUX2 to Rhost:

1. @mail is not transferrable. So that is lost.
2. comsystem is not transferable. So that has to be recreated.
3. Some features are 'different' and require some mucking around.. these are:

• columns(). Columns() in MUX is not compatible with columns() in Rhost, as @Thenomain mentioned. However, part of the db converter script renames 'columns()' to 'column()' and part of the softfunctions.minmax (@function wrapper tool) is a MUX compatible column() function. It also contains various other MUX compatible functions that ease transition. This file is located in the ~/Rhost/Mushcode directory when you set up your Rhost.

• Mail out of the box is not MUX compatible. However, there are mail wrappers that will work (again under Mushcode) that you can install that provides wrappers to the hardcoded mail system. Essentially, like Penn and MUX, Rhost has it's own hardcoded mail system which while very powerful is somewhat different in syntax. There are mail wrappers that mimic penn's mail and mux's mail available.

• MUX 2.7 and later have a built in UTF8 hardline encoding. Whenever you extensively use ansi or unicode (utf8), and store the RAW format in attributes, that will have to be converted. Luckily, Kage made a utf8clean program that converts RAW ansi and utf8 to Rhost's meta-characters for conversion.

• Sideeffects. Rhost has all the sideeffects that MUX has, and honestly all the ones Penn has as well. The difference is any object/room/etc that DIRECTLY uses a sideeffect must be set with the flag SIDEFX. This is a safty reason, so while annoying on a conversion is handy to have.

• LBUF size by default in Rhost is 4K. At compiletime you can increase this up to 64K. I would suggest 8K if you want to match what MUX had, or 16K if you want to get a bit greedy. 32K is fine as well, but 64K can potentially cause issues on older network routers between you and the people connecting with it cutting off after 32K for TCP packet sizes. It's goofy, but I tend to just say don't go over 32K. You ABSOLUTELY MUST have at least 8K lbufs compiled BEFORE loading in the flatfile or you''ll lose data loading it in.

• The comsystem in Rhost is softcode. Very fast, very powerful, and compatible with MUX and Penn. This is also in the Mushcode directory.

• MUX has wizard and royalty for bits. Rhost has immortal, royalty (wizard), councilor, architect, and guildmaster. Each bitlevel grants varying levels of power. Nothing should be owned by #1 other than #1 (and garbage). There's debate when it's good to use Immortal or Wizard for global code and/or head builders/coders/etc. In essence, immortal bit gives someone effectively #1 access to your game, so use it responsibly.

• Zones are different in MUX than Rhost. If you use zones, they will not convert. The reason why is MUX's zones, like TinyMUSH's zones, are like psudo-zone where it has a one to one relationship. Rhost's zones are a hybrid of Penn and MUX and in addition allows you to have multiple zones belong to a single thing.

• Reality Levels -- Fully compatible. Whee.

• Variable exits -- They should convert but you may run into issues. Variable exits are done a bit differently in Rhost so if you use them you may want to mark down where so you can double check them on conversion.

• RAW ANSI in names of things. Rhost does not support RAW ansi of names. While it'll convert fine and Rhost will seem to work fine with it, you can tell pretty early on that Rhost doesnt' like it. It breaks formatting and other things, but doesn't 'damage' the mush with it done. The correct solution to this is re-name the ansified named items with a normal name, then just use extansi to colorize the name of the item (help @extansi)

There's likely other small issues with command or functions you may run across here or there, but honestly most everything else should work 'out of the box' between codebases.

Hope that helps.

Further, some systems have very active developers of softcode and that's also an important draw. If you can talk to @Cobaltasaurus or @Thenomain or @Ashen-Shugar or you (or more, I can't list all of you coders, but I'm glad you're here) about the code they wrote instead of using decade old castoffs or three week old undocumented experiments, then that's also really important.

As @Griatch can attest to, the devs of RhostMUSH are pretty open on interoperability. In so far as even opening a dialog with @Griatch once we get around to finally writing our Python API so that Evennia and Rhost can talk to each other on some level. Cross-compatible python modules for the win!

One big thing we do have with Rhost is we have a built in execscript. This is a built in function that allows you to interactively execute external script/binaries/other as a local built-in function and be able to scrape the results off it. It allows fun things like running things through an external spell program, calling the mush patch process in-game so you could compile your game inside your game, allowing you to scrape web pages, do external sql calls, populate external files, basically absolutely anything and everything in a sandboxed location. A lot of flexibility here.

And once the Python API is written (We plan for that in the Alpha of Rhost 4.0 hopefully in 2017 Q1), we will have the framework for other API's, maybe perl, ruby, and so forth. Our goal is to move the main mush engine into it's own API extraction layer so that you have all the power of the mush internal language and all the external tools of calling API tools. So hopefully a merger of two worlds.

Some stuff may be vaporware and far too far to reach, but the Python API is already down on paper, just have to get the guy who knows how to add it to, well, find time to add it