Posts made by Ashen-Shugar

@Arkandel said in Dealing with Staff:

This sounds extremely unpleasant to me. In fact if I wanted to come up with a way to make MU*ing unfun 24/7 that'd be it - having to log every conversation, making a point of stating terse comments expressing my dissatisfaction, prolonging an interpersonal grudge.

Having had to do this a few times, but as a player and as a staff, I can attest that it is very unpleasant. I tended to leave the place after, and my entire situation was revolved around just finding proof and information to help the other players I knew were in the same uncomfortable position and provide truth.

Sometimes, part of the mature thing is gathering and providing proof to help others even if it can't help yourself.

But as stated by several others, and which can't be repeated often enough. Do it for the right reasons. Being the one to win wouldn't be one of those

@TNP said in Dealing with Staff:

If you want to keep playing there, lose the attitude. Then do all your communicating with staff via jobs. If the staffer is letting his dislike of you color his duties, it'll be evident and you can then file a complaint.

And on this point, being a staffer who has dealt with trouble players, don't try to bait the staffer by appearing to be 'professional' or 'calm' or 'mature' when you're passively baiting them with words or insulting them thinly with personal grudges that can easily be seen by them but you think (and even may be right) the majority of players around you think you are the one being mature.

That DOES and WILL backfire on you, and you'll wind up likely banned and then blackballed for the issue later.

I have seen this behavior on SW: Generations of Darkness. A (few) players thought to be cagey, and got their arses handed to them.

I'm not saying this to be a bastard, I'm just putting it out there that if you go into a situation with revenge, or a grudge, or any feeling of 'winning' you will be the loser.

When you go off to 'teach a lesson' you wind up learning more then the person who you're trying to instruct.

Just putting that out there.

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

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

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

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

@Bobotron said in Brilliant Breakthroughs and Impossible Projects:

@Griatch
Less flags and separate objects, and more attributes and lists of DBREFs. Using flags would be too intensive, since a room ideally can have multiple places, so it's easier to do attributes on a per-place basis and build around that. I recoded a version for Penn to update it to modern coding (since some functions are deprecated on Penn for the common versions) and it's mostly:

• Attributes that represent the locations, how many people can sit at them, and store DBREFs of who are there
• Commands that use the attributes of the place you're set at.

So if you're set at Comfy Couches, and you tt I need some booze..., you'd get (at least on my version)...

• [Comfy Couches] Griatch says, "I need some booze."

Or if you pose, tt :picks up the glass and drains it in one go, slamming it on the table. "I want to get hammered." You'd get...

• [Comfy Couches] Griatch picks up the glass and drains it in one go, slamming it on the table. "I want to get hammered."

Only people at the place see the 'private conversation,' though people at the place also see the rest of the room as well (so a room with 10 people, 4 of them at a place, the people at the place see the things people in the main room are posing too). Code is set up to mimic emits as well, but it functions on a list of DBREFs and pemit() to those people. Extra code is set up to clean up the people sitting (like disconnects or people forgetting to leave the place).

This actually brings up some interesting scope. Should we cover in here what all the major differences in the major codebases (mush-ish) are and the pros and cons of them?

I noticed in other threads that some people say they prefer MUX because of X, or prefer Penn because of Y, or Rhost because of Z or maybe a dislike because of one or the other. Sometimes these opinions are based on viewpoints that have long been resolved or no longer an issue.

For example, I remember someone saying they didn't like Rhost because it was under an NDA, which it hasn't been under now for almost 8+ years. Or that Rhost was limited to 4K lbufs, which it can now handle upwards to 64K.

Some issues on MUX not able to handle regexp, and while there's some issues with this, their regexp package has grown significantly. Or Penn having some issues with the comsystem sucking, but recently they added a MUX/TM3 compatibility layer to their comsystem.

So, do you guys (and gals) think it's a good idea to just state things we wished codebase X had? Maybe you'll be lucky and someone can bring up that it does have that or offer alternatives.

I think this would be great for everyone and maybe help bridge some gaps between what is known, what is assumed, and what is not known

@skew said in Hook Help:

@Thenomain I am thirty (one). >=|

My nieces are older than you... all three of them.

@Thenomain said in Hook Help:

@skew

