Crossfire has *serious* problems ahead...

[tchize]

I have *finanally* got the x11 client to draw (inefficiently) maps which contain large images...

The function gtk_draw_map() is an example of one of *many* 'timebombs', that *will* go bang in the end!

I think this (current/cvs) comment sums up the foreseable future of cf devel:

/*After long long long investigations on why the multipart objects did
disappear when entering map view from right or bottom, scrolling
through whole server code, i concluded the following line should be
commented. If a multipart object was on a square outside of map,
containing the tail, tail may be cleared by following process and
so we end up with things like tower disappearance.
tchize@myrealbox.com*/

Notice the words: "long long long...", if things carry on this way, then more, and more, and more, time will be *wasted* on stuff like this, leaving less, and less, and less, time for actually adding things to cf!!!

Baaaka!

I reworked the gtk_draw_map() to handle the smoothing code a while ago. This was not easy since i had to take care of multipart objects, heads, tails, smoothinglevels and the 3 layers of pictures used to draw. The way to draw things are clearly documented in Developper doc (not in source code, since this would make very long comments). But it took time since it is simply some algorithmic problem, not because of documentation problems. Some behaviours related to smoothing code still need to be documented but they are quite well understandable from the doc i wrote for GFXers. Unlike what you say, there is beta testing. But it's not easy to think about every problems and test them. I know there has been problems with smoothing code which laid to crash in some configuration (image cache related prolems) and which have been fixed.

Now, why did it take a long long time to fix? Quite simple, i made the algorithmic error. But, i don't know why, i was thinking this was a server related problem. So i check the map1cmd for server, looked at it from all points of view, and the saw that the problem was simply the concerned line in client (sic). I wrote the comment late at night, feeling a lot stupid not to have noticed the error before and most important not willing anyone for strange reason to uncomment my line (this has been seen in the past, 2 developper doing exactly the same mistake by writting exactly the same erroneous line of code).

If you think algorithmic errors are always easy to spot, shame on you. I think i have enough experience to say some errors are not easy to spot, especially in a multi developpers envirronement.

Ok you might also ask why we don't submit, for example, the patch on the mailing list so it can be beta tested before CVS submitting. I don't do this for a simple reason. When i submitted patches for feedback and beta testing i got some suggestion, worries, and notices from people who didn't even open the patch to look at the content. So i stopped submitting patches, except for really important changes.

Now, please, could you stop using comment from joking developpers as political arguments. Doing this only proves you have no knowing of other developpers background. Most of developpement discussions take place on irc channel (faster than mailing list) where we say stupid things along with, sometime, interresting things. But i never saw a "juk" on irc channel. I don't blame you for that but don't blame me for sparing time to develop a game i like and who, am sure, is far more stable than some commercial 'released' games.

[Eriwal]

Ok, this will sound evil to many of the open source coders who believe that "Portability is everything"....but perhaps trying to make all the clients as portable as possible is not such a good idea. If the clients were written using the basic GNU principles of "do a job and do it right" they might be both easier to code and easier to maintain.

By this I mean -- if you want an Win32 client, write a Win32 client using Win32 native GUI/GDI libs (networking, graphics, IO, everything). Don't try writing a Windows client that uses a dodgy mix of "generic" libraries. And if you want a good X11 client, write a good client that uses X11 specifics and don't worry about trying to make it portable to Windows and Macintosh.

Of course, this would mean totally different client code bases, but the people maintaining them would have a much easier time doing it. Not having to constantly code things to work on multiple platforms would make it much easier to debug and code a particular client well.

In the end, the players don't care if the client is elgantly coded for portability, they just want a client that doesn't crash every time they enter a new area (yes, the Windows GTK client does that to me a *lot*!).

[Eriwal]

I forgot to add ... I don't mind coding a new Windows client using just Windows specifics. If there are docs for the client-server network protocols I don't think it would be a problem. The only major obstacle is whether people really insist on portable clients....I don't have any Unix or Linux systems and don't want to install one. So I'm not big on trying to code a portable client when I can't compile and test the portability myself.


