Posts made by Ashen-Shugar

@TwoGunBob said in Christmas...:

She also got a Macross VT-01 Ostrich fighter when I was 13 that I resold awhile back for $1500 when I needed a car quickly. She was happy a toy she got me for Christmas bailed me out of a sticky financial moment.

This brings tears to my eyes.

I had the complete GoDaiKin collection (all the main robots as well as all the side-robots/vehicles/etc) before I went off to college. All mint condition, boxed, nicely arranged, and hidden in my closet.

I came back from college to find nearly every toy, broken, outside, sitting in a sandbox.
With my 8-12 year old nephews still playing with some.

My brother's comment was 'well, they're just toys, get over it'.

I haven't gotten over it. I never will. And yes, the majority of my family are assholes

@Thenomain said in What is out there? Hard and soft codebases of choice.:

We could call Ares something different. How about ... hmm ... a MULORG? MERINGUE? MIP? MUM, Multi-User Mush?

MULLED.

Multi User Low Level Environment Director

Then his plugins can be names of alcohol. Wine, Beer, Scotch, Whisky....

@Hexagon said in What is out there? Hard and soft codebases of choice.:

@Ashen-Shugar said in What is out there? Hard and soft codebases of choice.:

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.

This sounds amazing. How fluid is it between in and out of game? Would it be possible to have it interact with a chatbot in a meaningful way, then? That was something I was always interested in. I mean, you can sort of do it already by having a bot connect to a bit flagged ROBOT I guess.

It's limited in that it doesn't allow interactive integration. Think of it like an API call.

You run an external app, it does its thing, and returns its results.

It's not able to wait for input or anything like that.

We do, however have interactive @doors that do allow you to do full interactive mode. There's still some limitations with it as it's a line mode TCP connection and not a character mode, so ncurses or similar is not possible.

But it does allow fun features like being able to connect from inside one mush to another, or playing unix empire or other line based TCP systems.

@VulgarKitten said in Christmas...:

... because tis the season! What's the best geeky/game-related present you've ever received?

The Fallout Pipboy, Deluxe Bluetooth Edition.

Henry Heimlick.

It just chokes you up...

@Seamus said in MUX: Openly writeable attribute?:

@desc here=[ifelse(hasattr(%!,temp-desc),[u(temp-desc)],[u(perm-desc)])]

