Re: How to fix the xconq network code

[Jan Jona Javorsek <jan dot javorsek at guest dot arnes dot si>]

> VNC is an interesting option. It is of course already possible to run
> xtconq on non-unix platforms, since free X Servers are available for both
> Windows and MacOS. I have tested running xconq remotely under MicroImages'
> MI/X Server on my G3 Mac. This was actually MI/X running on top of MacOS
> Classic on top of Mac-on-Linux on top of LinuxPPC (where the xconq app was
> running), using the ethertap device for communication between the MacOS and
> Linux interfaces. It may sound complicated, but everything worked fine.

But, being realistic, nothing can beat a dedicated client running right on
the workstation, and any X11 or VNC solution rules out low-bandwidth and
crappy-latency connections.

> I'm less enthusiastic about tcl. There were some good reasons why Stan
> abandoned tcltk and instead went for SDL. First, the tcltk interface is
> rather slow and also has other limitations. Second, it is more difficult to
> debug tcl code. Third, it is not easy to port to other platforms, even if
> tcltk is available. I tried (hard) to get the tcltk version of xconq to run
> under MacOS, but failed. This is in contrast to sdlconq, which I had up and
> running under MacOS after no time at all.

Agree completely. Scripting languages are scripting languages. They are
great, but if you *have* an application in C, why rewrite it? Furthermore,
the very limited developper base could then split up and each could use
one of TCL|Perl|Python|Ruby|Java|C#. A task of rewriting the X11 interface
in awk+php+sed combination is lef as an exercice for the readers.


> The really good news, however, is that we may not have to rewrite the code.
> After some ferocious debugging, I believe I have fixed all the problems
> with the existing network code. I now have the network game running for any
> number of turns without synch errors or lockups. This is with AIs on both
> sides and in non-sequential mode, i.e. the toughest possible conditions.
> There is still some testing and code cleanup to do, but if no serious new
> problems emerge I will check in the code soon, perhaps already next weekend.

That is wanderful! After testing the last available version, I am quite a 
bit optimistic, but this gives me a good day.

Do you think it would be good to add capability to resync unsynced games, 
as a safety net? That could fix any probles due to hairy network problems 
and make it 110% reliable.

Maybe if -host and -join options worked, I could write the master server
and connector clients in some scripting language, and provide te server?
How though would it be to fix -host and -join? (Too hairy code for me.)

Jan