[CF-Devel] Questions to developers

Fri Dec 7 00:41:12 CST 2001

Michael Toennies wrote:
>

     >

      I had inserted in the server code alot of new code.

     >

      This was 2 kinds of code: New stuff for the iso client (or better: a new

     >

      generation of clients)

     >

      and true fixes or changes.

 While this code may not effect other things directly, it has the problem of
adding new commands to the protocol which must be supported at some level (I
think you would rightly be upset if none of the clients I use use that extended
protocol commands so I remove it/don't support it).  So for better of worse,
these changes must stick around for quite a while, unless you are willing to say
that anyone is free to remove those enhancements whenever they feel, and thus
break your client.  Simply put, any code, no matter how much its used or
exercised, implies some level of support (bug fixes, making sure it compiles,
possible modification if something it depends on changes, etc).

 While I don't have any specific problems with these new commands, I have
problems with the process of just putting them in.  This is because you put in
something that matches your needs for right now.  Suppose that someone else
wanted other information included in the protocol command.  With such quick
implementation, it is now difficult to do (changing the protocol command to
include that may result in breaking your client).  So what happens is they then
write a new protocol command, perhaps with know prior discussion.  Then perhaps
you take that again, add yet some other piece, and add yet some other protocol
command.  Pretty quickly, you get a lot of commands that all send the same thing
(say map or item data) which all must be supported.  If discussion was properly
done, then perhaps that first protocol enhancement would have been enough
because the other person would have provided his input, and it would have been
done completely correct the first time around.

 Note for the most part, I don't have any issues with most of the
changes/enchancements you made.  But that is not the point of this discussion. 
In addition, I do have serious problems with some of the changes you did make. 
There is of course no way for you (or anyone else) to know how someone will feel
about a change unless it is discussed.

 The point of this discussion is if that is the way we want crossfire
developed.  I'd much rather have things discussed (and thus done properly the
first time), then something get committed and then removed because it was the
wrong way to do it. 

Snipeed:
>

      i will explain the anim system when i had included it on full level. 

 To me, this is completely the wrong approach.  This should be explained before
it is done so other people can comment on the proposal.  Your code should
certainly be tested before it is committed.  But before such changes are
committed, otherwise you take the potential risk of your code getting rejected
(removed) after you check it in.  I already plan to do that on your subtype and
player sex code because of the poor way (IMO) they were done.

>

      I had start to include a subtype system. This is "in work". Sadly, we don't

     >

      come to a conclusion about

     >

      this in the past. Fact is, that the current system is a bad, bad hack which

     >

      not really works and

     >

      violated the whole arch/map system we have (clients have a hard coded list

     >

      of items which they parse

     >

      for every item on the item name - create a new item for a map or create

     >

      generic ones and every client

     >

      is automatically outdated). This is the reason why the "player doll" sytem

     >

      of the dx client not works

     >

      and will not work 100%.

 And this is something that should be discussed.  They way you started it is not
acceptable IMO.  While I agree that the current system is broken, this is just
not something that should go off and get done quickly, for the following
reasons:

1) A method should be done that matches what other people may find useful (for
example, garbled was doing some work for weapon types and might perhaps extend
that to weapons against specific types of armor).  It would be stupid to make a
method that does not include those other needs.

2) Such a change will require an enhancement to the protocol - thus a new item
command.  This should be on the list simply so others can suggest other
information they might want included if the command is getting updated.

3) this changes will necessitate a change to the object structure.  What this
element is called is very relevant, as calling it subtype will conflict with
real subtypes, as what you are doing here is really a 'client_object_type'.

>

     >

      I have your opinion about the fixed map positions in mind Mark. :)

     >

      But i have solved it. In fact, i will send the fixed position direct to the

     >

      map2 cmd,

     >

      remove the mapscroll cmd and let do it the client.

     >

     >

      The problem is the one you decribed: Without any information about the map,

     >

      the client

     >

      can't do things like buffering or fog of war or automapping.

 Current unix client does fog of war just fine without know about map size, so
that comment is false.  Note that the way the unix client does it is actually
better because it works properly with tiled maps.

>

      But giving NO map postion and size information to the client will remove

     >

      about half a dozen features

     >

      i want see in the client. And the biggest one is to let do the animation

     >

      effects. Don't let start

     >

      now how this works - set it as a fact that it is in all cases good to

     >

      delegate much as work to

     >

      the client as its possible.

 Matter of debate.  Certainly something that should be discussed.  Just because
you want something in the client does not mean it should be there.  I could see
lots of things different people would want in clients - that does not mean they
should be in the client.

>

      Like this szenario: You step in a room, which look like 3 others. There are

     >

      hidden teleporters in

     >

      the floor, transporting you from one room to the others. You have to find

     >

      your way through this, what

     >

      is hard because all look the same.

     >

     >

      If you now have the true map positions, you can easily track your way down

     >

      by hacking the client.

     >

      Thats the exploit.

     >

     >

      The answer is exactly the mapstats cmd i introduce. :)

     >

     >

      This command will tell the client: Here is a new map. It has the size of

     >

      x,y. Delete the old map buffer,

     >

      allocate a buffer from size x,y and start buffering the data. Mapname is

     >

      <name>.

     >

     >

      Well, all we need is to use this command in the right way. We can force the

     >

      client to throw away the

     >

      stored data so he has no chance to exploit anything.

 How can you 'force' the client to through away the data?  The only way I can
see to do this is if you randomize coordinates and map names.   Sure, the server
could send new mapstats command, but of course the client does not have to throw
away the data it already got.  And this gets very tricky if you want to include
your animation information.

>

     >

      Because: The mapstats commands don't submit the REAL file name - it gives

     >

      the mapname, included from

     >

      mapuser!

     >

     >

      So, easily create a script or improve the teleporters you use so they send a

     >

      new mapstat cmd to the

     >

      client! The client has NO WAY to decide that this is a new or not a new

     >

      map!!

 This IMO is a complicated hack.  Requires all maps that use teleporters to get
updated, to fix a problem that currently does not exist.

>

      Now, its just a task of map makers. If you think about it, its easy to drop

     >

      in all cases you want

     >

      a mapstats cmd, so the client much drop his map cache. If the client try to

     >

      cheat, he runs in heavy

     >

      danger. Just create 2 maps with 4 rooms! Now you jump from one room in the

     >

      other and from one map to

     >

      the other! There is NO WAY for the client to track this down (because the

     >

      client don't get any real

     >

      information about which map gets loaded or not). Every mapstats cmd can be a

     >

      real map change - or not.

 What you are basically proposing is a much more complicated way for map makers
to try to fix a problem you have just introduced which IMO you have yet to
provide good reason for needing to get introduced.  Note also that some exits
types can not go across maps, so that then requires enhancing those (trapdoors
come to mind).  Other ones can be hard to do that - take trapdoors - you may
want those 4 rooms to have controls linked to the others - currently impossible
to do if they are on different maps.

 Note also that the player can always get information on what map he is
currently on.  IT can be argued this information should get removed

>

      If you think it over, you will see that so no exploit is possible. Yes, the

     >

      client has the real

     >

      positions and he can use it (like for DIABLO like automapping which i will

     >

      include in the iso client),

     >

      but the server has 100% control of this use and can force the client to drop

     >

      it.

 You are just making it more difficult.  suppose instead I have my client dump
the information from the mapstats command to a window.  It won't take long on
some maps to figure out exactly how the teleporters lead back to each other.