Would it be possible to give items the concealed member like mobiles have?

This would allow shard Developers/Admins to conceal certain things from lower level staff members . For example on a shard that uses items to mark ore veins the script could set the ore vein markers to be viewable only by admins and above. Thus preventing less trusted staff to be able to see, and tell their friends etc., the locations of "uber ores". This has other applications but that one was the first to come to mind.

#1 : Leave their color and name plain, don't mark by name.
#2 : In the usescript, make it check cmdlevel.

That works for items that are "used" but that doesn't keep "passive" items from being seen by lower ranks of command.

No worries. It was just a thought. Guess it's not an easy addition to make.

Thanks anyway.

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)

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. It was just one more of those possible security enhancements to POL.

See the idea is that even GMs can go nasty. I'm not talking Councillors or Seers here who don't necessarily need to see invisible items/players. GMs need to be able to see invisible objects but Admins etc can conceal themselves to a level where they are not visinle to lower ranks and since POL allows concealed to be a ranked member on mobiles, I thought it might not be too hard (or a bad idea either) to add it to items as well. My thoughts were if you gave items a concealed member then one could rank which items should be concealed at a higher level, ie. more secure level. After all why have any command ranking at all if not for security reasons. Why not have two player levels, player and staff? Someone must have seen the need for higher levels of trust in POL.

It seems like a fairly straightforward thing to move the concealed member up to UObject in the object tree so that all children inherit it but then again I don't know how the POL source is coded. Like I said if it's too difficult a thing to add, no worries.

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.

If it is not possible via core you can also script something like e.g.
.setitemconcealed [level]
.showitemconcealed [short/old]

The first one could contain something like:



The second one could search items in a specific radius and shows them only for a short time (changing a few seconds to the old graphic than back to 1) or forever again by changing to its old graphic if your concealed level is >= the setting made with the first command.

The disadvantage is, you also don't see these items unless you make them visible again. But you can "scan your world for them" easily.

I think you know what i mean. We have something similar but not for trust reasons, cause all GMs can use it. But if i would put the "concealedlevel" CProp in, it would be exacly what you need if i understood you right.

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!

it is possible but would increase data in a huge way (for some items only using this feature)

Shinigami

Aye Shini. Exactly why when I added uc_lang to characters, I made it to NOT be saved to data file. It's sent every logon, so no need to save it

As for anyone saying "Why not do this with concealed for items?" Not needed, cuz then increases ram use for something very easily scripted.

I agree Maud it would increase RAM storage. By the way, that's a good reason not to do it. I can accept that answer. What irritates me is when something is dismissed out of hand simply because they don't like/see a need for something.

So I am satisfied with your answer.

I did consider something similar to Pierce's suggestion and am doing that in lieu of having concealed on items.

Thanks to the developers. Keep up the good work.

Hmm.. I seem to remember saying:



But then trying to discuss other ways to do it, or get around the need to do it.

Don't worry. I won't bother getting in your way again by trying to help you with any ideas. Wouldn't wanna get in the way of your tunnel-vision when asking for new features.

And now, I'm reminded why I was one of Austin's #2's for so long... I sure seemed to have more time to devote to my own shard, when I didn't bother trying to help others.

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.

Thank you Marilla.

Because I do value your help. I have used, or will use when I get to them, some of your ideas in scripting. So keep on offering suggestions please.

Oh and I still wish I could conceal items.
*grins*