|
|
Forum Guru
Group: Forum Members Active: 2/3/2007 Posts: 39 |
|
Well, there's a lot of issues with the MUCK crashing right now, but with the advent of more code to work with, and the high probability that I'll have a job by next week, I'm working on inrooms again.
I've changed some of my plans and ideas from the last update, and solidified some of the concepts I wasn't sure how to achieve. This is what I plan for version 0.6, leading up very soon to a complete 1.0.
Below is the list of changes, and a link to the description of each.
Inroom Flags The R Flag The Size Flag Using Names as well as Dbrefs The #set Command Flush Actions Add, Remove, Open, Shut Entering and Leaving Inrooms Messages and Pronouns New Help System #update Does Version-checking on Connect Menus Roleplay Feature Inroom Forcing and Actionlists Types of Inrooms Two Built-in Inrooms Message-setting #find Works Differently
top
-Move the basic switch settings for #allow, #listen, and #loud to a simple flags property changed by #set. For instance, 'ir #set MyRoom=Allow!ListenBroadcast' or 'ir #set me=A!LB'. top
-Add a Roleplay/R flag, for the roleplay function described below. top
-Also, there will be a Size/S flag set, for size-checking before grabbing. If a player has the size-flag checked, then the grabber will be forced to check their inrooms size prop, which will be either micro, normal, or macro (1, 2 or 3). If the grabber or inroom has the size flag checked, size will also be looked at first. If the victim's size isn't less than the grabber's, the fail message will automatically be given. Player's sizes will be asked when they first start using inrooms, or everyone using the program will be asked after the first update. Size will be changable with ir #size . top
-Obviously add the ability to use names as well as dbrefs - and also partially match names (including playernames). For room settings this should be global, for moving players this should only work if they're in your local or an inroom (for flush actions, below). top
-Allow #set to also be used to set locks, as in 'ir #set PlayerName=A!LRB[=MyRoom]'. This will actually simply use reflists for different purposes. !A will actually add a playername to a locks/deny reflist, instead of removing them from an allow. If the player's in that reflist, they won't be allowed to use inrooms with you or your room - depending on how you set it. Roleplay, will default to off, so that will actually set a POSITIVE reflist. Listen and Broadcast default to ON but come second to the room's global settings. But all of this makes no difference to the user, they're simply setting flags in the same familiar way they set player flags. top
-Add flush actions, which simply allow people to 'grab' someone in one of their inrooms, and move them to another, or possibly even just move the whole contents of the room by not specifying a player. For instance, if somebody had a mouth, a throat, and a stomach, they could 'eat PlayerName', then 'swallow PlayerName' and it would send them to the throat, then maybe 'stomach PlayerName' to send them to the stomach. Then just 'digest' to send ALL the contents of the stomach to the small intestine. top
-Change the way #open works. Add an #add for actually adding inrooms, with the simple, quick format of 'ir #add RoomName=GrabAction[=Type[=Flags]]', the type and flags parts being obviously optional. Type refers to whether the inroom is internal, external, or an object, and defaults to internal. These values are simply 1, 2, or 3, or any part of the words 'internal', 'external', or 'object'. Then #open itself would open either a grab or flush action, of the format 'ir #open ActionName=Destination[=Source Inroom[=Flags]], where both source inroom and flags are optional, and setting a source inroom will make it a flush action. There will of course be #remove and #shut actions to simply and effectively recycle your inrooms and exits. top
-Remove the (O)ut;out;o action that's put on every inroom; there will now be two global actions for getting in and out of inrooms on your own: enter;in;getin will get you in a nearby inroom if it's set Allow, in the format 'enter PlayerName's Inroom'. And o;out;exit;leave will ALWAYS get you out of an inroom - possibly into another inroom, if one contains another, but eventually you can get back to the owning player's location. top
-Finish moving and fixing messages and pronoun substitution. In order to accomodate for both victim and user, there will be two sets.
%n will get the grabber's name. %v will get the victim's name. %s will return subjective for the grabber (he/she/it). %x will return subjective for the victim. %p will return possessive for the grabber (his/her/its). %l will return possessive for the victim. %o will return objective for the grabber (him/her/it). %k will return objective for the victim. %a will return absolute possessive for the grabber (his/hers/its). %z will return absolute possessive for the victim. %r will return reflexive for the grabber (himself/herself/itself). %f will return reflexive for the victim.
Also, %i will return the inroom, %j the user's location, and %e the action used.
Even if a victim enters an inroom themselves, they will still have the victim tokens and the person owning the inroom will have the grabber tokens.
Messages will be stored in a directory that mirrors the typical message one, only in the _inrooms directory:
_inrooms/_/succ _inrooms/_/fail _inrooms/_/osucc _inrooms/_/ofail _inrooms/_/vsucc _inrooms/_/vfail _inrooms/_/odrop _inrooms/_/vdrop
Each of these will work exactly like they do normally, except that vsucc, vfail, and vdrop will display only to the victim. These messages will be triggered this way even if the victim enters the inroom themselves. top
-Combine all the informational and help commands into one, indexed help. Of format 'ir #help' for basic help with a list of topics, or 'ir #help topic' to read a particular topic. These help documents will be stored in proplists that the program will access dynamically, so all that has to be done to update the documentation is lsedit the proplists, and the list of topics (and topic commands) will be updated automatically. This will include the current #list, #new, and #props, as well as better documentation on each individual command, and detail on each of the properties inrooms uses. top
-Create a version-checker that compares the inrooms current version to a player's stored version when they connect, so when inrooms is updated, everyone will get a quiery to update their inrooms to keep up. This will only occur if people HAVE inrooms. Also, aside from the quiery version which will do the old run-through everything, make fixes, and ask the user what they want to do about important changes, there will be an #update menu so people can update or check only certain things about their inrooms, like that all their inrooms have grab actions associated, which ones are set dark, that all the properties are set correctly, etc. This way people won't have to go through EVERY SINGLE question every time they run #update. top
-Create a simple #menu command that simply allows the user to see all their settings, change those that are changable (some of the rp one's aren't), add, delete, and manage each of their inrooms and exits, and maybe even see who has them #set to deny, listen, broadcast and roleplay. top
-Alright, the promised roleplay function. It will be very simple, no complex dicerolling or statgrinding. There will be only one stat, speed, and while you *can* view it, you can't set it, and you don't really need to know what it is.
Basically it works like this. Say you have the roleplay flag, R, set on yourself, and someone also has the R flag on an inroom. They try to grab you to that inroom. Both your speeds are compared. Speed starts high, say, 5, and over time (I think based on a very basic experience counter, but I'm not sure yet), gets lower, to a minimum of 1. If the grabber's speed beats yours (the victim's), you have the grabber's speed in seconds to respond.
You get a warning message (probably stored in _inrooms/_/vwarn, as well as warn and owarn for the grabber and room), which also tells you how many seconds you have to respond. In that amount of time, you have to type 'dodge' to roll a chance (again effected by speed) of dodging the attempt. If you succeed, there will be a dodge success message (_inrooms/_/dodge, vdodge, and ododge?), if you fail, the normal inrooms success messages will be displayed, and you'll be grabbed and sent to the inroom.
Then, when you're IN an inroom and both you and the inroom have the roleplay flag set, you can try and 'escape'. This has no timer, but just rolls your speed versus your captor's, aiming for the lowest roll. I possibly might add a modifier to inrooms that are used a lot, perhaps their own speed, that adds a penalty to your roll (or subtracts a bonus from the captor's).
My idea for how to modify speed is based on success percentage, which basically comes down to usage of the program. ^_^ So, if everyone starts at 5, and one person uses it a lot more than another, their speed might be 1 when the other's is still 4. My idea for the experience was simply to have it slowly add up to 1000 or something, awarding more points for a greater success, and less for a lesser, but not taking away points for losing. Or perhaps just losing taking away less points than winning gives. Once the counter gets to 1000, speed is decreased by a point, and the counter is reset. top
-The next cool feature I wanted to add to inrooms to make it more roleplay-esque was inroom interaction. Since I'm going to allow object inrooms, allowing them to enter and leave inrooms as well, or send messages back and forth, or be @forced by the user sounded like a really neat way to open up possibilities.
So this is how it works. You can 'GrabAction #force=MuckAction', and you can also use MPI by making the action 'MPI {stuff}'. Then, I'll also add MPI code to run action LISTS, or basically force a series of actions pre-written in proplists.
These won't be normal proplists, instead the number of the action will be a time, like seconds or tenths of seconds or something reasonable. Basically, skipping 1 takes twice as long, skipping 2 takes 3 times, etc, where it would normally be moving smoothly if none were skipped. So basically, you can set up, event-by-event, with time delays, a list of actions you want to run through.
An inroom can have as many actionlists as you want, and they can contain any actions or MPI (after the MPI command) you're allowed to use. Finally, inrooms can be set to allow having another inroom's actionlist run on it, but it can't be directly #forced. There'll just be MPI for forcing an inroom interacting with yours to run one of your actionlists. It will also ignore certain commands, depending. top
-Now, the different types of inrooms. They'll be internal (the normal room ones you have now), external (sort of like ride or hopon, but with more options, and of course grabber-initiated), and object (inrooms on portable objects).
For instance, say Akisame has all three kinds of inrooms. He may have a handpaw with a 'grab' action, that's an external inroom. When he uses that, it prints a message as normal, but the drop messages are only printed to those also considered 'in' the external inroom, and the first success messages aren't. This will be handled by a reflist on the player, room or object with the external room (yes, rooms will be able to have external inrooms), and there will also be a prop temporarily set on the grabbed player or object (also objects will be grabbable by inrooms).
The player is told they're picked up, so is the room and separately, anyone else who's been picked up. If the carrying player moves, the carried follow. All messages in the room will be heard, because the people will be in the same room, really - no need for broadcasting at all. If the room has listening turned off, but the external inroom doesn't, then if the object or player has other inrooms that are broadcasting, those in the external inroom will hear them.
Optionally, there can be a 'window' description that masks the room description. All this is is a look-trap on inrooms, that either passes the player on to the normal look, or forces them to see the external inroom's description instead - optionally (and on by default) with an 'Outside, you see:' sort of thing followed by the room's description.
Now, Akisame might have a 'muzzle' object, with an inroom on it. The object is a vehicle object, and so players and other objects can be put inside it. Again, the messages are sent, and the player is transferred into the object. Broadcasting works as normal. Only this time, the object can actually be dropped by the owner.
Akisame wouldn't be likely to drop his muzzle, but he may drop a Slipper, for instance. Now, Akisame's muzzle can have external rooms on it, and he could use a flush action to set somebody on top of his nose. But he could also put them in his mouth. Using the interactive #force command, he may have a tongue object inside the mouth that he forces around, and may force the mouth itself as well. Perhaps he would initiate an interaction with somebody else's inrooms, and kiss them, and the two tongues would press the person in the mouth back and forth, perhaps transferring them to the other person's mouth room...
...or Akisame could swallow the person. Then they'd be sent to his stomach room, an internal room - from the object inroom. So we've gone from the ground, to an external inroom, to an object inroom, to an internal - this can work in any direction!
You could also have an inroom object in an inroom object, interacting with another's inrooms while there are players in the innermost object...the possibilities are quite limitless!
And yet there's still more. Object inrooms can be passed through flush actions, and they can ALSO have a forced description similar to external. Except this forces you to see the object's description no matter what you look at. This can be used to fake transforming someone in your inrooms. By flushing them into an object that's look-forced, you can leave a window to the world outside and what's going on, but they'll see the inner description of the object no matter what they look at, even themselves! You could use this to literally digest someone as you passed them through your system! top
-To display the capabilities of inrooms, give somebody a taste before they create their own, there will be two default external inrooms available, but also overridable - grab and stomp. Stomp flattens somebody under the stomper's foot, causing them to stick as the person walks. Grab picks the person up and holds them. Both come with flush actions to set people down/unstick them, as well, and without overriding the inrooms completely, you can change the messages/descriptions individually. top
-Which brings me to another point. Since #open (and #add) won't be walking through a query, You need some other way of setting your descriptions and messages. This will be available through the menus, but not everyone wants to wade through those.
So there will be commands for each, respective to their names. #succ, #fail, #osucc, #ofail, #vsucc, #vfail, #vdrop, #odrop, #warn, #owarn, #vwarn, #dodge, #escape, #oescape, #efail, #eofail, and finally, #desc and #odesc. Odesc is the one written seperately because the focus is on what's inside. ^_^
Also, there will most likely be some sort of movement messages, too. Inrooms versions of _connect, _disconnect, _arrive, and _leave. However these are stored, they'll also be settable with the same command names - #connect, #disconnect, #arrive, and #leave. These will be triggered when the inroom owner moves or their connection status changes. top
-#find will now only list the names of players using inrooms in the current room when used by itself, as well as listing the room's listen, broadcast, allow and roleplay settings. To see a list of someone's inrooms, type 'ir #find PlayerName'. This will not show dark exits or rooms, or inrooms with the setting _inrooms/hide? equal to 'yes'. top
There's some other aesthetic and functional minor changes that I can't think of right now, but when I get to that part of the coding, I know I'll remember. ^_^
So now, suggestions time! Who has suggestions for inrooms? These aren't guaranteed to be included in this version, or really at all, but good ones will certainly be included! So suggest away! ^_^
|
|
|
|
|
Supreme Being
Group: Forum Members Active: 3/22/2011 Posts: 152 |
|
Maybe a few on-player-flags would be nice -- for example: if I'm about 6ft and Blue is maybe an inch or so taller than me at the time, he shouldn't be able to eat me unless he has some sort of 'stretchy' command. If Blue.stretchy=0, then his attempt to ingest me would fail automatically, although maybe everyone in the room would receive a comical message about the action and its result. If he were to be, say, 20 times larger than I was, though still not stretchy, then he'd succeed if I couldn't dodge and then haul ass to a safe place.
It wouldn't be too hard to put in a height converter into the MUCK. So conversion between in, cm, ft, and m (and maybe mi and km, I guess), to allow for the height-scenario-thing.
One thing that I thought of the other day way to have would be roomkeys, i.e.: items that will allow entrance into certain areas when carried, rather than just playerallow-stuff. For instance if I wanted to go into someone's apartment, I couldn't just go... I would have to, maybe, look under their welcome-mat for a spare key, and then it would take me, say, 15sec to open the door once I tried it after picking the key up once I found it. (Ideally, the welcome-mat wouldn't just appear in the hallway's contents list, perhaps just in the description of the room, or perhaps not atall.)
Maybe it would be cool to have an action-result-list for special stuff that isn't included in the normal commands... like @set door(actionlist)=kick/kick down/kick in/shoulder/ram... then, the result would be rendered as programmed, maybe a broadcast message to everyone who's in the building that someone's making a lot of noise in the hallway, followed by a success- or failure-message, and then allowing passage into the room. An InRooms-application of this might be something like @set mouth.uvula(actionlist)=tug/pull/touch/hold, and then the result being the victim gets vomited back out onto the ground, or perhaps bitten or swallowed or something. I'm not sure how much of this functionality exists already, but I'm curious as to how hard some of this would be to implement, because elements like these would make the MUCK much more MUCKy.
Also, I wanted to know if normal items can be eaten at this point... like if Dino drops his poptarts, could I eat them before he got a chance to notice?
Thanks. |
|
Something more important than Patch's sentiments: SAVE the goddamned INTERNET! |
|
|
|
|
Forum Guru
Group: Forum Members Active: 2/3/2007 Posts: 39 |
|
Yes, yes! I'll add that to the list. That WAS something I was thinking of doing.
Although originally, I was going to just ask new users (or all users after the first update), if they are macro, micro, or normal, and then, have a flag for size-checking.
The problem with size conversions, as great as they would be, is not figuring out in, ft, cm, m, mi, etc, but figuring out what somebody means when they either misspell a unit of measurement, use one that wasn't programmed in yet, or use none at all - I've seen a few people that just have raw numbers in their size.
I could have it default to meters. But then, what when someone has one of those absolutely huge units they know about that I don't, and thus weren't programmed in? I can keep adding them, but until I do, people will have the frustration of their size not being converted right.
Also, locks to items already exist! All you do is, when you're @locking the exit, use an item name or dbref instead of a player. You can & and ! these together, too. For instance: '@lock door=Key&me' would only allow you and anyone who has the object Key (the nearest one with that name, or the lock won't set if it doesn't find one) to enter the room.
It can also read MPI. You can set a lock like this: '@lock up={if:{equals:{prop:_flight?},yes}}', so that only people with the property _flight? set to "yes" could enter.
And, currently, inrooms will NOT grab objects. The current inrooms code has a check that basically goes like this:
if victim is not a player, return error message.
That was to prevent exits and rooms being moved, because both of those don't make sense and could be harmful to the MUCK. Soon, the code will look more like:
if victim is a player or object, then if victim has the Allow flag set or is owned by the grabber, then move the victim otherwise, print the fail message, and then otherwise, return an error that the victim's type can't be moved.
EDIT: Oh yes, and the other suggestion of yours I missed. ^_^
I've thought about making the actionlist activator a global program. Like a 'do', 'perform', or something like that command, where you could cause yourself (or your belongings) to run through an actionlist. It's something to think about.
It's something to think about before I implement it in inrooms, even, because I don't want to have two versions of the same code floating around, that's wasteful.
If I do decide to make actionlists standalone, I'll let you know. There'll be a command to access them, there'll be MPI, and there'll be MUF prims. It'll be a library and then some. ^_^ So other programs will be able to use it to control actionlists as well, including just activating actionlists by dbref (which, depending on the permissions-level the program is running at, could belong to anybody).
This way, after I write the actionlists program, I'll just use the MUF macros I create in inrooms. ^_^
Re-EDIT: Yes, since the actionlists code is actually fairly easy, I'm going to finish that before I finish inrooms, so you'll have actionlists first. That'll also let me see how people use them, and how well people take to them. When it's implemented I'll let everybody know. It'll then have the command, MPI, and MUF macros as promised. Those will be documented in #help.
|
|
|
|
|
Forum Guru
Group: Forum Members Active: 2/3/2007 Posts: 39 |
|
Ok, update on how actionlists will work.
There will be a single base command, al;alist;actions;actionlist, that will serve as the actionlist creator.
When you want to create a new actionlist, here are the commands:
al #create ActionName=Delay.Action;Delay.Action[=RunningObject]
This creates a new actionlist, on the player by default, but optionally a different object can be included to run the list on. Delay is in tenths of a second, so putting 10 in delay will wait for a second before causing that action.
Then, simply type your ActionName to run the actionlist!
You can remove an actionlist with al #delete ActionName. You can change an actionlist's values with: al #change ActionName [StartValue]=NewDelay.NewAction;NewDelay.NewAction[=NewObject] Where StartValue is the Item in the list to start the change at, either in the form of a number, or a search string (by Action, not Delay). That will be the first Action changed, the next one will be the one after, and so on. You can also optionally change the object it's being set to. You can change *just* the object by typing: al #change ActionName==NewObject
You can also see a list of your actionlist actions with al #list.
MPI can run actionlists with the {run:} command. The format is the same as above; {runelay.Action;Delay.Action[=Object]}.
MUF can run actionlists with a 'run' command as well:
"Delay.Action;Delay.Action[=Object]" run
In all cases, the default object an actionlist will be run on (if none is specified) is the triggered object, or otherwise the thing on which the actionlist trigger exists.
For created actionlists, this defaults to the player or object that used the al #create command. For MPI, this is whatever the MPI is on. For MUF, it's whatever called the program the run command is used in, whether it be an exit, a program, or anything with more MPI in a prop.
If you specify the object, you must either own it, be a wizard, the exit must be wizbitted, or the MPI property blessed. If any of these conditions are true, you will be allowed to run actionlists on an object.
Actionlists can run actionlists, as long as the inner actionlist that will be run is within the reach/permissions of the user.
For instance, you can create an actionlist where one of the commands is another actionlist action, or the MPI command with the {run:} MPI function. You can even use the MPI command from the MPI or MUF run.
This will now save programmers from the absence of a 'parsempi' MUF prim in Fuzzball. Perhaps 'parsempi' will be defined as ( d s -- ) "0.MPI " swap strcat swap intostr "#" swap strcat "=" swap strcat run , or something. The only thing it can't do is tell the program what the result was; but it can still be used to run MPI in strings passed directly to a program.
And finally, an actionlist can be made-up on the spot just by using the run format with the 'al' command: al Delay.Action;Delay.Action[=Object]
It will always do permissions and locality checking, and tell you if you aren't allowed to do that, or the object couldn't be found.
Also note that using dbrefs instead of names for the object will always find it no matter where it is, so if you use a dbref you can control an object remotely, as long as you have the right permissions.
There's one final permissions check that can influence your ability to control an object: The public flag/reflist.
To allow anyone to use actionlists on an object, type al #public Object
To allow anyone to run an actionlist, type al #public ActionName or al #public Object=Property
And to allow individual players, objects, exits, rooms, or program to use actionlists on an object, type al #controls Object=thing&thing&thing&thing
You can also use !thing to remove something from the list.
To allow individual things to use an actionlist, type al #controls ActionName=thing&thing or al #controls Object=Property=thing&thing&thing
And the ! operator can be used on these as well.
Finally, to allow everyone to use any of your actionlists, type al #public all
And to allow everyone to use actionlists on any of your objects (except you), type al #controls all
To undo these, just put the ! operator before the 'all'.
This way, anyone can allow others to use their actionlists, or use actionlists on their objects, as a whole or individually.
Note that when you allow someone to use one of your actionlists, it will operate on the object it's set to (or its default), with your permissions. So be very careful what actionlists you allow others to use, and be careful not to allow everything to use actionlists on YOU! This will effectively allow anyone to force you to do whatever they want!
This is left in there in the event that somebody wants this. I know some people want a slave program, this effectively gives it to them. But I'm declaring right now that it's not my responsibility what you do with my program! If you open yourself up to be forced at whim by anyone's actionlists, I warned you!
I'll still of course accept bug reports, but only if they're real bugs. This isn't a bug. ^_^ Only if it becomes a REAL problem will I change it, and that requires a Wizard being taken over and crashing the MUCK, or some disaster like that. So wizards, don't set this up as a slave program on yourself AS A RULE. If you want to be able to be forced to say and pose, make those actionlists and make THOSE public, not yourself!
And, last but not least, to review any of these commands, in a list or in detail, type al #help. That'll give you a list of topics, and you can then type al #help Topic to read that topic.
That pretty much sums up actionlists, and suggestions are welcome for this as well as for inrooms. Note that neither programs are up yet (older inrooms is, but these features aren't implemented yet).
So, what does everybody think of this? I'm programming this as I write this post, and the post actually helped me solidify how I was going to make it work. So it's already almost done, and will be up soon! I have the program triggering right, I've tested MUF and MPI prim functionality, I just have to finish writing the call test (exit, MPI, or MUF), and then create and execute the force array, and then add the menu options. Sounds like a lot, but I'm actually more than halfway through. Menus are easy with the advent of the select-case defines. ^_^
Also, technically, this program itself doesn't quite make the muck more MUCKly - it makes it more MUSHly. ^_^ I've experimented with a MUSH server, and I would have stuck with it were it not horribly out of date with other MUCK servers.
MUSHes have the ability to string actions together by semicolons by default. Their entire command interface is called MUSHcode, they have nothing like MPI or MUF.
But MUSHcode (just commands) could be used straight up, or set in properties. Any properties. There may have been some special signifier when a string was to be executed as commands in a property, but other than that, that was it.
So for instance, you could @create the command eat, and @succ it to something like 'tell Arg1="You get eaten by Akisame!";otell here=Arg1 "gets eaten by Akisame!";teleport Arg1=#1234' and then there you go, basic inrooms. It was wonderful.
Except it was missing so much that MUCK servers have, that just couldn't be reproduced with the limited commands it had, even if they COULD be strung together.
So this is still a wonderful, open, free, and *very customizable* MUCK, but it'll be a little more like a MUSH once it has actionlists.
|
|
|
|
|
Forum Moderator
Group: Forum Members Active: 4/16/2008 Posts: 737 |
|
I was going to comment on that suggestions but the comic somehow got in the way... So i'll just say, it's a bascical issue. Faibanx is a MUCK, and one with wonderfully mature (in more than one way) and open-minded players. Things are more about roleplay than about fancy commands for everything, and i dont think trying to force everything (that can still just be said in a pose no matter how much you prevent the global command from working in that case) into a program code is a good idea. As for the size thing, there is no way for the MUCK to know who can due to whatever abilities eat (hug/stomp/mount/ several hundered other commands) whom, and if you are afraid of someone eating someone else unasked or without the victim's wixxx at least clearly hinting he likes that, you are thinking of the wrong thing anyway. In a place where sizes admittedly span quite a mindboggling range, size can not hope to be 100% accurate to the actions anyway, let alone the rooms, it all relies on the palyers' sanity. And besides, we even HAVE a size setting, plus command that shows all. I've been to places that have nothing like that, and get you comments on how rude you are when you look at someone to get an idea of his/her/its size.
And everything else that you mentioned if perfectly doable already. Just keep in mind it's a MUCK, not an adventure game. While there are indeed areas that work that way, noone wants to @create every tiny object of everyday life just so someone can interact with through code rather than by just posing it.
------------------------------- Blue anthroraptor, Iconeer Resident anthrosaur
(Linking the Faibanx muck map here hoping that helps google find it properly: http://download.lavadomefive.com/members/blue/map/main.html ) |
|
|
|
|
Forum Guru
Group: Forum Members Active: 2/3/2007 Posts: 39 |
|
Yes, yes I know, Blue. ^_^
But, lots of MUCKs have more advanced programs to do more advanced things. This program doesn't force you to use it, and you have complete control over what about you can be forced and what can't.
So, for anyone that still wants to use *just* poses and says? They can do that just fine! But, if people *want* an actionlists program, it's there. If people *want* actual force-based slavery, whether limited or complete, it's there!
It's not going to ruin the MUCK. New features won't ruin anything unless they FORCE you to use them. Say we implememted a real stat system, that everyone had, and you could always be attacked and there were always people using magic and stuff...THAT would change it, and make it no longer what it is. But this? This isn't required at all. The MUCK can continue running as it always has, with all the openness it always has, and yet there's one more way to 'embed' your roleplay desires in the MUCK more, making it slightly more realistic in the middle of roleplay than just pretending the stuff's happening.
And it's all optional.
Also, I'm thinking more and more, even though I'm not gonna remove the ability to 'al #public me', I'm going to put up a warning with it, and I perhaps might not allow wizards to use it.
Or perhaps I won't allow somebody to force others to do things they couldn't do themselves, and only NOT check for ownership. So you could force a wizard, but you couldn't force them to change somebody else's properties, @toad people, or @shutdown the MUCK. That way wizards could get the '#public me' openness if they wanted, without compromizing the system. They'd still have to be careful about their own settings that way, though, of course. For instance, I wouldn't do that, because it would allow someone to edit my programs and change inrooms' or actionlist's code.
Security aside (and I'm certainly interested in maintaining security), this doesn't ruin our (and your, sometimes it seems) precious MUCK. It's ok. It's just an option. ^_^
P.S. - No one wanting to use the program can force someone else to use it, either. If you aren't set up to use the program, you don't have to. If you aren't set up to be controlled in any way, you won't be able to be. If someone pesters you, well, you can ignore them, or at least politely tell them you're not interested.
|
|
|
|
|
Forum Moderator
Group: Forum Members Active: 4/16/2008 Posts: 737 |
|
|
|
|
|
Forum Guru
Group: Forum Members Active: 2/3/2007 Posts: 39 |
|
Yes, and it works like this.
@set me=X @flock me=The list of people who can force me.
So, for instance, it *is* possible to @flock me=!me
And then you'd be the only one unable to force yourself, theoretically, and everyone else would be able to force you.
But then we have that security issue. So what if you just want to be able to be forced to say and pose? Well, then you need something like actionlists.
I suppose, then, that the ability to 'al #public me' is repeat, but the rest of it is entirely unique.
So alright. There'll be TWO ways wizards can potentially open themselves up to being exploited to do damage, one of which already existed. But I've already pretty much decided I'm going to remove the ability for wizards to do an 'al #public me', after all, they can still do anything else.
They could even do this:
al #create forceme=0.MPI {force:this,{&arg}}=me al #public forceme
Which would be effectively the same thing. But it takes a lot more effort, and someone would have to be TRYING to open themselves up to do that.
So yes. @force exists and has for a long time. The ONE thing I'm putting a restriction on, that I hope @force has too: If the @forcing player isn't a wizard and is trying to @force a wizard, regardless of the wizard's @flock settings, they can't do it. I HOPE that's the case.
|
|
|
|
|
Supreme Being
Group: Forum Members Active: 3/22/2011 Posts: 152 |
|
Okay, so as I was reading your technical detail of the al-commands it occurred to me to ask whether al-prompts are possible for when actions are being executed, and, if so, how would I implement one?
Say there's a generic Big Red Button© that's hidden behind a wall-painting in a hallway. If a user does a "move painting" and then gets the message "When you take the painting off of the wall, there's a huge red button in a recess behind it, will you press it?" could I then give them a (perhaps timed?) chance to give a "yes" or "no" or "neither" and then create a response accordingly? It would be a little bit hefty to have the action then enable another action called "response" (or something) and then execute from there, especially if they might be carrying on a conversation and saying "yes" "no" and "neither" already while speaking. Can the current code send people into a submenu and then process the response(s)?
Also, another thing that struck me was that having another player's action to you (the player) being answered by a script might be a necessary extension to the al-functionality you already described; Blue's right when he says that it shouldn't necessarily be up to the program who can do which actions (and to whom), so it would be good to leave it up to the players, e.g.: a player enters "stomp Patch" and then a script attatched to me sends them into a labelled submenu: "are you a biped?" A "yes" would allow their action to be completed as dialed but a "no" would leave them with a "well guess what? You can't!"
For security reasons there would totally be a necessity to have a mandatory consequentless exit for all such submenu-initializations that would be attached to all scripts like this by the MUCK's code. This would prevent infinite loops that could keep players logged in, or other stuff of that ilk. So, if I needed to do something else or was tired of playing somewhere I could not only "neither" in the submenu about the red button, but I could just type "xx" or something, and then be able to come back to it later, without having a whole bunch of stuff trying to keep happening when I actually wanted to go. EDIT(1): Just thought of something else that I wanted to ask about; can running als search for certain phrases in certain rooms, in addition to actions? So if someone, say, in my pocket said "Vendi vidi vechi" could it place them into the exterior room (the one where I am) and then, say, shrink me (change my size flag to a given value), followed by checking if the player had a pocket themselves, and then if yes, putting me into it?
I know that's kind of a permissions-nightmare, but stuff like that would be super-amazing. |
Something more important than Patch's sentiments: SAVE the goddamned INTERNET! |
|
|
|
|
Forum Guru
Group: Forum Members Active: 2/3/2007 Posts: 39 |
|
Ok.
Well, right now, I'm writing it with MUF and MPI support so even if I *didn't* put the inrooms-dodge type of functionality into actionlists, it could be created.
As for your concern for being trapped in an infinite loop, currently actionlists doesn't trap the user in a read, but instead triggers off of one action and then proceeds to force a series of others. So even while actionlists is running, the user can do other things.
The idea of the *inrooms* dodge command is that it wouldn't trap the user in a read either, but instead have an event-based system. When the 'grab' action is initiated, if RP returns true to a 'victim AND (grabber OR inroom)', then instead of immediately moving the victim, the PID (process-ID) of the current copy of inrooms running will be put in a prop on the victim. Using the 'dodge' action (built in to inrooms) will send a message to the PID (using a separate copy of inrooms that runs quickly then terminates) telling it to exit the dodge attempt with the fail messages. Otherwise, when the program's dodge timer runs out, the victim is moved with all the success and drop messages displayed.
So, this could be added to actionlists. That would make even the dodge action of inrooms probably refer to actionlists instead of being hard-coded into inrooms. And the user would NEVER be caught in an infinite loop. Even if there's some sort of looping added to actionlists (or if, for instance, the last action in an actionlist is to call the actionlist again), their ability to act normally won't be hindered.
That ability to make a loop within actionlists though IS a good security point, however. Even if they weren't hindered, if they were being forced to say "Hello!" every five seconds to eternity, that would be kind of annoying. So, I'll ammend my security checking a bit with the following rules:
1) Actionlists can only be run on a PLAYER if that player is connected. When a player disconnects, any actionlists running on them cease. 2) An actionlist may not run in a loop. If an actionlist calls a different actionlist that calls the first actionlist, either the command will fail with an error, or the last call (that would create the loop) will fail silently, I haven't decided yet.
As far as adding such 'dodge' prompts to actionlists or not, I haven't decided yet. The 'dodge' command will be available for inrooms, as well as the rp 'escape', and the 'out' exit will always, regardless of RP settings, get out of the current inroom. There are flags to allow yourself to be grabbed overall, locks to deny certain players, objects, or inrooms, and of course the RP flag.
Actionlists ALSO has flags and locks. The default behavior of actionlists on a person or their things is always to only let that person use them. You have to explicitly set #public or #controls on an object or actionlist to allow anyone else to use it. So the player DOES have control over who can/can't use their actionlists.
MUF that I write can technically take this away from them if it's written that way, because I typically set my programs Wizard, Mucker-level 3, and Setuid (behave with program's permissions, not user's). However, actionlists may not be set 'S', but then I'd have to make accomodations for 'force'. I'll probably still set it 'S' but put any force commands inside a try-catch block (which does what it's supposed to if the try succeeds, but if the program would normally return an error here, it does something else instead. This way I don't have to string parse what's being forced to make sure somebody isn't forcing a Wizard to do something they shouldn't be able to).
So yes. Users do have control, with both inrooms and actionlists. If, after these are uploaded, anyone finds any security bugs, REPORT THEM! Thank you for your current help, by the way! I'm glad I posted this topic the way it did, because your suggestions have been great, and both of you (Patch and Blue) have had good questions and concerns that I can certainly understand. ^_^
|
|
|
|