[CF-Devel] DM - God Finger - bleah!

Mon May 31 04:15:47 CDT 2004

>

     >

        In terms of privacy issues, hard to say.

     >

     >

        One can make the case that if you were a police officer and had to tell

     >

      someone if they were under surveillance, you'd never actually catch them doing

     >

      anything (or they are really stupid criminals).

     >

     >

        One can make the same case for crossfire - if there is a report of abuse, the

     >

      DM may want to check it out, and not notify the player involved.  Because if the

     >

      player suddenly got a notice 'you are under surveillance', of course that player

     >

      is going to stop doing whatever abusive actions.

I too mentioned this, and said it would be fair telling the player that
(s)he was being observed - after "the case is closed".
On the other hand, CF is (yet?) a small community, I can hardly imagine
"corrupt" bad DMs who override their commissions. I hope it'll never happen,
and I think we can say we don't have to worry about this.
But it could be a good stance - let's not forget, children play CF as
well, it's not irrelevant what we show them there. And what's fair - it's
fair, no matter it's in the game or in reality.
Besides, surveillance methods which tell players that they are being
snooped would be more _efficient_ than one would think! As I said, CF has
a small community, and if the message was not only 'you are under
surveillance' but 'X is under surveillance by Y' would be much better,
cause other players would know the fact that a certain player is
suspicous. It could be some kind of a warning for X. If X was under surv.
for several times, peepo would know he's a problematic guy. Kinda
more "democratic" too.

>

        I personally find it hard to envision what one would do in crossfire that is

     >

      so secretive.  I could see things like private messages perhaps - even to the

     >

      extent of things like 'says', if a couple players on by themselves on a map and

     >

      are thinking of having a private conversation.

Personally I find it hard too. BUT, as for one reason - one that's not to
be neglected - peepo hate to know they can be observed anytime. And _this_
fact they _really_ should know. (I mean - the fact that they _can_ be
under surveillance anytime, without a warning.)
How would it look like in the MOTD: "On this server you may be observed
secretely by a DM anytime." And don't tell me anybody it wouldn't be fair!
And for example there may be peepo who could seem to be "crazy" for a
usual observer. (Like having strange habits. For example moving in a
circle in his apt in every 15 min, etc. If I were such a player I
wouldn't like the thought some DM could see me while doing such things,
maybe laughing at me and telling his/her friends...)

>

        As far as a 'snoop' for the dm - to see what the player sees without being

     >

      there, this probably isn't that hard to do.  Add something a field to the

     >

      player/socket, and when a dm starts to snoop, that is set to point to the player

     >

      he is snooping on.  Then when it comes time to render the map, it uses the data

     >

      for the snooped player, and not the one the dm is currently on.

     >

     >

        One could extend this a bit of course - include things like the commands the

     >

      player enters, so you could see if they are invoking spells and what not.

     >

      Because as I think about it, trying to discern/filter messages is very difficult

     >

      - by the time new_draw_info() gets the message, and that is the obvious place to

     >

      send a copy to the dm, there isn't really any context about the message itself,

     >

      other than color.  So you could perhaps say 'if the color is ..., don't send to

     >

      snooping dm'. (aside, one of the things on the TODO list is to change the passed

     >

      in values to be context and not color).

     >

     >

        Now going back to the original issue - DM's not being able to see invisible -

     >

      that is actually much more difficult to fix.

     >

     >

        That is because each square is generated once, and every player that can see

     >

      it, sees the same thing.  If you notice for example, see invisible is actually

     >

      an area of effect spell (makes invisible things visible for everyone), and not a

     >

      personal spell such that only the caster can see the invisible objects.

     >

     >

        So to make that work for the DM, the map code would have to get redone - now

     >

      for each and every space, you'd have to figure out what the dm sees special.

     >

     >

        This perhaps get easier if we limit see invisible of dm's to only see

     >

      invisible players, which may be what is really desired.  That is a bit simpler

     >

      (can fairly quickly cycle through all the players, see if any are invisible, and

     >

      treat that special).

     >

     >

        As far as blocking players - the DM is a living creature, and thus when it

     >

      goes to check if the space is blocked, it sees there is a living creature there,

     >

      and then finds that there is the DM.

     >

     >

        This may be simpler to fix - the update_space() code (or is it

     >

      update_position()) could be modified - if the creature is a player, and has DM

     >

      set, don't set the flags for that space.  However, I'm not 100% if that will fix

     >

      everything - monsters may still be able to 'find' the DM, because they search

     >

      the list of players for nearby players (as a shortcut of searching all the

     >

      spaces).  That could certainly get changed to skip DM's, etc, but there might be

     >

      lots of bits like that.

     >

     >

        So if the goal is really to be able to spy on players, adding a spy/snoop

     >

      command is probably the way to go.

     >

     >

     >

      _______________________________________________

     >

      crossfire-devel mailing list

     >

      crossfire-devel at lists.real-time.com

     >

      https://mailman.real-time.com/mailman/listinfo/crossfire-devel

     >

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

     https://mailman.real-time.com/mailman/listinfo/crossfire-devel