[CF-Devel] Questions to developers

[Michael Toennies]

First, i had to agree with mark in most points.

I had dropped a little less on information about what i do,
thats because i had not enough time in the last 2 weeks and i had done alot
of changes.

But please let me explain what i had done in the past.

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.

In the first case, you will not notice any changes. All the new client code
is capsuled and changes
to other functions will not effect anything. Why then including them? Well,
in hard words: I need to
test it works. The core functions are working for all clients types, only
the result will old ones not
submited (they have no interface to handle it). This is the only way to be
really sure all is fine.
We have no other way to test things. Of course, i had tested the code before
its not buggy, but this
then is the "beta test". Note, that virtually all changes to CVS from all
developer works so, thats
why CVS is CVS and not the stable version.

In the way i worked me through the server code, i noticed 2 things:
The core idea of how the CF animation system should work was screwed in the
past.
And the attack/move code was also buggy. The use of the arch commands SLEEP,
UNAGGRESSIVE, STAND_STILL
and the way you push one was not right. This effected also the work of other
arch commands.

I talked about this with Mark and i start to fix it. This was some more work
as i expected, because
the one bug in the code hides the other bug in the code and so on.

For example was it possible to push a friendly NPC. In the push code was
only handled the unaggressive
flag. So, if you create a char with FRIENDLY 1 and UNAGRESSIVE 1 and you
push him - he starts attacking you!
A NPC with FRIENDLY 1 / UNAGGRESSIVE 0 not... so, i must reworking the push
code too.

STAND_STILL was also screwed... if there was no enemy, random_moves and some
attack moves was included
before it. Because this, people start to insert a SLEEP 1 in the code...
this really stops the suckers
until they attack - of course the whole sleep code (which was for my opinion
included in the past right)
was so screwed too - now we haded 2 kinds of "stand_still" commands inside
the code, no real sleep code
and both are not working right - i fixed this too but still there are many
monsters with SLEEP 1 in the
arch. If you see a SLEEP 1 in the monster arch, remove it. It should not be
there. Sleeping is a
kind of "action", like running or firing - not a attribute.

This kind of commands should be inserted on map script level, not on arch
level.
Because sleep was (and still is) meaningless, stealth and hiding skills also
not works like expected.
This should be reworked later.

In the way i included new features in the ISO client, i had included a new
fantastic animation system.
Monster who attacks you now facing you. They follow your moves and instead
of turning back when step a
aside or go a tile back, they strive sidewards or go backwards. Also, when
they run away, they truly
turn back. Also, i had included move, fight and "do nothing" sequenzes. When
you move, your char starts
moving animation, when you fight he slashes with his sword... i will explain
the anim system when i had
included it on full level. Let me say, that it is a "lazy system". Means you
don't need 100% action
synchronisation and you don't need 100 animation steps from each monster.

Well, as i test the new system, i noticed that some monsters start doing
strange things - thrown of fired
objects drops to there feets and they start to attack himself - punshing
herself dead.

The reason was 2 bugs in the enemy/firing code. First, because firing
objects was true objects they was
not synchronized with his owner - it was possible that a fast monster shot
an arrow and still has moving
points left. So , he start to move on - and run in his own arrow!
Now, the 2nd bug starts: Because the monster hits himself, it was marked as
enemy - well and so it starts
to kill herself.

I was forced to changed booth. A monster now can't be hurt from own missiles
anymore - but this has a side
effect. Reflected missiles for example SHOULD hurt his owner. Mark and i had
not find the last conclusion
about it, so this is unfinished. Perhaps we simply change the owner of a
missile to the one who has reflected the missile?

Well, i changed also that a monster can't attack himself.

Next bug was, when i looked in the friendly monster thing. There is a list
of "friendly objects".
In the original code i think, this list was for player and his pets. This
was all "friendly" ones.
The rest was the stuff which attacks this. Friendly NPC comes later and they
was added in the list
too, but in fact they was in all other ways handled like normal monsters.

Problem was, that a monster don't attack a monster. This must be - or all
monsters start to attack
each other, because a single fireball from one monster will hurt all others
too and so you can stay
back and watch the monsters killing all themself.

Second problem: Original friendly monsters only attack the enemy of the
player. Means this single monster
which is the signed target of a player (which means was attacked & hurt from
a player). Well, but often
friendly monsters was attacked from other monsters, so they die without
doing anything.

You will noticed this often: a guard for example stands there and do
nothing. Or they got killed without
doing something.

I included now a "you got attacked " mechanism. If a monster attacks
something, it marks himself as attacker
inside the object. The object then looks for an enemy, and if there is no
one, it looks for a possible
attacker. If there is one, it decide to attack it back (or not).

In this way, NPCs now have a real life. If they got attacked, they attack
back.
You can for example now create a guarded entry. Put some guards there and a
orc generator somewhere.
The generated orcs will start attack the friendly guards and they will
attack back.

Oh well, and i removed a bug which invoke monsters not to cast spells to
enemies stand right next to them.

Hm, in this works, there was alot of "small" changes i don't had write down.
Most a tricky things
like "this flag must checked before this action and this flags" and so on.
Alot of this.

Another thing i changed some time before (original for testing but it works
fine so i let it in),
was that you can now include a object in the OTHER_ARCH part of a door. When
now the door gets
destroyed or opened, this new object gets inserted on the same spot. This
allows to create open/close
doors. This should be worked out: open/close door and broken door (in the
iso arch i had this kind
of pictures).

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%.

Also, many of the arch commands are simply work arounds for the missing
object type system. Like
IS_MONSTER for example. When you don't set things, you must explain things
and this do this kind
of commands.

