Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Misc notes/thoughts.



From: mwedel@pyramid.com (Mark Wedel)

>  First, as with the recent discussion of conversion to c++, I just gave
> a quick try, and the main issue looks like it will be the naming of 
> elements/structures that conflict with c++ (ie, class and protected are the
> ones it immediately died on.)

If the goal of the c++ version is that it will replace the current
version then it really needs a major work.  I think that it's not worth
to make all changes only to able to compile it C++ compiler.  And the
current code assumes Ansi C, not C++ so there are probably some
incompabilities.  If it's a just separate work, then I think it can
be a nice challange, but the code is probably outdated when conversion
is done.

>  Second:  Dm mode.  How many people actually use this?  I looked into this
> after receiving a bug report, and noticed that the security for it is really
> quite dismal.

Yes, I wondered why the password was removed and changed to a name check. 
Generally I would like that dm would be like other players and using 
the player name and password. Of course there is a problem how to make
those dm chacacters in a first place.

> Any reason not to just go back to a global password for dm access?  

No, but I prefer the above method.

> Or should dm protection be improved (also include authorized 
> hosts/displays to become dm from.

Not before the true client/server.

>  Or may add passwords in addition to just names - at
> least it would be 2 things that need to be guessed.)

No, the name is too easy to find out (identd/email-address etc).

> The other is, is there really any reason to restrict dm access from sockets?

Probably not, but the client/server mode should offer the same security 
anyway.

>  Third:  Message output.  A few days ago, I think I said I would probably
> come up with something that would do paging.  But what someone just mentioned
> made a lot of sense - add a scrollbar.  

The both makes sense, but is it worth start coding scrollbar code since
all toolkits would offer one? The general paging routine would be useful
on the client side.

> Originally, it was my opinion
> that this is somethign that is better suited for the client (actually,
> it is still my opinion, but the client is going anyplace right now.)

Of course it not going anywhere if all changes are made server and not a 
client :(.

>  Any suggestions/thoughts on this?

I would say that forget all code on server side, which clearly belongs
to client.

And from Raphael.Quinet@eed.ericsson.se writes about sounds:

[ Ideas removed ]

I think that sounds don't need any special archetypes, but just build-in
support in objects like faces are now.  Only meaning for lib/sounds file
should be make mapping between game sounds and actual sound files (like
bmaps do now with the images).

> It would be much easier to write and to maintain the new sounds code 
> if CrossFire was really split between a client and a server, like this 
> was discussed some time ago.  Will this ever be done?

Why everyone thinks that the current client is not enough to work with?
Yes, it's still incompleted, but offers enough features to work with.

I have compiled the current server without any X libraries, but it requires
much more that just commenting out xio.c :).  Generally I used #ifdef's  
to comment out code that was something to do user interface and in some
cases I used the new client/server function instead of the old one. 
The new function calls the old one if X support is compiled in and used.
This makes code little more clear, at least.

I try to make some changes to get better item handling in the protocol
and send changes to Mark before Christmas (or otherwise changes are kept
in my machine so long that new version comes out and  no one is interested
patches to the old version ;)

The true advantage comes when client side animations are implemented, but
this requires more work.  Basically all animated archetypes needs to be
updated and all support programs.  Also this kind of changes are very
hard to make to keep compability to the old scheme.  it probably requires
rewriting some of the basic code on server side.

  -Tero