> Feel free to request any document you feel is missing. As I can't document > everything at once, I think the easiest thing is that you ask what you need > or think it will be most usefull. Do you have any format your prefer ? Would > you like doxygen documentation or do you prefer text files in doc/ or would > you like things on the wiki. I don't feel very comforable with the wiki right > now as it is much more difficult to add a user there than on savannah... does > anyone knows if there is a mod or something for pmwiki that makes it more > conveniant? If not, should we change our wiki engine?
If we're moving servers (still no response from icculus.org, by the way), how about we let the people hosting us decide on the type of Wiki? It would be one less demand we're putting on them. > As you have probably all noticed, my salvage proposal put a big emphasis on > changing the network model. This is because it is the only part I really > don't know enough to fix/extend/modify. Furthermore, it is very complex > because of this NAT/firewall problem. The NAT/firewall issue shouldn't add much complexity to a well implemented protocol stack. I'd be quite interested in tackling this problem. I've posted some thoughts on how the top level of the network API might look - I wrote it last night, but it's not turned up until just now, hence it not responding to your points. > Third, our current network model is > really difficult to manage: the synchronization requirement is indeed very > demanding (for instance, it prevents the use of float or double, because > their behaviours is not the same on different computers). I noticed this when I was writing the iostream implementation. I thought about using XDR (http://www.faqs.org/rfcs/rfc1014.html), but decided against it as I don't know how well it's supported on different platforms. If it's important that we be able to transfer floats, I can rewrite the binary iostream code to use XDR - one of the nice things about the iostream implementation is that doing so would be completely transparent outside of the iostream code itself :) The only other big synchronisation requirement I'm aware of is the need for clients to agree on the random number generator they use, which seems to be going OK (I was able to understand it without documentation, and have cleaned it up a bit too). > This said, I've the feeling you do not want too big changes, which is very > reasonable. Nevertheless, do you have any suggestion on what to do with this > network problem ? Actually, I'm very keen on changing the network code, because I think it's important that the orders be put in the sections of the program they relate to (e.g. building orders in Building.h) so that people who want to work on discrete sections of the code can do so. It's just that I'm not convinced that a client/server model would help - for every problem it fixes, it seems to create an additional one. Actually, I found the synchronisation method quite a refreshing way of dealing with the problems of lag and lack of a powerful central server. As with much of the Glob2 codebase, the theories are excellent, it's just the implementation that needs work. > Andrew, what is the state of maprewrite_branch ? If it is mostly usable, I'm > ready to merge it to HEAD and continue the development and the required > rewrites in HEAD. I agree that we need to clean things and that's ok for me > to break map format, if we do a very clean and easily extendable format this > time :-) It's far from usable I'm afraid. I've been rewriting things to use the new I/O framework (which has allowed me to get rid of at least 3 different parsers), and will need to thoroughly test them all. I've also been playing with the order code, to come up with the ideas in my other post. As I've said above, I'd be happy to do a complete rewrite of the network code - although it would put the date of any release back even further, I think it'd be worth it to have a codebase that newcomers can pick up and work with. I think it's better that we look at the map rewrite as a branch for long-term changes, and let people that want to fiddle with ideas on a working system use the HEAD branch. That said, I'm quite happy for others to work on the map-rewrite branch, although I'll probably need to improve my CVS etiquette if they do. - Andrew _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
