Posts made by Ashen-Shugar

@Arkandel said in Tracking Alts on Dynamic IPs:

I don't know how IP matching possibly works in large cities where most people subscribe to a tiny number of ISPs. In Toronto other than a handful of techies I know almost everyone's either using Rogers or Bell, and all it takes to change your dynamic IP is turn your modem off and on again.

Most of these larger ISP's and back-end tiers lease subnets of their larger subnets to these smaller ISP's.

With some small amount of digging around, you can get the subnets for these tiny ISP's and block those specific ISP's and not the larger subnets.

A few exceptions are china ISP's where a lot of their information is hidden behind the great wall of china, where a lot of times you have to block entire A-class addresses if someone's being a turd and trying to attack your site as their subnet information is obfuscated.

But generally you're pretty good by blocking based on the subnet lookups you can find of any given ISP.

For those who try to hide using proxies, you can get most of the IP lists of the most common proxies and even have dynamic methods to block the more nefarious proxies like TOR with some hardcode mods.

There's always ways around things, but it boils down to what level of restriction you want. The more you tighten, the more chance of impacting innocents. So you have to weigh every choice you do.

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

@Three-Eyed-Crow said in Fuck this guy:

Anybody familiar with MUSH of the Dead (http://mushofthedead.com/)?

I'd like to know if this particular brand of fuck is staffing on other games, or alternatively if he's incorrectly attaching himself to another game.

I've tagged his IP for watching on every game I admin on

@il-volpe said in Fuck this guy:

65-33-226-46.res.bhn.net

This critter doxxed the guy who hosts my game, under the impression that he is me, and tried to get players to harass me by telephoning our host.

Not sure where this sort of thing belongs, or if it's even proper soapbox use.

doxxed? You mean DoSSed? Any proof the site was under attack?

If so, you may have the site owner bring in the authorities, as DoSing is a federal crime.

For giggles I introduced a method to have, essentially, full psudo-breakpoints in trace output.

It essentially allows you to add start and end tag/markers in softcode to specify locations where you want trace output to occur. You're allowed to add up to 1000 tags to a single running command (or $command sequence). You can enable or disable these tags (labels) at any point which works like how breakpoints would work.

With this, there's also a method to highlight (with optional regexp pattern matching) patterns in red of any trace output. This can work with or independently from the breakpoint/label system.

For those curious for more, 'help @label' on any RhostMUSH running the latest code will give you a review of how it all works.

Enjoy.

@Auspice

I'm a big coffee man. I roast my own coffee and all that jazz.

However, other than a good single malt scotch (cough) I'm also a big tea man. Wife loves tea as well.

I've recently started ordering from the whistling kettle (http://www.thewhistlingkettle.com/). They have mostly loose leaf tea, and it's fairly top notch.

My favorite teas to date are lessee....

Irish Breakfast
darjeeling 1st blush,
Aged Pu-erh (15+ years preferred). I like both raw and cooked, though cooked helps more with healing.
Lapsang Souchong
Aged Oolong (Prefer Blue Spring)
Earl Gray (I like the derivatives that have like various flower blossoms added)

And some flavored White teas go great for ice teas. Have a nice leechee tea and some white chocolate tea (with actual cocoa nibs) that make excellent tea for the summer.

And that's about it for my favorites.

Green teas I'm hit or miss as they tend to be a bit too bitter for me.

@Arkandel said in The Cat Thread:

@Ganymede said in The Cat Thread:

(3) doesn't need a fucking sitter every time my partner and I go out because OMFG WHAT IF HE WAKES UP IN THE MIDDLE OF THE NIGHT?!?!?!?.

<squints>

What kinda super-cat do you have that doesn't wake up at 4 am, find that the food dish is only 1/3rd full then starts wailing like the world is on fire?

@GangOfDolls

I've seen tons of games succeed, and die. Both under my own leadership and under others.

There's no perfect recipe for a game. There just isn't.

We deal with different personalities, of different nationalities, of different beliefs, of different egos, of different broken psyches, and you put that all into a bag and shake it up then pour into a mixing bowl to cook and hope it doesn't blow up.

In the end, every MUSH, without exception, is a bit like this:

How long the game lasts at this point is a mixture of several things. Some have a higher weight or a lower weight both on the way the game is ran, the types of players you attract and the base rules you founded the game on.

• Set rules that you define upfront. Stick to those rules, for staff and players alike. They either apply to everyone equally or they're not a rule. If you need to change them, have it signed off by the majority of staff, and provide open and public reasons why the rule was done and what the new rule(s) are. No surprises. People loathe surprises.

• Set up pre-defined rules of what expectations of both staff and players are. Lots of people know where I stand on the pre-determined entitlement or belief a game owes them something. If you think the game should, set that up front so people are not surprised or disappointed that what they expect and what is to be expected do not differ.

• Select solid game mechanics and a good staffing to handle them. Make it well understood and get player involvement right out of the gate. Not only does it help players feel good that what they do helps provide direction for the game, it's a good way to test what you're building to adapt as you go. There's a reason big corps have beta testing. We should as well.

• Burnout is a huge mess. Staff and players alike get this. We grow tired of a situation, a gaming engine, or anything else. And frankly there really is no ready solution to this. The reason? Burnout means something different to each person. The best way to deal with this is to talk to the person/staff getting burnout and see if there's an active solution to it. If one person burns out, likely others will as well eventually on similar reasons. Likewise, if you are the one getting burnout, it's generally common decency to alert the staff of why you are getting it. Again, burnout is not a bad thing, it just happens. But maybe something can be done to help solve it, if not for you, then for the next person.

• People change. We grow up, we get old, sometimes we die. Lots of people who have mudded like me are getting close to retirement age, and we're not the spring chickens we once were. One day, we may leave entirely or not be around anymore. Shit happens. What we should do is pass on what we know to the younger generation so that they can apply what they want and so forth. Teach, learn, exchange, freely, openly, and without all the emotional baggage we tend to bring to the table. You can learn from an asshole or an enemy just like you can from a friend. Ignore the crap and take what you can from it. We're all (for the most part) adults, let's start acting like it.

So I guess how do you make a game successful? In the end you can't. They are all, without exception, doomed to failure. Accept this, and do it anyway. Because it's fun. Because the enjoyment you see others get from your own dreams and designs tickles you, because you just like giving to others and watch those same people give to others. It's a chain reaction. And like any chain reaction, it eventually ends. But the time it is firing away is truly enjoyable. And that's why I do what I do. In the end, you have to figure out why you do what you do.

Cheers.

@Tinuviel said in PennMUSH & DBREFs:

@Ashen-Shugar Would this depend primarily on the type of compression they use? Or is it simply a side effect of a large database?

I honestly wish I could answer this, but I really don't have one.

I've not tore apart PennMUSH at that level and ran it through any sort of performance analysis.

I'd first really want to run it through something like valgrind just to see where all the allocations and deallocations were occuring.

This could be nothing more than poorly managed memory, but again, without really digging into the code and tagging it with a performance engine debugger all I can do is speculate.

@Seamus said in PennMUSH & DBREFs:

I'm curious, has anyone seen a PennMUSH that went into the 10s of 1,000s of DBREFs and if so did it negatively impact the game's general performance?

I"ve not personally seen slowdown in execution of code, but I have seen first hand much slower save times with larger number of dbref#'s and more attributes per dbref#'s in PennMUSH.

I'm not sure why. May be related to the unique way they store their data compared to other systems.

@icanbeyourmuse said in Room parent / exitformat weirdness:

@Ashen-Shugar I am a wizard. The only time the issue crops up is if @Cobaltasaurus owns the room and I set the attribute on the exit or vica versa.

Who sets the attribute shouldn't matter. It'd be the ownership of the object/room/exit.

If you, as a wizard, set an attribute on something you don't own auto-hides that attribute, that's a bug. it shouldn't do that unless you expressly set the attribute hidden or if the attribute is pre-defined as wiz only.

@icanbeyourmuse said in Room parent / exitformat weirdness:

The exit owner did not matter but when i owned the room and set the attribute it went where it should. Even if @Cobaltasaurus owned the exit.

Double check to see if you, yourself, are not inherit.

If a player is set inherit, it assumes inherit on anything they own.

DO NOT DO THIS.

Another option is setting the exits, rooms, etc with a @power of see_all (I think it is?) which also can be somewhat abusive. Other than that, I'm unfamiliar with anything in MUX that would grant one player full access to everything w/o an inherit for darkish things.

Best bet is what is suggested earlier, just make a central builder character and chown all rooms and exits to them.

Not only does it allow the ownership and permissions to match up, it also keeps things less cluttered as you know who owns what and why they own it.

@Seamus said in Room parent / exitformat weirdness:

True I was just throwing it out there as a possible issue. I know with Rhost it can cause havoc.

Meh, not really.

Attribute ownership in Rhost is pretty identical to the TinyMUSH (MUX2) standard.

We do have some additional flexibility where if you set the attribute hidden and a given bitlevel the attribute will be hidden from anything below that bitlevel.

But this isn't set by just setting an attribute. The attribute flags have to be individually set.

For Rhost, the other things that can affect attributes:

If it starts with a '_' it's automatically wiz only.
You could apply an attribute prefix permission mask via @aflags.
The attribute could be set with individual global flags via @attribute.

With Rhost, you could identify all the various global permissions via @aflags <attributename>.

You can just do lattr(#obj/attr) to see individual attribute flags on it as well.

Minus the magic foo with @aflags, the above would also work on MUX.

@Cobaltasaurus said in Room parent / exitformat weirdness:

@Thenomain said in Room parent / exitformat weirdness:

The child room has no access to the filter attribute (the attribute, not that it's a filter) on the parent. I'm not kidding and it's a design feature for security. Here's one of the few times I'm going to say: Use iter() to build your own inline filter.

But why did it work before? It worked but stopped working for only objects that I recently messed iwth.

Unlike Penn, MUX and Rhost are more inheritance based.

If the object was owned to a wizard and set inherit, it likely would have worked as it inherited those wizard powers from the owner.

Likewise, even for non-wizard, it would still require inherit to access anything not itself.

Exceptions to this, like as you saw with the visual flag (or you can set the attribute visual) and various other things are likely possible depending on what codebase and what version of that codebase you have.

@Apos said in Fanbase entitlement:

I get what you're saying, but if you take that to the logical conclusion then it would be okay for people to take advantage of others' work on MUs. I don't think any of us would disagree that is a bad thing to do, so I'd say there's a difference between contributions when it's basically asked for and just doing something alone in a sandbox of their own investment, and MUs really blur the line between the two.

Pretty much this.

My personal belief is there is no such thing as entitlement at all in mushing. Frankly, we're not really entitled to anything. Ever. At all.

We work to invest time, patience, energy, and effort into something. In this case that something happens to be mushing.

We take out of it enjoyment, a feeling of accomplishment, co-work with others and hopefully advancement and achievement of self and the help of the same with others.

But that's not entitlement. That's reward for effort put in.

I think the lines of entitlement and justification got blurred over the years to work, effort, and reward.

Somewhere, along the time, people woke up and felt that they were entitled, because of.. I don't know... whatever. I don't get it now, and I don't get it then.

We are what we put into things, even if that's as simple as day to day breathing. If you want a rewarding experience, you work for it.

If the staff or players on a game are buttclowns and are of the 'me mentality' and have no desire to work with you or reward you for work you invest, then you need to ask yourself if the fun you get out of the game is worth staying, or to go somewhere else.

You're not entitled for the rewards, they're rewards for a reason, and usually a gift.

I'm not entitled to a paycheck, it's frankly a reward of my long and productive hours of work. The fact it's not an entitlement means I can be laid off for any or no reason what so ever. Mushing is a lot of the same way. Regardless of the work you put in, while rewards is a nice thing, it'll never be guarenteed, nor is it entitled to you. It'd be darn nice if you got it, and likely keep the game successful if it is, and likely crash and burn like we have seen many if you don't, but, there you go.

@Thenomain said in Making a MU* of your own:

Involving. And involving means invested.
I have some thoughts about how to do this without losing control

I've found one important thing to do when you start a game is to pre-establish the rules, set up guidelines, make them flexible enough to allow a small amount of wiggle room when required, but make sure that they apply to everyone, players and staff alike.

And the most important thing.

Stay consistent. No exceptions for friends, no hard-nosing for enemies, treat everyone the same based on those rules. If it means you keep someone you hate who's actually behaving, so be it. If it means you remove a friend who's being a troll, so be it. You shouldn't be a total psycho to everyone, just as you shouldn't be a total passive accepting 'turn the other cheeker' as well. Just approach it with maturity and be yourself. If you're a bit heavy handed, fine, but be that way to everyone. If you're a bit more forgiving than normal, fine, but be that way to everyone.

The moment you lose the entire point and start to play favorites, or heaven forbid, try to please everyone, that's where the big problem lies, even if that favorite is yourself or your player-alts.

I have a reputation of being a total hard-ass on mushes when I have any position of power. But one thing I strive to do is be consistent to everyone equally and as fair as possible. I don't always succeed, and likely you (the collective you) won't either. Welcome to the human condition. But when you fall short, and realize it, pony up, admit it, take responsibility, and move on. For better or worse, that's an important factor to make a game successful.

@skew said in Sort by last character?:

Thank you all for the replies. I've not actually gotten around to testing the latest solutions, because I discovered a way to sort my rotes by arcanum in a nice, clean, neat fashion. So, deciding if I want to mess with reverse order.

It's not exactly code, but anyone have an opinion? Would you rather see rotes (For Mage: The Awakening 2E) alphabetical, or by dot level? They're dot level in the book.

My suggestion? If you're designing this from scratch, allow player customization so that the player can specify what sort method they want for it.

It should, theoretically, just be a matter of u()ing a different attribute based on the customization the player wants.

So something like oh....

...[u(#obj/SORT.[default(%#/_sheet_sort_method,default)])] ...

Then SORT.DEFAULT is the default sorting method (however you want).
Then the customized attribute '_SHEET_SORT_METHOD' on the player contains the sort method they want to use (whatever you define)

Then just u() the #obj/SORT.DEFAULT (or SORT.NUMERICAL, or SORT.ALPHANUM, or whatever) and design your own sorting algos for how you want to sort it on the fly.

This method also allows adding new sorting algos on the fly without really re-designing any core functionality.

reverse(sort(reverse(<string>),n,|))

@Griatch said in Evennia for MUSHers:

The closest I know of a real Python sandbox is the PyPy project''s specially compiled python interpreter that offers that possibility. We have not explored this for Evennia but since you require compilation anyway it might be worth to look into.
.
Griatch

Yup, you've ran into the same problems I have run into.

pypy also doesn't cut the bill at the current base because it still has tags into the strict hardware layer itself of the server running under it.

So while it is marginally sandboxed, it still allows race conditions and jumping permissions by tagging into device drivers. So it's still half-baked as a security model.
It also has known memory leaks.

Maybe sometime someone will get a working sandbox model, but right now it's a bit like:

@Griatch said in Evennia for MUSHers:

@ThatGuyThere said in Evennia for MUSHers:

I was one of the big proponents of being able to use softcode in the last conversation and i still am.
Most of what I use it for basically to let me do tasks I do often quicker, such as WoD power activation, or shifting in places that did not have a shift code set up so I could make a quick shift command and have it macroed in to change my name, desc, etc to fit the new form my character had taken. Now every recent game I have played a shifter on has had shift code in place so it is less of a practical issue in that case anymore.
I have not had to really use any of my limited soft code tricks because now the games have things set up so there is less of a need to come up with them from a player side of things. though I still like having the ability to if the need should arise.

So if I understand you right, your main use case is to to alias commands to your own needs (such as entering something short to abbreviate a longer series of commands).

Out of curiosity, if you look at the example of Evennia's "nick" Command in the tutorial above, do you think that could replicate to some extent the aliasing you'd now use softcode for?
.
Griatch

Something you could look at (that I've not been able to figure out but you may have better luck than I have) is a sandboxed method to allow in-game transposing of a limited python or similar scripted language in-game.

The issue I always run across is using any mature language in-game allows too much control and allows escaping the sandbox to the server running below it. I've not yet found a clean and safe way around this. But I think that's the golden ticket for future mud based gaming. A mature language system in-game that allows a safe and configurable complexity in a completely safe sandbox.

I'm still poking at things, and if I find a solution I'll absolutely let the mud community know, but so far, no joy