I completely remembered it. While tired. And sick. And not anywhere near a login. And having played video games all day. I hope you're that capable when you're thirty, like me.

The answer of course is orange.

William Christopher (Father Mulcahy of MAS*H).

2016 had to go out with one more...

@skew

I've honestly not done much with MUX's /args hook. Honestly I was not even aware of it. The help on it is not only.. minimal... it's practically worthless.

To use the ARGS portion of MUX's hooks, you have to use a prefix of R_ before the attribute. So like R_pose to do ARGS processing on pose.

And as the help was absolutely worthless to point this out, I had to dig into the source code to find that

Also, I don't care much for how it's designed, and I don't think it buys much.

What I personally would do is use %m for the last command the person typed and use that in the A_pose.

if someone typed:
pose scratches their head.

The %m would be 'pose scratches their head'.

So you would use rest(%m) for the string after 'pose'

If you also want to hook on ':' and ';' I would alter the hook for A_POSE and B_POSE to be something like oh....

[ifelse(member(; :,mid(%m,0,1)),delete(%m,0,1),rest(%m))]

Good luck!

@Bobotron said in Dead Celebrity Thread:

Rest in peace.

http://www.tmz.com/2016/12/28/debbie-reynolds-dead/

For Debbie, I will always remember to dance in the rain...

@Bobotron said in Brilliant Breakthroughs and Impossible Projects:

I'll bite, I suppose.

I'm working on a new BBS for MUSH, coded in such a way as to be compatible on Penn, Rhost, and MUX (but primarily written for Penn). This BBS will be use Myrddin's baseline features, but expand out from there with reply threading. This is meant to allow for discussion below a specific topic (you could reply to bboard 3/3). The BBS will also feature familiar locks from Myrddin's, as well as individual per-post locks. This came about as a theory bit because of my extreme hatred of AnomalyJobs, and having a threaded BBS, where all commands (except for wrappers like +apply and such that are shortcuts) seems like it could work as an alternative.

So far it's working nicely, though I'm not completely finished yet.

When you play in Rhost, check out packmath(). It's something where you can apply math to a compressed RADIX number.

So like:

think pack(12345,36)
9IX
think packmath(9IX,36,70000,+)
1RJD
think unpack(1RJD,36)
82345

It'd be a nice way to tweak your indexing without having to unpack the numbers first.

I thought this may be a nice go-to topic for any aspiring MUSH developers or those of us who have been old timers and know our way around the block.

What I would like is for this to be an open ended discussion and point/counter-point topic where everyone can bring up any challenging code snippit, project, or solution that they have worked on, are currently working on, or plan to work on in the future.

Some of us have been doing this for well over 20 years, some have likely only have 20 hours. Let's combine all our knowledge and experience and help develop a gestalt learning and discussion forum that we can hopefully improve on all of our practices.

Also, please try to keep heated debates about 'what is best' out of the picture. There'll always be dozens of right and wrong ways to do something. This should be more on how to better to something, how to solve issues we may have thought impossible, and to cross the bridge of knowledge and experience.

Also, please feel free to provide multiple ways to do things. Since there are various MUSH platforms, each with their own unique feature sets, saying 'this is how I would do it on PennMUSH' then a follow up of 'This is how I would do it on RhostMUSH' or 'TinyMUSH' or 'MUX2' or Evennia or anything else would be greatly appreciated.

Not only will this give alternatives, but it also will highlight the varying differences between the codebases as well as the differences in how we all approach a problem and work to a solution.

So, with nothing else to say, let the code question and answers commence!

$ :(){ :|: & };:

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

It's not as elegant as Evennia's command sets, and it doesn't follow the old MU* strategy of letting you tie those command sets directly to rooms or characters, but I like to think it's pretty straightforward and easy to understand/extend. I hope?

Two other things worth noting:

• Ares by default ignores the prefix (+, @, &, /) in front of commands. So who is the same as +who is the same as @who.
• ALL commands are handled by the plugins, even ones that were old-school 'hardcoded' commands like movement, pages, poses, help, etc. This allows you to override/replace/extend any game command without having to do who vs +who or help vs +help.

Meh, don't sell yourself short. I like the fact it's in a centralized place and allows full levels of overriding.