I have another multiplayer game of my own that I was writing but making the maps, NPCs and items was just taking too much time. Here's a webpage which has some sample images of the client in editor-mode...the pics can at least show some of my Windows coding:
www.geocities.com/wombling_wombat2/dangband.htm

[tchize]

The fact the windows gtk client has lots of problem does not come from the 'code for portability' behaviour of coding. In fact, the fact there is a partially maintained windows client come from this kind of coding. The gtk client was never coded (in the beginning) to be compiled under windows. It comes from a modification of the cfclient, which is a pure, but a bit ugly now athena client.

It has never been asked to client developpers to write portable client. All was aked is to take care when modifying in CVS the mainstream client (gtk/athena clients). In the past there has been several windows client written from scrap which were using the windows API and not some portable libraries. (I think about the delphi written client, which was my first game connection and the direct X client). Unfortunately, those clients are not maintained anymore and their respective developpers never released the code under GPL so we can't maintain them.

So why didn't anyone in the crossfire developpers write a GPL windows client after that? Simply because i think, most of us are using linux or BSD as main developpement OS.
Now you want to write a windows client? Glad to hear about it. You will be the third pure windows client and i hope you could maintain it and get helped by putting it under GPL. Now for the doc on how to access the server, the *famous* protocol. The complete description of protocol is available in the file "doc/Developers/protocol" of the crossfire server source code. It is well explained, and up to date (i think this is the most important point for Mark Wedel, as i saw last time i added functionnalities to the protocol). You are not forced to implement all functions of protocol (some of them are used only by old servers/ old clients but shouldn't be used in recent server with recent clients transactions as explained in the doc) and i think, if you put client under gpl, the common part of current unix client could be a good starting point. Apart from socket handling, most functions are portable and don't use any library, simply they are some algorithms to communicate with server.

[Lauwenmark]

I have a couple of comments to make about this. Sorry if I'm too long for the laziest ones

Ok, this will sound evil to many of the open source coders who believe that "Portability is everything"...

It doesn't sound evil. Sometimes portability is an important factor, sometimes it isn't. It is a commonly accepted idea that portability is a good thing - but there are cases where its benefits are outweighted by the increased complexity it generates.

...but perhaps trying to make all the clients as portable as possible is not such a good idea. If the clients were written using the basic GNU principles of "do a job and do it right" they might be both easier to code and easier to maintain.

You're attempting to mix portability (which is mostly a programming question) with morale principles, something I find quite inappropriate. Does portability prevent a code to do its job (and to do it right) ? Of course not. On the other hand, poor design does - but that's *another* question.

As for saying that separate code bases would be easier to manage than an unified one, I don't see how. We would end up with several sources, each being known by only a couple coders - maybe only one in some cases. And what happens when this last coder leaves ? The others are screwed with a code they know nothing about.

By this I mean -- if you want an Win32 client, write a Win32 client using Win32 native GUI/GDI libs (networking, graphics, IO, everything).

Don't you think rewriting everything would be a great loss of resources ? Note that I'm not thinking about the visual side of the client, but about the logical side: communication handling, for example.

Don't try writing a Windows client that uses a dodgy mix of "generic" libraries. And if you want a good X11 client, write a good client that uses X11 specifics and don't worry about trying to make it portable to Windows and Macintosh.

You seem to forget the way Crossfire evolved. At first, it was a *nix-only application. Win32 support came up much later. As a result, most CF coders were *nix ones, not Windows ones.

A first client attempt came - but we never got a hand on the sources and the author disappeared in the Wild. A second one was long maintained (the DirectX client still in use today) but as it was closed source, we have no opportunity to maintain it anymore.

Given the limited programming resources we have (especially under Windows), we couldn't afford to create and maintain a brand new client; we couldn't have done it in a reasonable amount of time.

Of course, this would mean totally different client code bases, but the people maintaining them would have a much easier time doing it. Not having to constantly code things to work on multiple platforms would make it much easier to debug and code a particular client well.

But on the other hand, any change in the client-server communications has to be recoded several times. Independent teams also require enough programmers for each major platform - something we do not have.

In the end, the players don't care if the client is elgantly coded for portability, they just want a client that doesn't crash every time they enter a new area (yes, the Windows GTK client does that to me a *lot*!).

Without proper return from gamers, you cannot expect the devel team to be able to dig out bugs 'by magical means'. How often I heard people complaining about 'this or that doesn't work', but didn't report the problem on the list ? How many users actually take five minutes of their precious time to write to the team or to ask on IRC ?

I forgot to add ... I don't mind coding a new Windows client using just Windows specifics.

More power to you. You're free to do so if you want. But then don't complain if the GTK client is unstable - you are a Win32 coder, so you would have the possibility to help improving that. I hope readers will have noticed that like I did.

If there are docs for the client-server network protocols I don't think it would be a problem.

So you didn't even read the development docs ? Good to hear that you got your ideas about the GTK client problems without even understanding how it was working. Again, I hope I'm not the only one to have noticed that.

The only major obstacle is whether people really insist on portable clients....I don't have any Unix or Linux systems and don't want to install one. So I'm not big on trying to code a portable client when I can't compile and test the portability myself.

Crossfire is a team project, not a single-person thing. That makes a strong difference between my views and yours I'd say.

I have another multiplayer game of my own that I was writing but making the maps, NPCs and items was just taking too much time. Here's a webpage which has some sample images of the client in editor-mode...the pics can at least show some of my Windows coding:

Being a good coder isn't sufficient I'd say. You also need to be able to team-work and, yes, it means you cannot always do what you want the way you want.

I'm tired of those political discussions. You want to make a client ? Do it. You want to debug the existing one ? You're welcome. But never forget that critiques are easier to provide than solutions. And so far, you only provided the first kind.

[Eriwal]

The fact the windows gtk client has lots of problem does not come from the 'code for portability' behaviour of coding.

Well, from my view the errors I see in the shell say that the problem is being caused because of the GTK lib. Specifically the library isn't handling simple device context memory copies (looks like copying back the screen context to memory).

Since this is caused by the use of a 'portable' library I'd regard it as a 'code for portability' problem. If the coder had used normal Win32 API calls it wouldn't have DC copy errors every 5 minutes or so (this isn't an exaggeration either).

It has never been asked to client developpers to write portable client.

I stand corrected on this point then. My understanding had been that people wanted only the GTK or SDL client worked on (according to the replies I had in another thread). I had thought that this was because they were portable.

My mistake...I understand now that they meant those client simply because they were the only existing ones that needed maintaining

So why didn't anyone in the crossfire developpers write a GPL windows client after that? Simply because i think, most of us are using linux or BSD as main developpement OS.

Yes, I think that's pretty much the case. I originally played CF at university on a Solaris system, and I've never seen anyone I know use CF from Windows.

Since CF is primarily a Unix game I can understand that it's very difficult to attract Windows programmers who want to work on it.

Now you want to write a windows client? Glad to hear about it. You will be the third pure windows client and i hope you could maintain it and get helped by putting it under GPL.

If I wrote a client it would be under GPL. There wouldn't be any point in keeping the source code private. Writing still depends on getting a Windows server running though, and the binary Ryo sent me still won't run for some reason.

Now for the doc on how to access the server, the *famous* protocol. The complete description of protocol is available in the file "doc/Developers/protocol" of the crossfire server source code.

I've been reading over it today, looks pretty complete.

(Edit: Just rewrote the 'qoute' codes into 'quote', so your text appears as expected)

[tchize]

The fact the windows gtk client has lots of problem does not come from the 'code for portability' behaviour of coding.

Well, from my view the errors I see in the shell say that the problem is being caused because of the GTK lib. Specifically the library isn't handling simple device context memory copies (looks like copying back the screen context to memory).

Since this is caused by the use of a 'portable' library I'd regard it as a 'code for portability' problem. If the coder had used normal Win32 API calls it wouldn't have DC copy errors every 5 minutes or so (this isn't an exaggeration either).

How do you use a win32 API under linux? Those errors, technically, comes not for the 'code for portability' but from the fact someone, one day, decided to compile the gtk under windows, a realm where gtkclient wasn't suppposed to stand. If you want us to stop coding for portability this would mean your client will not crash anymore, since there won't be anymore client.

[qoute="tchize"]It has never been asked to client developpers to write portable client.

quote! It's quote, not qoute

(Edit: Just rewrote the 'qoute' codes into 'quote', so your text appears as expected)

you may thanks the moderators

Since CF is primarily a Unix game I can understand that it's very difficult to attract Windows programmers who want to work on it.

Well most windows programmers i know personnaly live in a world where coding in GPL is something they don't want to do. Take a lambda windows programmer around you and ask him how much code he did release under GPL (not freeware). But that's beyond the scope of this thread.

If I wrote a client it would be under GPL. There wouldn't be any point in keeping the source code private. Writing still depends on getting a Windows server running though, and the binary Ryo sent me still won't run for some reason.

Strange indeed. But you may connect your client to existing server. They are not meaned to crash when client is wrong. Am not sure running the client locally will help you detect your protocol problems.

[Lauwenmark]

[qoute="tchize"]It has never been asked to client developpers to write portable client.

quote! It's quote, not qoute

(Edit: Just rewrote the 'qoute' codes into 'quote', so your text appears as expected)

you may thanks the moderators

Never use such rude terms against me again (that's the 'thanks' part I'm talking about).

[Avion]

Well, from my view the errors I see in the shell say that the problem is being caused because of the GTK lib. Specifically the library isn't handling simple device context memory copies (looks like copying back the screen context to memory).

Since this is caused by the use of a 'portable' library I'd regard it as a 'code for portability' problem. If the coder had used normal Win32 API calls it wouldn't have DC copy errors every 5 minutes or so (this isn't an exaggeration either).

Do all other gtk applications running on windows display this behaviour? I doubt that. Is your distrust of GTK based in fact? Then I would say it isn't the libraries exactly but how they are being used in this case - something probably fixable with time. I am afraid that no amount of winking, quoting and clever emotes can make up for a few well placed factual statements. Also if the coder had used normal Win32 API calls then you would be seeing a heck of a lot of worse errors when the client was run on other operating systems .

My understanding had been that people wanted only the GTK or SDL client worked on (according to the replies I had in another thread). I had thought that this was because they were portable.

My mistake...I understand now that they meant those client simply because they were the only existing ones that needed maintaining

No mistake, I meant because they were portable. I think that most reasonable people do want a portable client using libraries that are platform agnostic. Both GTK and SDL are portable libraries and work has already been done on these. I think that it would be better to have people work together than on seperate clients. All the other clients were windows clients (Java, DX, win32) and they are all now defunct.
I don't say this because the client programmers are lost little lambs in the unix world hoping some real developers will come save their software and run it on a real OS (baaah baaah please saaaave us) - it is just more sensible to write a client that can be easily ported to all platforms possible. This is not an impossibility or even highly difficult any more. There are people who are working on this (a thankless job in many cases). I thought you would want to get in touch with them - my mistake.

Actually, enough on this subject as it accomplishes nothing- as you cannot lead a developer to water... If you wish to build a new client that's great - however come back here in a year and we will see what maintained clients there are available for the game.

[Guest]

Those errors, technically, comes not for the 'code for portability' but from the fact someone, one day, decided to compile the gtk under windows, a realm where gtkclient wasn't suppposed to stand. If you want us to stop coding for portability this would mean your client will not crash anymore, since there won't be anymore client.

This is a bit contradictory...you just said that the GTK client wasn't written for portability. But then said the only reason there is a Windows client is because the GTK client was written to be portable (ie, saying "If you want us to stop coding for portability" means that the GTK client WAS code for portability).

And if you stop coding for portability there wouldn't be a client?
That's wrong because there was a DirectX client that apparently worked until the server upgraded. Unfortunately it can't be maintained since the sources weren't released. But I'm pretty sure it's no accident that the one working Windows client happened to be done in non-portable, Windows specific code.

(Edit: Just rewrote the 'qoute' codes into 'quote', so your text appears as expected)

you may thanks the moderators

Thanks moderators

Strange indeed. But you may connect your client to existing server. They are not meaned to crash when client is wrong. Am not sure running the client locally will help you detect your protocol problems.

A localhost server is useful for faster testing. It takes me ages to do stuff on the metal-forge server, even walking across maps is slow. Plus I'd want to edit my character to help with testing.