You're on a boat!
-
&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.
-
I thought grids that simulate the land were a done thing.
Also, it's all about the draft.
I have a waggish sense of humor.
-
2 options. Easy and hard. I suggest easy.
Easy:
- Create zones for the ships and exits. Check the parents of each. Code for the large and small waterway parent.
Hard:
- Set each exit to have a size and each boat to have one too. Make sure they're compatible.
The easy way just requires setting a parent. The hard requires each one to have an attribute set.
-
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.
-
I think you can do it with lock. Give each boat a size attribute. Have the lock check for the attribute. If > maximum size for that lock it fails.
-
@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.
-
Needs a command that gives me a nautical-themed Pashmina afghan.
-
So basically. You want to do this.
Set size on boat. Lock it to wizards but set it visual so exits can pull it without being set wizard.
@lock exit=canpass/1|type^player
&canpass exit=grab size of %#'s boat and compare to get(%!/size)That will let them pass if the size of the boat works or they're a player object.
-
@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.
-
I can help with that. Can I know a bit more about the setup? For example, are the boats objects they carry? Or are they objects players enter? If they are just things they carry, how do you know when someone is sailing?
-
They are objects they enter. You then type 'sail <exit name>' and -- well the blurb of code is above in my first post.
-
That makes things considerably easier.
@lock exit=canpass/1|type^player
&canpass exit=lte(get([where(%#)]/size),v(size))That will only allow someone through the exit if the size attribute of where they are is less than or equal to the exits size attribute or they are a player object.
-
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?
-
Hit up an @fail and @ofail on your locks saying: "You can't sail that way" -- this should emit to the room/player that they can't sail because they failed to pass the lock.
-
@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.
-
@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.
-
If it makes you happy, it's good, and it won't get in anyone elses way.
I have a waggish sense of humor.
-
@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?
-
@il-volpe the fail messages can be whatever you want to be clear. As to where, it would grab the object's dbref. If you enter an object, your location is that objects dbref. As to making it part of the @ command, that's a little harder. I will do that in a little
-
Okay, so, the player types sail north for instance from inside the object. The problem is that the exit isn't inside the object. So you can't just assume it is. So you have to account for that.
sail *:@switch [setq(a,0)][iter(lexits(where(where(%#))),if(strmatch(name(%i0),%0*),setq(a,%i0)), ,)]%qA=0,{@pemit %#=That doesn't appear to be a direction you can sail!},{[if(u(%qA/CANPASS,%#),tel(where(%#),loc(%qA)),pemit(%#,Your boat can't fit through there!))]}
