Codebase Pot Pie - Or what I like or wish I could have
-
Ok.
Theno suggested I start a new thread to talk about this. I think it may open some eyes of people and maybe give more options to people who want to start a mush on what direction and options they have.
Bring up your favorite codebase and what features it has that you just can't live without, and why it doesn't work in the other codebases.
I'm hoping that people will speak up and maybe offer alternatives of 'but wait! we do have that and it's called X!' or other solutions. And if not, maybe the devs will get a hit that it may be a nifty thing to add.
For myself, I'm obviously bias to Rhost. I appreciate the multi-tier bitlevels and varying methods of control in-game to basically reconfigure or redefine everything in-game without having to recompile.
So what about everyone else? The more what is and is not in codebases is talked about, the more people will have an understanding
-
I wish TinyMUX had regedit, like Penn and Rhost have.
This is pretty much the only thing that is solidly on my wish-list.
-
I find myself constantly using PennMUSH's attribute trees and user-defined registers (IE: I could make and call %q<STRENGTH>). It makes coding so much easier to look at and organize, plus it expands the amount of registers you can use in general.
-
@Bobotron said in Codebase Pot Pie - Or what I like or wish I could have:
I find myself constantly using PennMUSH's attribute trees and user-defined registers (IE: I could make and call %q<STRENGTH>). It makes coding so much easier to look at and organize, plus it expands the amount of registers you can use in general.
Rhost has a diluted method of attribute trees (like examine, lattr, and set follow attrib trees), and a fairly advanced prefix handler for permission for attributes (including dynamic evaluation). Rhost also has named registers via setq/setr.
The Tree Stuff:
> @create TreeObj Treeobj has arrived. (Non-Listening) Treeobj created as object #17600 > &`THIS`IS`A`TREE treeobj=Bob Set - Treeobj/THIS`IS`A`TREE > ex/tree treeobj Treeobj(#17600) Type: THING Flags: Owner: Ashen-Shugar Key: *UNLOCKED* Gold Pieces: 1 RxLevel: real TxLevel: real ModifiedStamp: Tue Jan 3 21:45:42 2017 CreatedStamp: Tue Jan 3 21:43:07 2017 THIS: @@ - Tree Trunk No exits. > ex/tree treeobj/this`* THIS`IS: @@ - Tree Trunk > ex/tree treeobj/this`*`* THIS`IS`A: @@ - Tree Trunk > ex/tree treeobj/this`*`*`* THIS`IS`A`TREE: Bob > ex treeobj/this`is* THIS`IS: @@ - Tree Trunk THIS`IS`A: @@ - Tree Trunk THIS`IS`A`TREE: Bob > think lattr(treeobj/this`*,,,,,1) THIS`IS > think lattr(treeobj/this`*) THIS`IS THIS`IS`A THIS`IS`A`TREE > @aflags/add this`=5 5 Entry added [1 of 100 used]. > @aflags/list Attribute Prefix Set See ------------------------------------------------------------------------------ THIS` Wiz Wiz ----------------------------[ 1/ 100 max]------------------------------- Note: Immortals are treated as god with regards to seeing attributes.
And the setq stuff:
> wizhelp penn_setq PENN_SETQ Config parameter: penn_setq <yes/no>. Default: no Enables setq/setr compatibility with PennMUSH. This effectively allows the use of: setq(label,blah) in addition to setq(1-9/a-z,blah) setr(label,blah) in addition to setr(1-9/a-z,blah) This effectively mimic's the Rhost built in setq(+,blah,label) option. This will still allow the setq/setq with the + and ! options to work as expected. > @admin penn_setq=1 Set. > think [setq(Narffle The Quaffle,Zot!)] -- %q<Narffle the Quaffle> -- Zot!
Sadly, MUX has support for neither, but they do have a way to do prefix locking based on a limited access for attributes.
-
I don't use attribute trees.
What I mean to say is that I use them extensively, but I don't see much of a point of 'ex tree/*' not showing them. Attribute trees may keep my screen from scrolling, but I've also gotten used to using 'think lattr( tree )' first, because I am not insane.
No matter how many times fans of attribute trees explain it to me, I don't see anything I can't and don't already do on my own.
... with one exception.
I wish I could 'lattr( %0/str* )' and not grab 'str*.*' matches. That's it. I end up doing an ugly double-search, but it works: setdiff( lattr( %0/str* ), lattr( %0/str*.* ))
edit: Maybe I want more regex options in my searches. rlattr( %0/str[^\.]* )
I do miss the ability to setq( long name, foo ), but I also think that we should just drop the 'q' part of the substitution in recalling it. %<long name>.
-
@Ashen-Shugar
Yeah, I knew Rhost has both of those. But you asked for things I couldn't live without, and that's the rough gist of it. -
@Thenomain said in Codebase Pot Pie - Or what I like or wish I could have:
edit: Maybe I want more regex options in my searches. rlattr( %0/str[^\.]* )
Penn and Rhost both offer regexp pattern matching to their lattr functions.
Penn via reglattr() and Rhost through extended options to lattr().
Penn: reglattr(me/str[^.]+) Rhost: lattr(me/str[^.]+,,,,1)
-
@Thenomain said in Codebase Pot Pie - Or what I like or wish I could have:
No matter how many times fans of attribute trees explain it to me, I don't see anything I can't and don't already do on my own.
The only time I used attr trees was in +combat to store the individual combat attributes for each participant. You'd have things like:
stat_faraday`ammo: 10 stat_faraday`recoil: 2
When you had several dozen combatants, it was handy to be able to examine the combat instance object and see the combatants and other sundry combat attributes without having to get spammed by everybody's combat state. That's the only time I've found them useful.
-
@faraday said in Codebase Pot Pie - Or what I like or wish I could have:
@Thenomain said in Codebase Pot Pie - Or what I like or wish I could have:
No matter how many times fans of attribute trees explain it to me, I don't see anything I can't and don't already do on my own.
The only time I used attr trees was in +combat to store the individual combat attributes for each participant. You'd have things like:
stat_faraday`ammo: 10 stat_faraday`recoil: 2
When you had several dozen combatants, it was handy to be able to examine the combat instance object and see the combatants and other sundry combat attributes without having to get spammed by everybody's combat state. That's the only time I've found them useful.
For organization I've gotten hooked on @cluster.
You could set unique attributes across multiple objects, and just cluster_u() any object in the cluster and fetch the matching attribute regardless of what object it was on.
And of course individually examine the objects for those attribs. So in your example.
> @create AmmoObject > @create SkillObject > @create WeaponObject > ... etc > @cluster/new AmmoObject > @cluster/add SkillObject=AmmoObject > @cluster/add WeaponObject=AmmoObject > ... etc @@ These would all return the same thing. > think cluster_u(AmmoObject/weapon`ak47,foo,morefoo) > think cluster_u(SkillObject/weapon`ak47,foo,morefoo) > think cluster_u(WeaponObject/weapon`ak47,foo,morefoo) > ... etc @@ Output of what a cluster will show on a list > @cluster/list #2820 Showing cluster statistics for cluster with member #2820. 20 total members: #3683 #3672 #3667 #2820 #13789 #17715 #17714 #17713 #17712 #17711 #17710 #17709 #17708 #17707 #17706 #17705 #17704 #17703 #17702 #17701 10731 total attributes [Highest: 746, Lowest: 43, Average: 536]. Threshold set to: 500 Threshold Action: @eval [pemit(#1234,boo!)] Action retrigger limit: 10s Threshold Action Function: [cluster_add(me,setr(0,create(cluster_foo,10)))][tel(%q0,#3667)] Action Function retrigger limit: 1s Note: The threshold function has priority over normal action.
Essentially @cluster in Rhost allows you to have 2 or more objects share the same virtual object, up to somewhere ridiculous like 800 objects in a cluster (actually it will keep adding dbref#'s to the cluster up to LBUF_SIZE - 20, so around 600-800 on a 4K lbuf, to around 4500-5500 on a 32K lbuf). Allows for some fun stuff.
For data warehousing you can also just set attributes based on a cluster and it does a weighted set on which object in the cluster receives the new attribute. If it's an attribute name already in the cluster it of course resets it on that specific object in the cluster.
So fun stuff.
-
Yes, but you can do the same without any special code. &attribute.strength: 3, &init.faraday.roll: 2. This isn't a tree, it's a structure convention. The Mushes can't really store in structures, really, which is why I don't get the Tree thing. I can think of some coding practices that would benefit from it, but Mux got rid of push and pop, so I don't think we're really using the binary tree method in softcode, are we?
This is the grumpy coder in me, and this is a great about what you can't live without, not what Theno doesn't get.
I can't live without regular expressions, unlimited data space, and unhindered and uncomplex search tools. Essentially, I can't live without databases.
-
Figure I'll keep this in this thread as it talks about 'Codebase Pot Pie' just as well as adding a new thread.
First, Rhost 4.0 supports full unicode. Have fun those who are on Rhost 4.0.
Second, I'm working on a somewhat passible STEP API into the mush.
Essentially, using curl, you will be able to submit GET and POST responses to the mush to push and pull entries to and from the mush queue and return them to the outside application.
You should be able to use this in junction with execscript() and interactively as it pushes and pulls right from the queue itself.
The goal for this is to allow outside applications full reign into the mush engine to pass any data async into it.
It obviously won't be the fastest thing in the world as, hey, it's an API engine, but it should allow unlimited flexibility into the mush.
The reason of bringing it up here, other than the obvious of giving people a heads up what may be coming down the line with Rhost, is ideas and interfaces you would like to see on the API as it's being built. It's in the design stages right now (I have a working PUSH/PULL engine, still have to build the parser around it).
So, anyone interested to dive on the band wagon, feel free. All constructive ideas are welcome.
An example of the interface will be:
curl --user "#dbref:password" -H "Exec: commands-go-here" -H "Parse: no/yes/strip" http://mymush.is.here:API-PORT
The 'password' will be generated per-dbref# (non-player allowed!) in a SHA2 hash.
-
@Ashen-Shugar said in [Codebase Pot Pie - Or what I like or wish I could have](/post
curl --user "#dbref:password" -H "Exec: commands-go-here" -H "Parse: no/yes/strip" http://mymush.is.here:API-PORT
Rhost's RESTapi is effectively completed and live.
It uses a header-driven API engine to push (POST) and pull (GET) requests from the API port. Everything is documented in-game.
It uses multi-level authentication and has varying levels of safeguards to avoid any DoS/DDoS attacks as well as methodologies from in-game attacks. You know me and my paranoia
The interface is nearly what I said above, but it is this instead:
For POST action:
curl -X POST --user "#dbref:password" -H "Exec: commands-go-here" -H "Time: seconds-for-queue-to-run" --head http://mymush.is.here:API-PORT
So for example:
$ curl -X POST --user "#123:test" -H "Exec: page bob=hi!;&BOB me=[secs()]" -H "Time: 30.5" --head http://localhost:1234
For GET action:
curl -X GET --user "#dbref:password" -H "Exec: functions-go-here" -H "Parse: parse/noparse/ansiparse/ansinoparse/ansionly" --head http://mymush.is.here:API-PORT
So for example:
$ curl -X GET --user "#123:test" -H "Exec: My string ran at [time()]" -H "Parse: parse" --head http://localhost:1234
It returns results and error conditions via HTTP headers just as submissions go.
So guys, enjoy, and go forth and cause havoc.
Cheers.
-
I wish I could code in shell or kornshell.
Not happening, but I wish that I could.
Clarification: I can script just fine in sh/ksh. Its just not supported on codebases for MU
-
@Ghost said in Codebase Pot Pie - Or what I like or wish I could have:
I wish I could code in shell or kornshell.
Not happening, but I wish that I could.
Clarification: I can script just fine in sh/ksh. Its just not supported on codebases for MU
That's the beauty of the API, you don't need to code in shell. Any language at all that allows webapi with headers, including, but not limited to java, javascript, cgi, php, python, or such, will work with this API interface.
I just gave curl as an example.
-
I'm not saying I'd approach it with the same time and energy as a second job, but I'm going to check this out and if I can throw my full sh/ksh scripting knowledge in, I'm gonna get some shit done.
-
I'm really liking rhost's execscript. It runs an arbitrary script written in any language you like and returns its results.
On character approval, it runs a script (a python3 script, specifically) that automatically creates a wiki page with their +sheets, their name, codename, birthdate, and anything else in game (except the bg, for now), all in the correct script. It automatically thats that page with the appropriate tags.
On purge, it replaces the page with a blank template and adds appropriate tags (ie, _retired or _unavailable depending on MC vs OC). This means our wiki is 100%% accurate with currently approved characters-- always. Without users having to know wiki or even signup -- they still can to add photos and more content if they like, but its optional.
Then we have another script that runs by default every night at midnight, or on-demand, which queries the wiki for new logs and adds them into a sqlite database for all participants. So we query that database for activity.
Theeeen there's another script that we run to upload and create a log, all with the right tags-- so again people can get what they 'need' to on the wiki without ever having to be good at wiki-ing.
I have another script that adds or removes tags from specific pages; so when I +faction/add person=faction, they automatically get the faction tag to their page.
All these scripts are allowing deep integration with our wiki.
Next project is to write a script to query the tzinfo database for live timezone conversions so +events and +bbposts are always displayed in your local timezone. (I already have rudimentary hacky versions of this).
And I'm just getting started: the stuff I'm gonna do with the API's....
Anyways, this is all examples of the cool stuff you can do with execscript()
Let's see, other favorite features. I couldn't live without full, deep regeditall and friends. I have some custom substitutions: %'ui' and %'std' so my code often looks like:
$+foo *=*:@attach %'std'/IS-STAFF;@attach %'std'/FIND-TARGET;@set %q<target>=blah.
Basically IS-STAFF looks like this:
&IS-STAFF %'std'=@assert isstaff(%#)={@attach %'ui'/DENIED}
So if %# is not staff, it gives a standard Permission Denied error. Then:
&FIND-TARGET=@assert t(setr(target,pmatch(%0)))={@attach %'ui'/NOT-FOUND=%0}
The %'std' and %'ui' libs allow me to do common actions without repeating any code. And since these @asserts and @attaches (alias for @include/override), when they decide to halt command processing, it halts everything.
I like that I have some mail() functions that let me completely softcode mail reading-- this lets me, in particular, write +amail so I can read my alts mail and have it marked as read after.
printf() is crazy powerful.
I like the /inline versions of @assert, @dol, and the like-- to run stuff now without queueing. Keeps things speedy.
-
I'm kind of a N00B at API/API usage/API setup. Any good resources on this out there?
-
@Ghost You'll need to be a little more specific. API stands for Application Programming Interface. It's just a way for one computer program to interact with another. For example: PennMUSH softcode functions are an API for game-level programs to interact with the PennMUSH server program. That API is similar to but ultimately distinct from the TinyMUX softcode API. So what are you looking for exactly?
ETA: I get that you're probably referring to the Rhost API - but what kind of program are you looking to interact with it from.
-
@faraday Sorry for the lack of clarification. Since a lot of these APIs differ (Penn/Tiny/Rhost), I'm mostly looking at Rhost but in terms of how to utilize the API in practical application towards MU.
I'm exploring really, and just looking for any good resources and examples that explain this process altogether.
-
@Ghost Here is a nice tutorial that explains how to utilize a REST API through Ruby. Wondering wtf a REST API is? It's just a reasonably standard way of letting one program talk to another. There's a general overview here.
For example if AresMUSH offered a REST API you could do something like have your ruby script issue a "GET" request to
http://mush.aresmush.com:8081/api/chars
and get a list of all the characters' data in JSON form. Or you could issue a "POST" request tohttp://mush.aresmush.com:8081/api/char/1
to update character #1 with some new data.Side note: Ares currently doesn't offer an API because the website is built in and I haven't come up with any reasonable use cases for an API beyond a website. If I find one, I'll probably build an API for it.
I don't know jack about the specifics of the Rhost API - you'll need to get more info from @Ashen-Shugar for that.