I will explain the new animation system when its ready. Let me say that it
will remove also a hack, which
cuts the animation system in a player and a monster system. You ever wonder
why some monster do crazy
animation things? Go in scorn in the mercenary house (next to reagence shop)
and look to the monsters.
The one which turn around and around is a screwed animation (a monster which
use a animation from
a player arch). Some ninjas and so on are doing the same. Problem is, that
player anims use a different
animation system as the monster one. The monster system comes in the current
state from mark and its
the same new system use (only a bit boosted). I will use the same system for
player arch too, so we
can reinclude the doppelganger race (they was removed because they grap the
player anim and this will
not work yet).


>
     
      First, the question people following the standard programming practices
     
     >
     
      seem to be failing.  MT is probably the biggest offender, but not the only
     
     >
     
      one.  To me, the core principals that should be followed are:
     
     >
     
     
     >
     
      1) Discussion of proposed changes.  Now, if you just fixing a bug
     
     >
     
      or making
     
     >
     
      a minor change, this isn't really necessary.  Definition of minor change
     
     >
     
      is obviously vague.  But if your change includes changes/additions
     
     >
     
      to the client/server protocol, how objects works, or will be more than
     
     >
     
      a few hundred lines, a note about what you plan to do should be sent to
     
     >
     
      the mailing list.  I've seen many commits done where my impression is
     
     >
     
      'that is a really stupid way of doing that', but I'm not goint to spend
     
     >
     
      my time fixing it or getting in a lengthy discussion to the author on what
     
     >
     
      the proper way would have been (since they've done the code, they don't
     
     >
     
      really feel like going back and fixing it themself)
     
     >
     
     
     >
     
      2) Documentation. Most new things should get documented - this is
     
     >
     
      especially true with changes to object structures or changes to the
     
     >
     
      protocol.  If we don't follow this, documentation gets hopelessly behind
     
     >
     
      and/or someone else needs to figure it out later (which tends to be much
     
     >
     
      more difficult because that later person has no real idea how it was
     
     >
     
      done.)
     
     >
     
     
     >
     
      3) Writing clean code.  Code written should not generate any warnings when
     
     >
     
      compiled with gcc -Wall.  This is mostly just simple things - removing
     
     >
     
      unused variables, making sure functions that are not void actual have
     
     >
     
      return values, proper commenting, etc.  C Code should also conform to the
     
     >
     
      ANSI C & Posix specs (this last point may be a bit iffier in some areas
     
     >
     
      as code written specifically for one platform but with proper #ifdefs for
     
     >
     
      other platforms may not really need to meet that).
     
     >
     
     
     >
     
       Now I am soliciting the developers opinions on how important these three
     
     >
     
      aspects are.  All have upsides and downsides which I won't bother going
     
     >
     
      into.  My main point here is to see if the developers at large are willing
     
     >
     
      and able to abide by these and if not, for you to present alternatives.
     
     >
     
      Note that whatever in the end is agreed upon would become unilateral for
     
     >
     
      all developers - if 80% (for example) agree that those are the guidelines
     
     >
     
      that should be followed, that remaining 20% who did not agree can't ignore
     
     >
     
      them - they must follow them or else.
     
     >
     
     
     >
     
     
     >
     
      Second MT's latest commit comment below:
     
     >
     
      ++
     
     >
     
      Include mapstats cmd for extended clients (sdl iso). Cmd is needed for
     
     >
     
      automaps ambient media infos, map name and map parameter infos.
     
     >
     
      Paramter infos
     
     >
     
      are used for "fire & forget" animation tags inside the map2 cmd
     
     >
     
      (next patch).
     
     >
     
      server/main.c: include a automatic mapstats cmd every time the
     
     >
     
      player enters a
     
     >
     
      new map. Its the "default" mapenter cmd. The script event should used for
     
     >
     
      special cases.
     
     >
     
      ++
     
     >
     
     
     >
     
       Note the main thing that patch does is send the size of the map
     
     >
     
      the player
     
     >
     
      is on, the name of the map, as well as exactly where the player
     
     >
     
      is on that map.
     
     >
     
     
     >
     
       There have been past discussions and issues about how much information
     
     >
     
      we give to the clients about various aspects of server known details.  In
     
     >
     
      the past, it was decided that the client should not know about map size
     
     >
     
      or where the player is on the map.  But we should really decide this once
     
     >
     
      and for all.  Note that this will make playing easier (you will
     
     >
     
      know exactly
     
     >
     
      where pits and teleporters dropped you for example).
     
     >
     
     
     >
     
       Like most things, there are plusses and minuses to this informatin.
     
     >
     
      The plus is things like automap or fog of war or whatever else will work
     
     >
     
      better.  The minus is that it may be much easier for players to navigate
     
     >
     
      themselves around maps that use teleporters and pits (some maps transport
     
     >
     
      you such that you need to find your way out - if you know where
     
     >
     
      the exit is
     
     >
     
      from where you are now, that becomes much easier.)
     
     
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.

I really agree to marks position. It should not possible to cheat. Like the
player see things
he should not see. Or player gets information he should not get.

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.

The drawback mark is fearing (and i have seen this in real in Ultima Online
where they faced same
problems) is that you can grap from stored information the true position
from exits or other
valuable locations.

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.

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!!
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.

If the client try to avoid to drop the cache, it will fast screwed up.

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.

I had not explained it yet, because i have not tested it out - i just wrote
on the new map2 cmd.
But as it looks it really works like expected.

Your comments?