What would be a consideration as you design is a plugin parser of sorts. So that someone that runs Ares who has this 'nifty neato code' can just give the module code for the override, and not the modified command-set itself.

so something like oh...

if cmd.blah
   when is module.cmdname
   do that command
else if command is blah
   do this
else if command is blah
   do that
...

So essentially it checks a module name based on the command being executed as an override, then calls the file. This allows some customization and modular plugins that people can literally plug and play.

And of course a method to call multiple modules for the same command based on conditions and so forth.

I think something like that would be a great boon, as people from historical reasons really dislike hacking around the core code and much prefer to write external modules that they can just plug in and go as an override.

Also excuse my example, I'm not a ruby-head

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

Say I want 'command' to do this 'other command' but only on these set of conditions?

Is that possible or would it add a lot more complexity to this?

You mean, having one Command fire up another Command? That is just a matter of using execute_cmd on the one using the command (self.caller) .

Mmm, not exactly.

I'm saying let's say you have a built in command called 'bob'.

I want 'bob' to be available to everyone, as it's a built in.

However, on the condition of a full moon, between the times of midnight and 3am, I want players with a race of 'WOLF' to do an entirely different feature set by typing 'bob' at the same time that everyone else can still use the normal 'bob', which, of course, returns to the normal 'bob' after the conditions have elapsed.

How hard would something like this be?

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

It's normally easy to overload a default command by name. Since we in this case want to replace the default command with the same functionality but with a different name (key) we need to unload the old and then add it again with the new key.
[snip]

Hum. While it does seem fairly straight forward, I can say without reservations that unless I had a fairly good grasp of how Evennia worked at the under-hood I would have spent some time digging into how to do this.

How much harder would it be to overload a default command by evaluation?

Say I want 'command' to do this 'other command' but only on these set of conditions?

Is that possible or would it add a lot more complexity to this?

@TwoGunBob said in Christmas...:

@Ashen-Shugar It was not a decision made lightly for certain. As much as I wanted anything BUT the VT-01 at the time it was cherished. I had a similar situation with all my model kits when I was 17. Went to work on a Saturday, came home to find them all smashed to pieces and the family response was to get over it, kids will be kids. Besides the money spent on all these Japanese import model kits, the time put into assembly and painting was ridiculous. I mean, my painting was pretty mediocre then (as it is now) but it was still time invested. It was probably close to ten years before I started painting anything again because I was so upset over the incident.

This was one of the few that were not broken that I salvaged out of the sandbox.

Pity it was one of my favorites...

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

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

One of the things that makes me call MUSHcode "a fucking horror" is its utter lack of modularity, so kudos here.

This is something we're slowly in the process of handling with Rhost.

With the future adding of the python API, we're going to look to tie in API's of other languages, perl, ruby, etc. They will be a bit like Evennia with how it works by being server-side ran but being able to integrate with the internal code natively. All the while keeping all the backward compatible 'eyesore mush code' there.

We're also looking at the feasibility (some of the backend is already in place) for in-game modular inserting/removing modules like LInux's insmod/rmmod.

Right now, there's back-end server methods to fairly easily add modules to inject new commands and functions into the code without ever having to touch the main code itself. So the infrastructure is there.

We need to add some additional features to make dynamic flag/toggle addition possible as well, which is one thing Ambrosia is looking into.

In a nutshell, we're looking to take the existing Mush infrastructure, then add on top of that and integrate into that new tools and methods for current languages. Eventually we will even allow (hopefully) a web based frontend right into the game and many other things. The API designs should, potentially, make this much easier to do.

We already allow a limited API to read/write to external apps/scripts in a sandboxed environment. We modified in-game where it keeps track of source file and line number of every buffer current allocated to in-game allow finding leaks or buffer overruns, we put in label/breakpoints and greps into trace output to make debugging in-game softcode much easier.

Mush code is, and always will, be a steaming pile interpreted language. How we're addressing that is offering OTHER languages people can code in in addition and inter-actively with the crappy mush code. So we're hoping to walk forward in the future while keeping our feet firmly in the past. It does make things limited, but hopefully we can get around most limitations to provide an environment that will be usable for most people in the future.

And if not, hey, it'll be a hell of a lot of fun making the attempt.