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

Re: CF: client woes! and mroe

Mark Wedel (mark@siemens-pyramid.com) wrote:

> > a) filename handling needs to be #ifdef-ed
> 
>  And filename/directory names are hard coded to be seperated by / in many
> places.  Don't know if that would cause a problem.

Hm... I was thinking about (pseudo-) operating systems that are using
the notion of "drives", so absolute filenames don't start with /. But
now that you mention it, the / itself is a problem as well :-(

> > b) some maps assume case-sensitive filenames
> 
>  I don't think this would be a problem - I don't think there are any maps which
> have the same name but with different capitilzation.

There is at least one map which is available as Tower1 and tower1.
Don't know the exact path --- it's the place where the necromancer is.
Should be easy to fix, though :-)

> > However, who knows what Unix-dependencies lurk inside...
> 
>  I would think the socket stuff could be a problem (should be posix I guess).
>  There is also the need for timing at least to the millisecond.  Beyond that,
> there is nothing really strange about the code which I would expect it to
> break.

Well, technically one would have to #ifdef the command line parsing:
some OSes have their own commandline parser, which should be used
(although argc/argv is ISO-C... depends on how well the server should
adhere to system-style-guides). Well, debateable details...

>  As for mac/pc support, Phil Brown did a java port.  Probably a little out of
> date now.  I have just now sent him mail inquiring him on its availability in
> source form.

Well, it would be much better if someone did a native client.
But then, until someone find the time/resources, maybe people with
highend machines can live with a Java client.

Christian


-- 
Christian Stieber        http://www.informatik.tu-muenchen.de/~stieber
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]
References: