 |
 |
 |
 |
|
 |
 |
|
 |
 |
|
 |
 |
| Author |
Message |
Marilla
Joined: 02 Feb 2006 Posts: 329
|
Posted: Thu Nov 16, 2006 8:25 am Post subject: |
|
|
or
#3: ban staff that give out information they shouldn't be giving out perhaps, don't give them the ability to see invisible items in the first place. If you can't trust them to see one type of invisible object, what all other invisible objects should they probably not be able to see? Or... should they really be a staff member in the first place.
For instance, though we don't have any 'low level' staff on our shard at all, I would definitely recommend shards that do have something like 'counselors' certainly not give those staff the ability to see invisible items or players, at all. I would even do like OSI did, and not even give THEM the ability to be invisible.
It kinda goes back to my Basic POL Security post, though I did not mention this type of thing specifically: Always give people the absolute least privileges possible. If someone has a need to be able to locate a certain, specific type of item, then give them that, specific ability, alone; perhaps via a dot-command that shows them the items, and maybe sends them an appropriate packet to let them see the item, even if it otherwise would be invisible (see the 'Memory' and 'Hallucination' packages posted on the custom scripts forum for info on how to use the packets that send info to a client on 'seeing' an item - though those scripts use it to show you something that's not there, you could just as easily use that code to send someone packets showing them something that IS there, only otherwise invisible) |
|
 |
|
|
 |
 |
|
 |
 |
| Author |
Message |
Marilla
Joined: 02 Feb 2006 Posts: 329
|
Posted: Fri Nov 17, 2006 9:34 am Post subject: |
|
|
| Yukiko wrote: | | It was just a thought that might help folks to avoid problems in the future with, say a GM, who "looked" good for a while and decided to go South on an Admin and cause trouble... See the idea is that even GMs can go nasty. |
I think what you are trying to do here is look for a complex technical solution to what is an age-old problem: one of human trust. Just ask a bank, a spy agency or any other place that has secure information: All the security in the world is completely meaningless if you have trusted individuals who break that trust. 'Legendary' computer hackers will all tell you the same thing: They didn't break in because of some obscure computer flaw. They broke in because people were given trust and access who should never have had it.
I should mention, though; I kinda like the idea of a .concealed member on items, myself. For one thing, I would use it to conceal stuff even to ME - just things that really, really, really, under no circumstances, do not need to be seen at all, ever. (like dungeon teleporters)
But beyond that, I would not use it for anything more. In fact, I don't even use .concealed for hiding from my GMs... because I trust them all, completely. We use it only to hide from players, which is not a 'trust' issue at all, really, but is a game-play issue (it wouldn't do to have the GM be visible while pulling the virtual strings of quest/role play stuff, and hidden/stealth does not allow the GM to move around freely).
If I ever had a GM who I felt for a moment I would want to 'spy' on, I would remove them as a GM, on the spot. In over 5 years, I've never once had a problem such as that with a GM - but then again, the criteria by which I select GMs probably have a whole lot to do with that.
I just think that to the extent that GMs "need" to have visibility for all invisible items, across the board... well; if you can't trust someone with that, you should not make them a GM. And, if they don't need visibility on ALL invisible items, then absent this sort of feature, just provide custom ways for them to interface with the items.
And then finally, is one more point: You may want to consider if using an 'item' is really the best way to handle an issue, in the first place. Sometimes people use a real, physical item in game when in reality, a global or even local property would be a much better option. Though I know that most custom rare ores systems were made to use items like this, I'm not at all sure that was a good idea at all.
Err... but anyway; all that said - I think that you, personally, might be barking up the wrong tree for your issue. However, I do like the idea. |
|
 |
|
|
 |
 |
|
 |
 |
| Author |
Message |
Marilla
Joined: 02 Feb 2006 Posts: 329
|
Posted: Sat Nov 18, 2006 2:29 pm Post subject: |
|
|
Something like that could work, with a couple possible extras;
First, I would give all such items a Control script that checks to see if they have been 'concealed' via the CProp, and returns them to the 'concealed' graphic. This way they would not be inadvertently revealed permanently by the shard shutting down while they are visible.
Next, be sure you don't have any commands that enumerate and display items in the area and, if you do, be sure such commands specifically exclude items that should not be displayed to the person in question. For instance, I have a command on my shard that specifically lists/displays the items that are within a certain radius of the command user. If I were to want to exclude people from seeing certain types of objects at all, I would have to be sure that script checks and leaves such items out.
Finally, though; Note that this solution still results in the item's info being sent to the client. The client simply does not have anything to display for the info being sent. However, it could be easy for someone familiar with the appropriate things to capture the packets being sent by the server, and analyze them to find the instances of the items in question. So this is not something you can do to truly hide an item from a packet-savvy user; only from casual, visual inspection. Oh, on a side note, such an option also isn't helpful for reducing 'lag' of lots of 'hidden' items, because again; the items are still sent, but the client just doesn't have anything to display for them.
However, it's a pretty good option to just hide some 'invisible' items for convenience sake, even when you are a GM and decide to be able to see invis items! |
|
 |
|
|
 |
 |
|
 |
 |
|
 |
 |
|
 |
 |
|
 |
 |
|
 |
 |
| Author |
Message |
Marilla
Joined: 02 Feb 2006 Posts: 329
|
Posted: Wed Nov 22, 2006 9:44 am Post subject: |
|
|
| Yukiko wrote: | I'm sorry Marilla. I wasn't pointing fingers at you only. You aren't the only one I was thinking of but I admit you were on my mind more prominently when I made that post. I admit I didn't see where you posted your like for the idea. I had skipped ahead to Maud's post and after reading it I figured it was a moot issue and I didn't read anything else.So I hope you will accept my apology.
Anyway, I will read more carefully in the future, hopefully. |
Apology accepted. Now if you'll accept mine. I am honestly only trying to help, and my first instinct is almost always, "Is there a way to do this already?" and that's where I'll go, more often than not. I also try to ask, "Is there a different root cause to the issue that's inspiring the request?"; If I get yes answers in my own head to both, I just go with that. I almost never put even a moment's thought into how the things I'm saying might be coming across. Though I'm certainly not trying to come across negatively, and I am trying to help (not just help get a possible feature implemented, but help someone figure out how to do what they need to do, even if the feature can not be done), I probably have at least as much need to more carefully word what I say as you do to read what I might say.  |
|
 |
|
|
 |
 |
|