&cmd`desc here=$+desc *:@pemit %#=You have set the temporary description.;&Temp-desc %L=%0

&cmddescclear here=$+desc/clear:@pemit %#=You have cleared the temp desc.;&temp-desc %L

Now this is a very basic code. But feel free.

I'd put in protection since not every codebase sets new attributes NO_COMMAND.

So like:

@desc here=[default(me/temp-desc,v(perm-desc))]
&CMD_DESC here=$+desc*:@pemit %#=You have [ifelse(gt(strlen(%0),0),set description '%0',cleared the description)];&TEMP-DESC me=%0;@set me/temp-desc=no_command

@Lithium said in What is out there? Hard and soft codebases of choice.:

So I agree with what others before me have said when it comes to ease of use and familiarity of control schemes.

^^ - this.

This is the primary reason we want to add stock ontop of Rhost where possible for extensions like our API interfaces and so forth.

It does cause us to hit ceilings and limitations that other codebases will be able to get around having grown from scratch in other directions with multi-processing in mind.

Things we likely will never be able to achieve short of a complete rewrite:

• Multi-Threaded parser/queue
• Multi-Threaded db handler
• Full on DB log transactions and roll back capability
• Multiple mush processes accessing the same database, allowing mutiple mushes across several servers to access the same database (like WoW, Runescape, etc).
• Weighted processing of processes with built in wait/pause/continue based on conditionals on processing times of the threaded processes
• Many other things.

All of the above are, while not easy, well in the scope of doable. Anyone who's done advanced programming knows how possible it is.

The problem you run into is for pretty much any major mud engine you're on a single threaded engine. The db is non-locking, it's under a single core, under a single thread, and the interpreted language is a GIGO (garbage in/garbage out) destructive parser that does not lead well to advanced features like in-game debugging, pausing, rollback/rollforward, and various other things I would love to be able to do with a mud engine, but without a complete rewrite can not happen.

We have been able to make some crude approximations of the points above in Rhost. We have allowed some threading by allowing a shared slice of of processing with @doors that work interactively (like BBS Doors), we have allowed a way to have some half-baked debugging in our TRACE output like grepping, label/break points, and such things to make debugging MUCH easier, we allowed in-game alignment for code evaluation including in-game pretty printing, we allowed being able to load in all db's (minus the main mush db) in-game, we even have methods to call external applications in-game, allowing fun things like patching, compiling and rebuilding the mush from inside the mush. So we have worked around a lot of the limitations, but they still remain limitations.

Then you run into the big issue, if you rewrite the engine from the bottom up to allow a lot of that multi-processing capabilities, you lose the backward compatibility that a lot of users wish to happen.

It's a walk on the tightrope. How much do you alter, and what can you alter, while still keeping compatibility the same.

I've chosen to do the 100% backward compatible model with Rhost. So people who used it back in the 90's who use it today see things work just the same as it did back then, just with a lot more added fun happy toys. That's my goal with this. To expand on a known quantity and bring it to the absolute ceiling of capability.

What happens when we finally hit the limit? Well, I guess then we do something else, but like any good mechanic, I can say we still have quite a bit to squeeze out of this baby.

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

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

@faraday

Yup, that's how it works. But you can log in via alias. connect Smithy password

If you want server consistency, you're going to have to code a lpmatch() that honors it. Good luck. Please share.

Something most people don't realize either is you can connect by your dbref#

So from the connect screen doing something like 'co #69 pass' would work.

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

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

@skew said in Reality Levels and WOD Realms:

It would not separate out players, but simply descs? Or I could be totally misunderstanding.

Realities Levels (version 1) which is on MUX have multiple levels (31 total) where they are literally a different 'reality' from the previous. Descs are just one of the things affected.

Rhost has a version 2 that also includes override locks meaning you can specify overrides of realities based on a lock, so you could have for example spy glasses that if you wore you could see inside a reality without actually being in that reality.

Fun stuff like that.

In essence reality levels give you access into all interactions to and from the reality. There's two points to it.

An RX level and a TX level. Think networking. RX is what is received. TX is what is transmitted.

So if you belonged at RX to a reality, say, 'Umbra' and 'Real', and your TX was only 'Real'. This means that only those who are in 'Real' can see you or anything you say or do. However, you can see anything from both Real and Umbra.

Yes, this means you can set it up so you can transmit on a reality you don't even belong to. Fun stuff.

This effects everything. Descs, movement, connect/disconnect as well as any type of messaging, looks, contents, exits, movement, $commands, listens, and so forth.
This will even impact master room and/or zone code and areas that have specific realities.

It literally tosses you into a pocket dimension for all intents and purposes.

Hope that helps.

@Catsmeow said in The Cat Thread:

Please everyone post more cat pics.

Thanks

Pyewacket, our Norwegian Forest Cat.

Visiting the Breeder

Picking up from Breeder - 12 Weeks

Gluttony for Attention - 16 Weeks

I'm not always adoreable, but when I am... - 17 Weeks

And finally at 6 months... and 13 lbs...

@skew

Good looks good.

As a FYI to toss out there, for those who use PennMUSH or TinyMUSH3, it will need adaptation as the @hook code for Penn and TM3 uses the TM3 standard @hook functionality while MUX uses the Rhost @hook functionality. The syntax for @hook is different for those platforms.

So in that regard the code should work on Rhost likely without changes as well.

@Lithium said in New Start Databases:

[snip]
I wouldn't mind seeing something like it for Rhost though, and would welcome it too since it might give me enough code to look at that I might be able to teach myself the differences. I basically am self taught learning through osmosis and help files on what the functions do.
[snip]

Rhost has a minimal db that already has SGP. But as was stated elsewhere in this thread, it is a dated package. I wouldn't mind getting Theno's code, or MuxCore, or Faraday's ported to Rhost, and honestly most things should work ported to Rhost, the only difference being when you use a codebase's unique feature sets or oddities (like previously mentioned with Faraday's code on missmatches that work on Penn but not on non-penn), or align() via penn, or maybe the structure/setx stuff in TM3, and so forth.

And those can be ported, but the more unique code or features used the more effort in conversion.

My ultimate goal in all this is to see into making a general code that can be mostly working across codebases that helps people build ontop of it. So something that people are used to that they can then customize. Obviously it has to be generic, but a core set I think would get more attraction to mushing.

It's kinda daunting when you start up your mush and only see room #0, the Wizard #1, and a master room and that's.... it.

Then you think 'omg, I have so much to do!' and about 50% of the games flounder on that alone. I'm hoping if everyone comes together with a core package set, we can reduce that 50% by a significant amount.

@Thenomain said in New Start Databases:

@ixokai said in New Start Databases:

@Thenomain said in New Start Databases:

As much as I bitch about code, including mine, I have really only one thing I want my way: Put spaces after commas.

No, you monster.

Surethatsfine,Iknowhowlegiblethingsarewithoutthem.Isuspectthatintimeeveryonewillstarttounderstandtheusefulnessofspacesfortheoutstandingsimplicityofbeingabletoparsethekindofcodethatiswrittenoutthere.Inthemeantimethecalmjustificationofbeingrightwillwashovermelikeawarmbreezeonacoolday.

Function: parenmatch([<object>/]<attribute> [,<type>, [<key>], [<flags>]])
...
[snip]
...
  The following flags exist:
    s - put spaces after every , and ; character and before and after =
    p - put spaces before ) and after (
    b - put spaces before ] and after [
    B - put spaces before } and after {
...
[snip]
...

Some people listen to you Theno

@Cobaltasaurus said in TinyMUX: How to set default player attributes?:

Create a character parent, and then in the server set the player_parent to that dbref. So all players are automatically parented to it.

That'd honestly be the best solution, but barring that like you mentioned something in the starting room when they do ACCEPT or maybe the master room when a player connects check the existence of the attribute, if it doesn't exist, set it.

Times like this makes me kinda wish MUX had some more features from (shudder) TinyMUSH3 or RhostMUSH.

Basically a global_clone_<type> so when a new type of that type is created, all attributes are copied from the clone to the target. I think Penn has work arounds with their action lists and other methods, but with MUX you're more limited by options.

So off the top of my head with MUX you're limited to:

1. Set the attribute via global master room code.
2. Set the attribute based on the player starting room
3. Set the attribute via a $command or exit movement or some other method of trigger
4. Set up a parent like mentioned above via @Cobaltasaurus
5. @hook on @pcreate and enforce pcreating new players (ugly and not suggested)

And with MUX2 (the latest) that... would be about it.

@Thenomain said in New Start Databases:

I've been begged to put the CoD (WoD) system in a startup db for a while. At the speed in which this game line changes and I improve it, tho, I don't think it's quite possible without more dedication than I have the time for. I'm actually quite a bit saddened for it.

TinyMUSH has Ambryl's latest softcode-starter in it.
TinyMUX has the dated yet still functional SMP (SPM? SFM? I can't remember).
Penn apparently has a Faraday bundle (so good).
I suppose it'd only be fitting if Rhost had an option too.

Theno,

I'd be very curious how much your CoD package would work out of the box on Rhost.

I played a bit with getting F3 working on Rhost but there's some discrepencies in how the parser works that'll be annoying.

• Non-penn parsers require extra escaping of \ characters.
• Penn's parser does not require ending parenthesis, bracets, and brackets, no matter how many levels deep you are. Which... I never figured why, but makes for lazy code that is non-cross portable
• Penn's parser doesn't handle a large number of ('s, {'s or ['s in raw string format to any command, so anyone who uses a lot of them for something as simple as ascii art will be SOL.
• ansi is handled differently
• search/lsearch is handled differently
• align() vs printf() vs columns()

I'd say Rhost is the most compatible with MUX without being a MUX. It's also the most compatible with Penn without being a Penn. It has a ton of unique features that neither have as well. So it's a unique choice, but if you use the unique codepoints of each codebase, which make sense if you plan to code for those platforms, it starts to remove the ease of porting that code to another system.

Faraday, I do plan to work again on getting your code ported to Rhost, but one of the things I need to fix is the ending parenthesis, braces, and bracket issue. The other is convert all the lsearch()'s to search() and any use of align() to do printf()

Those are the big telling points. After that things will start to mesh a bit.

Theno, I've not looked at your package so I don't know how easy (hard?) it will be to port, but I think much easier as frankly MUX doesn't have the wider functionality that Penn does, nor the wider differences Penn and Rhost have to each other.

Would be a curious project to take on.

For those who want a place to play around with Rhost features, I have a game set up that anyone who connects will be automatically set wizard.

So you can use it to test packages, play with code, etc.

Some things (like @shutdown, @reboot, etc) were locked off, but pretty much everything you'd expect a wizard to have access to will be accessable.

Keep in mind help in Rhost follows the old mud standard where 'help' and 'wizhelp' are separate commands.

If you want to play, site is rhostmush.com 1066.

If anyone manages to crash and/or bring the place down, just let me know and I'll restart it up, no worries.

Something I've been considering more and more and think may be helpful is for those people who want to start up new mushes to have base-code already in a mush db.

What would be nice is getting together, as a group, and get a standard start db for MUX, Penn, and Rhost so regardless of the starting mush engine someone decides on, the base core of utilities and functions that someone would expect would be available.

This would, of course, require some planning and cross-porting various softcode between the various engines (where possible).

It this just shooting at stars? Does anyone see any use for this?

It also would be requiring consistently keeping code updated whenever updates or patches were done to the softcode packages.

Just something snoogling in the back of my mind.

@mushered said in Tracking Alts on Dynamic IPs:

I meant it like 'mushered' as in mushered out. The question was with regards to cheating. On our game, you are not allowed to share items, there are credit restrictions, in game money and other things. There is also the issue of people being turds as many pointed out. After years of mushered-ing and staffing, you would be surprised the strange things you catch people doing. Being able to link ip addresses to charbits has been an thing as long as I can remember. Of course, I don't think dynamic stuff was even around when I started.

@Ashen-Shugar
You mention subnets, and that was sort along the lines of what I had been thinking initially. With some softcode monkeying, I imagine we could lock down certain ranges with a glob pattern, for example?

All the years of mudding, not much surprises me anymore of what people are capable of

But yes, you can lock down ranges with glob patterns or with subnets.

Stuff like 192.168.0.0 255.255.0.0 locks down any site starting with 192.168.

Some newer codebases also allow globbing of dns sites which is nice, though some people have obfuscated DNS's. I've seen people connect with a site of '.' for example. Yes. A period