Posts made by il-volpe

I see no reason why newbies should 'catch up.'

A MUSH can either have character advancement or balance, but not both.

@Misadventure said:

Perhaps a way to block nonofficial STs from seeing certain traits on your +sheet?
I guess that would effectively function like a preset of +proves, but I am thinking more along blocking a few specific things that are likely not to come up in regular play, and might dispell player mystery. Things like I am a spy.

I rather like the idea of an '+stme misadventure' command. I enter that, then misadventure can see all of my sheet, and set damage on me. Given that she's on the list of acceptable STs, or not on the list of players blocked from STing.

@Alzie Thanks! I wasn't sure if there might be some good reason for it that escaped me.

@Alzie Why would I want to tel instead of @fo the object to take the exit?

Is it not so that now you've given me boats that are checking the exit yet also bypassing it, which means that, hey, anybody watching won't be able to see where the stupid things came from, because they won't trigger the exit osucc and odrop messages?

@Misadventure Yeeep. I also hated that old custom of banning teleporting in any fashion and forcing people who didn't want to walk the grid to do it. Why even give a shit?

@Misadventure said:

I thought grids that simulate the land were a done thing.

Took me a bit to figure out what you meant.

I hate the new-style grids where things that are ICly next to one another are not next to one another on the grid, or things that are far apart ICly are reached via some OOC grid-hub or summat. The grid should give you some imagination milage. I don't try to stop people using +join, or hangouts-hop-code to avoid ever walking the grid if they don't wanna walk it, and there's nothin' I can do about people who just fail to read the descs (well, except make it so boats will not move where boats cannot go) but bugger the grid that reflects nothing about the lay-out of the IC world.

@Cobaltasaurus Yes. It's not that I don't know how to set the fail messages. It's that this doesn't tell you that you can't sail that way because your boat is too big. It would tell you that you can't sail that way even if you're not sailing, but swimming. Ideally, it ought to tell people, "You can't sail on land," if you try to sail the boat through a non-waterway exit, and "The water isn't deep enough for this vessel," (or better yet, a customizable message so they can't fit under the bridge, or whatever) if you try to sail through an exit too small for the boat you're on, and "You can't go that way," if I've locked the exit entirely for some other reason.

Admittedly, people don't read that shit so I'll still eventually have somebody tell me that they could sail all the way up the river in their canoe, but they tried it yesterday in a big trading carrack and it wouldn't go, the exit or the boat is broken, kinyafixit?

But it'd be nice to give 'em a chance.

And if I want, as I said above, to put the check on the sail command I've got, instead of as an exit lock, so I can have the messages actually tell you why you can't sail that way?

I am mystified as to the use of 'where' in there, as the entire boat object and all its contents should go though the exit, and since the sail command is @forcing the object to take the exit, would not 'where' then refer to the room where the boat object is, and not the boat object itself?

Ahh, so, Person I Must Deal With, you spent too many years apologizing to your ex when you'd done nothing wrong, so now you refuse to apologize to anyone even when you've done something really fucking rude or damaging? This makes sense how? Also, fuck you.

They are objects they enter. You then type 'sail <exit name>' and -- well the blurb of code is above in my first post.

@Alzie Thanks. If you'd write that in actual MUSH syntax, like, I could make use of it -- as far as I know, the > symbol is not how to compare said sizes, or the poking about code I was using earlier would work.

As I said, I'm ignorant as fuck, and really don't know how to make 'grab' and 'compare' into MUSH code, and bugger if the manual, such as it is, helps me.

Edited to add that, in all honesty, unless there's something wrong with it that I don't know about, I really want to use the 'hard way' code above, except have it actually work with a greater-than rather than an equal-to, because this allows me to tell people /why/ their boat won't move through the exit, rather than leaving them with the generic fail message, which I rather want to leave in place in case said exit is locked.

@TNP I think that would lock out swimmers (that is, PCs who are not on boats) too, and I don't want to do that.

@Alzie

Thanks, though, well, not enough detail for my ignorance.

I'm trying to do 'hard' way, because I have other purposes for zones, and really don't intend to have shitloads of waterway anyway. What I can't figure is how to say, "If the 'size' attribute of the waterway is greater than or equal to the 'size' attribute of the vessel, then...else..." rather than, "If the 'navigable' attribute of the waterway is 1, then...else..." like I've got.

&SAIL_CMD Generic Boat=$sail *:@swi [u(%0/navigable)]=1,@fo me=%0,{@pemit %#=You have to sail on water.}

Okay, fine. But I want the navigable exits to have a size, and the boats to have a size, so you can take a little boat up the river, but not a big ship. My prodding at this problem hasn't worked, for I am ignorant. Well, unless I just use two types of parents and have two types of navigable attributes on the exits, using both for large waterways and only the one for small.

@Three-Eyed-Crow said:

Forums are just easier to set up. Any rando can do it in 15 minutes (same with Tumblr games), and just as quickly abandon them. I'm cautious to call this kind of thing 'growth', but there's certainly a lot of it out there. Whereas with MU*s, you have to know something about the back-end to get one going,

Yeah, but it is getting tonnes easier -- I totes suck at this shit and could do it alone now, thanks to Faraday and other clever folks who've shared code.

I can see lots of people liking both formats. But while forum games seem to be abundant, possibly even growing in numbers, MUSHes are not. It seems like a rich territory to find potential new players.

GoB was remarkably non-cliquey until kinda recently, and is still a shittonne less so than normal, in my assessment.

@ThatGuyThere said:

As a hobby we are very closed off and borderline hostile to new folks.

Borderline? Hehe. Watch what happens when I say,

"I'd like to try to get folks who are into play-by-post forum games to try MUSHing,"

(This is actually true.)

I've got a How-To-MUSH wiki-page. It'd be nice to have some feedback on how to improve it. Anybody who wants to copy it, edit it, and use it for their own game is welcome to it.

Not at all. As a design for a game that develops coherent story, narrower focus is so very much better. I think GoB (before I took it over, and continuingly) did have some elements of being an answer to other GoT games being draconically narrow in their list of playable concepts, so it's rather wide open.

Though the practical (rather than "this is just the way we chose to do it") issue I'd see with focus on a single family is how incompatible that can be with player turnover. I see that as a major flaw of GoT as a MUSH setting in general -- bugger playing pre-made roster characters, I think most people want to make an original character. But in spite of the source material's habit of having people die practically at random, characters wandering off the game because of players having other shit to do leaves PC families in weird places. Also that thing where some people really hate it when they just suddenly have a brother who was never mentioned before.