From ksoderbl at niksula.hut.fi Fri Jul 4 12:30:06 2003 From: ksoderbl at niksula.hut.fi (=?ISO-8859-1?Q?Kristian_S=F6derblom?=) Date: Sat Feb 14 14:09:45 2004 Subject: [Xpilot-hacks] Ranking server tutorial and script Message-ID: Hi. I was asked to write something about how to set up an XPilot 4.5.4X ranking server, so I wrote this: http://www.hut.fi/~ksoderbl/xpilot/xpilot-4.5.4X-rankserver.txt Comments? -- kps From darel.cullen at bostream.nu Sun Jul 6 06:57:11 2003 From: darel.cullen at bostream.nu (Darel Cullen) Date: Sat Feb 14 14:09:45 2004 Subject: [Xpilot-hacks] What goes... where is xpilot heading? Message-ID: <000f01c343a4$fc52fae0$7b3ed7d9@bonet> Hi Xpilot hackers, I have question to ask , I appologise for asking it, but perhaps it has to be asked. What is the future for xpilot? Is there a future for xpilot or will it slowly fizzle out. As far as I know there are three branches of development of xpilot today (1) The official Xpilot Activity: http://sourceforge.net/project/stats/index.php?report=months&group_id=14558 seems to have died out around december 2002 (atleast on sourceforge). (2) Buckos Xpilot++ (or is this (1) now) Activity: ? - lots of great work done here (3) U's / Sama's Xpilot 4.5.4X Activty: http://sourceforge.net/projects/xpilot Pretty active currently. Each of the developments have their strengths and weaknesses. Of course it's tough in these times to get the time to do "extra" work on something, and everyone will have their own agendas. I was also wondering how long we can rely on the official meta servers being up and running, as if they were to disappear the network game would pretty much disappear along with them. I think in an Ideal world we would get 2 + 3 -> 1 but I think that development line 2 and 3 are pretty different now. Any kind of unofficial forking has always been seen as bad for the game. Also is anyone willing to integrate work from 2 and 3 into 1. As 2 is c++ and 3 is still c I don't think it's even possible. I know for a fact that (3) have been careful to remain backwardly compatible with (1) and older versions of (1), and I believe (2) have also. The lifeblood of any game are newbie players, and I think recently most newbie players have got to the game through the inclusion of (1) in the official X distribution and in linux distributions. Maybe 4.5.4 is just the nirvana of xpilot and the game will never be as "perfect" as it is now. Although I know alot of bugs in 4.5.4 have been fixed in recent developments. I guess i'm just trying to start a dialogue really, because i've often wondered if things are going to remain stagnant, die slowly as more and more players leave, or some new things will happen. I'm sure i'm not the only one thinking that. I think with currently developments with ADSL and Cable modems, the game is much more even and playable (Xpilot could never really be played on a modem), so if we can update the eye-candy a bit, build a firm foundation, perhaps we can attract some new players. Xpilot has always been the most playable of games :-) I know that Subspace/Contiuum (http://http://www.subspace.net/) (windows xpilot clone) still can get servers with 250 odd people yet in my opinion their game play sucks, and their graphics suck also. What are the opinions of people here with regards: 1) What changes (if any) does xpilot need ? 2) Where should those changes go ? 3) How best to manage those changes ? 4) How to attract more players (if possible) ? Xpilot is of course GPL so its free for everyone to look at , and change as they wish. Personally I think it's always nice to have everyone rowing the same way in the same boat, but I know that that doesn't always happen. Best regards! /CB From kimiko at xpilot.org Sun Jul 6 15:28:09 2003 From: kimiko at xpilot.org (Kimiko Koopman) Date: Sat Feb 14 14:09:45 2004 Subject: [Xpilot-hacks] What goes... where is xpilot heading? In-Reply-To: <000f01c343a4$fc52fae0$7b3ed7d9@bonet> References: <000f01c343a4$fc52fae0$7b3ed7d9@bonet> Message-ID: <20030706182809.GA3769@brokenmoon2.xs4all.nl> On Sunday 6 July 2003, at 11:57, Darel Cullen (darel.cullen@bostream.nu) wrote: > What is the future for xpilot? Is there a future for xpilot or will it slowly >fizzle out. I hope it won't fizzle out. >(1) The official Xpilot >Activity: http://sourceforge.net/project/stats/index.php?report=months&group_id=14558 >seems to have died out around december 2002 (atleast on sourceforge). Actually, I recall that there hadn't been much development for a while then. The last time I worked on it was early 2002. >(2) Buckos Xpilot++ (or is this (1) now) >Activity: ? - lots of great work done here I'm no big fan of C++, so I'd rather see XPilot stick with C. The C++ development was started as an independent project, but it was later decided that this would become the official XPilot version. However, it is nowhere near completion and development on it has ceased since November 2002. >(3) U's / Sama's Xpilot 4.5.4X >Activty: http://sourceforge.net/projects/xpilot Pretty active currently. Some impressive new stuff has been added since Uoti split away from the main branch. I'd like to see this version reintegrated into the main XPilot branch some day. The topic has come up before, but a lot of features weren't working properly back then. It seems to have improved a lot since then however. Kristian S?derblom asked me a while ago how I felt about merging the two versions. I am in favor of that, but I don't want to make that decision. I'm only a developer (although not active for some time now) with CVS access, not one of the maintainers. > I was also wondering how long we can rely on the official meta servers >being up and running, as if they were to disappear the network game would >pretty much disappear along with them. The meta source is not part of the XPilot distribution to avoid having people run metaservers all over the place. If ever both the servers and their sourcecode become accessible, we'll just have to develop new meta code. It shouldn't be too hard to do that since many open source games have meta servers and we could probably borrow their code. > I think in an Ideal world we would get 2 + 3 -> 1 but I think that >development line 2 and 3 are pretty different now. I'd prefer to merge 3 into 1 and ditch 2 myself. >Any kind of unofficial forking has always been seen as bad for the game. It would be better to have people working together, but sometimes there are differences in opinion on how to go about development. IIRC the main reason that Uoti wasn't given CVS access was that his style of development was too 'radical'. It would lead to a CVS version that was either unplayable or seriously lacking some important features for a long time. The preferred style is to develop new stuff separately until it works with most other parts of the code before patching CVS. >Also is anyone willing to integrate work from 2 and 3 into >1. As 2 is c++ and 3 is still c I don't think it's even possible. Integrating 1 and 3 shouldn't be too difficult. I think some things in 3 (I actually haven't looked closely at the code, so I really don't know that much about it) might need some work (http transfer of textures and the ranking code come to mind). As 2 is a duplicate of 1, integrating that code comes down to a) finishing 2 and b) integrating 2 and 3 after replacing 1 with 2. As I said, I'd rather see XPilot stick with C. > I know for a fact that (3) have been careful to remain backwardly >compatible with (1) and older versions of (1), and I believe (2) have >also. I don't think it's a big deal to sacrifice some archaic code if newer code is definitely better (the collision detection code was available in two version for a while). 3 may be backwardly compatible with 1, but does it have all the features of 1 (eg. racing, robots)? > The lifeblood of any game are newbie players, and I think recently >most newbie players have got to the game through the inclusion of (1) >in the official X distribution and in linux distributions. Active developers are just as important to keep a game going as newbies. > Maybe 4.5.4 is just the nirvana of xpilot and the game will never be >as "perfect" as it is now. Nah. It's never perfect enough. There are always things that can be improved and new stuff that can be added. > I guess i'm just trying to start a dialogue really, because i've >often wondered if things are going to remain stagnant, die slowly as >more and more players leave, or some new things will happen. I'm sure >i'm not the only one thinking that. It's funny, I was just thinking the same thing. >so if we can update the eye-candy a bit, build a firm foundation, >perhaps we can attract some new players. UI/eye candy is another aspect of XPilot that could do with some serious improvement. >1) What changes (if any) does xpilot need ? a) integrate new map style b) integrate ranking code properly c) update interface (better game graphics, more online help) d) add new features e) keep on trucking >2) Where should those changes go ? See above. >3) How best to manage those changes ? Have some experienced XPilot hackers maintain the CVS version, with lots of people submitting high-quality patches, bug reports and feature requests (see Freeciv for an example). Unfortunately, we seem to be lacking both maintainers and developers at the moment. >4) How to attract more players (if possible) ? Making XPilot look better may help to get it included more prominently in Linux distributions. Once people see how cool this game is, they will become addicts soon. A better UI will probably get them past their initial shyness. Kimiko From urpala at cc.helsinki.fi Sun Jul 6 19:58:48 2003 From: urpala at cc.helsinki.fi (Uoti A Urpala) Date: Sat Feb 14 14:09:45 2004 Subject: [Xpilot-hacks] What goes... where is xpilot heading? In-Reply-To: <20030706182809.GA3769@brokenmoon2.xs4all.nl> "from Kimiko Koopman at Jul 6, 2003 08:28:09 pm" Message-ID: <200307062258.h66Mwmp18499@sirppi.helsinki.fi> > don't want to make that decision. I'm only a developer (although not > active for some time now) with CVS access, not one of the maintainers. Who exactly are the current maintainers of the official version? Bert and Bucko? (It's hard to tell when no one does any maintaining.) > > I was also wondering how long we can rely on the official meta servers > >being up and running, as if they were to disappear the network game would > >pretty much disappear along with them. > people run metaservers all over the place. If ever both the servers and > their sourcecode become accessible, we'll just have to develop new meta > code. It shouldn't be too hard to do that since many open source games > have meta servers and we could probably borrow their code. I suppose you mean "become inaccessible" above. Replicating the functionality wouldn't be difficult. I believe I could create a working substitute for them in a day based on the server and client code. However, if the domain names couldn't be pointed to the new metaservers quickly that would cause problems, as many players probably wouldn't know how to find the new location. > It would be better to have people working together, but sometimes there > are differences in opinion on how to go about development. IIRC the main > reason that Uoti wasn't given CVS access was that his style of development > was too 'radical'. It would lead to a CVS version that was either > unplayable or seriously lacking some important features for a long time. > The preferred style is to develop new stuff separately until it works > with most other parts of the code before patching CVS. I don't think that is a fair description of my style of development. I think that CVS should be kept usable, and major rewrites should be developed separately until they work "in real use". I think my main disagreement with the maintainers (mainly Bert) was about the value of backwards compatibility. My view was that there were several features in Xpilot that were badly designed and implemented, were not in wide use, and could thus be removed or changed (instead of spending time to keep them working exactly the same way when other parts of the code changed). So maybe you could say that the disagreement was not about whether important features should be kept working, but about whether some existing features were important or insignificant and undesirable. > in two version for a while). 3 may be backwardly compatible with 1, but > does it have all the features of 1 (eg. racing, robots)? Racing has always worked in the polygon code. The only real difference implemented so far is that the amount of checkpoints is unlimited in the new map format. Kps added support for robots when he did the 4.5.4X merge. Support for targets was incomplete IIRC. In the current version even non-poly clients (4.2.0 or later) can join polygon maps; the old-style block map data they get is given to the server separately (so it doesn't necessarily need have anything to do with what the map really looks like). This is useful for maps that have been converted from blocks to polygons. > >so if we can update the eye-candy a bit, build a firm foundation, > >perhaps we can attract some new players. > > UI/eye candy is another aspect of XPilot that could do with some serious > improvement. I think the current polygon map format already allows pretty good-looking maps, especially when the higher frame rate features are used. What we need is someone to design such maps and development of the map editor. From jlmiller at ctitech.com Sun Jul 6 22:33:25 2003 From: jlmiller at ctitech.com (Jarrod Miller) Date: Sat Feb 14 14:09:46 2004 Subject: [Xpilot-hacks] What goes... where is xpilot heading? References: <000f01c343a4$fc52fae0$7b3ed7d9@bonet> Message-ID: <001401c34427$c4c31b40$0200a8c0@TinkTank> Well, I'll take a hack at addressing things here as I see them, since U's already gone from the 4.5.4X side... > As far as I know there are three branches of development of xpilot today > > (1) The official Xpilot > Activity: http://sourceforge.net/project/stats/index.php?report=months&group_id=14558 > seems to have died out around december 2002 (atleast on sourceforge). We need the offical, whatever the final solution is, to end up here, I think that much should be obvious enough. If bert and dick (whom I dont get any replies from anymore) arent interested in maintaining anymore, then it'd be great for them to speak up and say so and maybe see about getting the reigns passed on, if necessary. If they are interested in still being involved here, a nice wave would be appreciated. :-) > > (2) Buckos Xpilot++ (or is this (1) now) > Activity: ? - lots of great work done here I think that a lot of great work here has been done, in fact it could be pretty easily finished up and declared the official for the most part. There a few things that should be finished up more, but as far as I know, everything works as it is now. We stalled out for the most part when it came to upgrading the Client interface to use the same gui (fltk) that we'd done to the rest of it. All the added features are great though, and I think they'd get really great if they were polished up. > > (3) U's / Sama's Xpilot 4.5.4X > Activty: http://sourceforge.net/projects/xpilot Pretty active currently. Really almost all of my complaints about U's work have been addressed by now. I think most of the maintianers' is as well, but I cant speak for Dick and Bert there. There is a need for a mapeditor, and it all has to work on both X and M$. I havent had time to compile 4.5.4X at all lately, but I probably should. I honestly think C++ is the way we need to go, if we want to attract any new developers in the future, and we definately have to be cross platform compatible, which means some kind of gui like fltk or going lower level like SDL, although that's a lot of work. > I think in an Ideal world we would get 2 + 3 -> 1 but I think that development line > 2 and 3 are pretty different now. Any kind of unofficial forking has always been > seen as bad for the game. Also is anyone willing to integrate work from 2 and 3 into > 1. As 2 is c++ and 3 is still c I don't think it's even possible. > The lifeblood of any game are newbie players, and I think recently most newbie > players have got to the game through the inclusion of (1) in the official X distribution > and in linux distributions. Which XPilot has mostly disappeared from, I know for sure from Mandrake, possibly because of the lack of graphical development compared to a lot of the other games coming around. In my OPINION in a perfect world, the best solution would be to merge (2) and (3) into the new Official XPilot, or (4) and just bypass integrating into (1). Just to solve that bit once and for all, and then really hammer in some better graphics/interface/features. We've gone around on this "what's going to be accepted as the next version" thing quite a few times now, and I really think we just need to say FINE HERES WHAT WE'RE GOING TO DO... > I think with currently developments with ADSL and Cable modems, the game > is much more even and playable (Xpilot could never really be played on a modem), > so if we can update the eye-candy a bit, build a firm foundation, perhaps we can > attract some new players. Xpilot has always been the most playable of games :-) > What are the opinions of people here with regards: > 1) What changes (if any) does xpilot need ? > 2) Where should those changes go ? > 3) How best to manage those changes ? > 4) How to attract more players (if possible) ? I agree with everything U and Kimiko said here too. I think we just need to quit screwing around and get on with it. Or at least I know I do :) See you went and got me all fired up here. So in that vein... Just to throw a project concept out there then and try to push some real direction into play: I move that we hereby move forward on project XPilot 5.0 with the following goal: Merging the two xpilot strains 4.5.4X and XP++ into one coherent next-generation XPilot, Preserving the main features of both (here's the sticky part) in C++. (see i told you that'd be the hard part) If people want to do that, then I'll write the Map Editor, for use with U's new format. (The cross platform editor for the old format is already finished in XP++) Jarrod --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.493 / Virus Database: 292 - Release Date: 6/25/2003 From darel.cullen at bostream.nu Mon Jul 7 10:19:30 2003 From: darel.cullen at bostream.nu (Darel Cullen) Date: Sat Feb 14 14:09:46 2004 Subject: [Xpilot-hacks] What goes... where is xpilot heading? Message-ID: <002301c3448a$66549260$7b3ed7d9@bonet> Hi, I only get the daily journal of xpilot-hacks so the conversation might have moved on from here. But from what I've seen already there have been some good comments, and i'm glad some kind of discussion is going on. Atleast for the good of the game. I agree with everyone that getting major stuff into the official tree is going to be hard until one of the main maintainers wakes up. Of course spare time game programming comes low on the list of life priorities, especially if more urgent matters arise. But I think there are some people I can think off who might happily take over the "reigns" of xpilot moderators to get things moving a little! I dearly hope the original xpilot maintainers want to see the game stay popular and move on technically. Of course the 4) option of starting a merge between 4.5.4X and xpilot++ is there, or even merging them into. Is the xpilot++ stuff GPL? is all 4.5.4X GPL, I suppose they have to be because they use original GPL code. *grin* I remember when i was looking into the xpilot++ stuff there were lots of really nice portable tools that Jarrod had done (front end , map editor) that xpilot-4.5.4X really needs :) , xpilot has always had its "contrib" of tools written in all kinds of languages so i think the fact its c++ is actually a good thing. integrating 4.5.4X to the official 4.5.4 is pretty much already done (although there are bug fixes and new features that would be nice). from that point on we could look at what was done to the server and client in xpilot++ and what the hit would be to move over to a newer language (kimiko is opposed to that but thats a whole other relgious discussion grin) and if we wanted to do that. By the way Jarrod, 4.5.4X has been compiled and shown to "work" under windows, there are some memory leak issues I think though if I recall correctly. Onto the metas servers - I agree writing new meta servers is a reasonably trivial job, which could even be done in some perl script or something, and I agree it could be difficult for people to know where to find the new meta server if the domains weren't redirected. Also we would actually need some long term stable place to host it which could even cost $$$s. I guess we don't know about the long term stability of the metas until a maintainer speaks. I guess they have been pretty stable always, but sometimes I wonder if a bill didn't get paid or a machine broke down what would happen, seeing as they are so crucial to the game. About CVS access to the official tree, I believe CVS is there to be broken for new features only once people are happy that the game is playable and bug free enough are .tar.gz releases done. I also agree the current poly client server allow for some pretty nice eye candy especially at higher FPS. I can see pieces of a Jigsaw puzzle here, but i'm not sure if the people owning the pieces are going to be able or allowed to put them together :) but if you think of what xpilot could be if we stuck together all the work people had been doing separately I think it could be quite good. I think for us to be able to merge 4.5.4X client/server and xpilot++ client/server at first step could be too much, but I think the tools from xpilot++ and 4.5.4X could be merged to start with, then (as long as i guess dick/U/Sam/Kim/Jarrod are in agreement), a client server merge could go ahead? I think the religious differences might be too great to overcome though (c or cpp)? and then issues of who controls what would become an issue. Dont forget we are working to GPL and the good of the game though. GPL software has been known to branch for the good of the software previously also (XFree, JBoss etc). Ho Hum. Anyway I'm available to work (I've recently become a statistic to the failure of the European space market) wherever i'm required most that will get the game out there to more people, in a more modern format :) "build it and they will come" /CB From millerjl98 at yahoo.com Mon Jul 7 17:16:50 2003 From: millerjl98 at yahoo.com (Jarrod Miller) Date: Sat Feb 14 14:09:46 2004 Subject: [Xpilot-hacks] What goes... where is xpilot heading? In-Reply-To: <002301c3448a$66549260$7b3ed7d9@bonet> Message-ID: <20030707201650.57488.qmail@web11508.mail.yahoo.com> > I think for us to be able to merge 4.5.4X > client/server and xpilot++ client/server at > first step could be too much, but I think the tools > from xpilot++ and 4.5.4X could be > merged to start with, then (as long as i guess > dick/U/Sam/Kim/Jarrod are in agreement), > a client server merge could go ahead? > One thing I want to note here...in the development of 4.5.4, the tools, such as the MapEditor, and the entire way the map format is handled, all the options etc, plus all the INI stuff for seamlessly handling .xpilotrc and xpilot.ini files IS integrated into the Client/Server. It'd probably be difficult to merge the tools, without also mergin the client/server at the same time. The mapeditor and the server directly share code in C++ classes. Which lets us do some pretty neat things directly, such as controlling the server options from an external gui, which can be run on a remote machine. All the tools for XP++ are in C++, and rewriting them to merge back to C would be pretty difficult. Really, I kind of think we should adopt U's 4.5.4X code, fixing the few remaining problems first of course, and then begin a move of XPilot to C++, bringing in a new GUI system, and the XP++ tools. I've found myself being somewhat disappointed with FLTK's look/appearance, even though it's better than what XPilot has now. It may just be a case of sprucing it up rather than using the default grey scheme... __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From urpala at cc.helsinki.fi Mon Jul 7 18:33:04 2003 From: urpala at cc.helsinki.fi (Uoti A Urpala) Date: Sat Feb 14 14:09:46 2004 Subject: [Xpilot-hacks] What goes... where is xpilot heading? In-Reply-To: <20030707201650.57488.qmail@web11508.mail.yahoo.com> "from Jarrod Miller at Jul 7, 2003 01:16:50 pm" Message-ID: <200307072133.h67LX4d16018@sirppi.helsinki.fi> > Client/Server. It'd probably be difficult to merge the > tools, without also mergin the client/server at the > same time. The mapeditor would be obsolete with polygon maps anyway. What are the server features that would be worth merging? The only new feature I remember was the ability to run several maps on one server (nice but not essential IMO), was there anything else? > All the tools for XP++ are in C++, and rewriting them > to merge back to C would be pretty difficult. I don't think separate programs would need to be rewritten because of language, though I think a higher-level language language like Python would be most appropriate for tools that do not require top performance. > course, and then begin a move of XPilot to C++, My opinion is still that moving to C++ would not bring many concrete benefits for a program like Xpilot. From millerjl98 at yahoo.com Tue Jul 8 09:29:15 2003 From: millerjl98 at yahoo.com (Jarrod Miller) Date: Sat Feb 14 14:09:46 2004 Subject: [Xpilot-hacks] What goes... where is xpilot heading? In-Reply-To: <200307072133.h67LX4d16018@sirppi.helsinki.fi> Message-ID: <20030708122915.24910.qmail@web11508.mail.yahoo.com> --- Uoti A Urpala wrote: > > Client/Server. It'd probably be difficult to merge > the > > tools, without also mergin the client/server at > the > > same time. > > The mapeditor would be obsolete with polygon maps > anyway. Not really, as I'm sure there's probably people who'd rather continue working with the block format. We'd still be able to edit old format maps, with the OPTION of moving them to the new format. > What are > the server features that would be worth merging? The > only new > feature I remember was the ability to run several > maps on one server > (nice but not essential IMO), was there anything > else? The dynamic editing of server option values through an external gui is deeply integrated into the server code. There's all of Dik's scoreserver stuff too, which is awesome. > > > All the tools for XP++ are in C++, and rewriting > them > > to merge back to C would be pretty difficult. > > I don't think separate programs would need to be > rewritten because of > language, though I think a higher-level language > language like Python > would be most appropriate for tools that do not > require top performance. This is my point. The mapeditor is NOT a separate program from the server at all in XP++, its directly integrated into the server code, along with a lot of the rest of the gui frontend code we created. We've put a lot of the code into classes that are reused in multiple places. > > > course, and then begin a move of XPilot to C++, > > My opinion is still that moving to C++ would not > bring many concrete > benefits for a program like Xpilot. I honestly dont think XPilot will attract many new programers without the move to C++. Almost all new games are written in C++. Adding things like cross platform sound (something XPilot badly needs) would be quite difficult, without using a crossplatform library, everyone of which Ive seen uses C++. Jarrod __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From urpala at cc.helsinki.fi Tue Jul 8 11:59:37 2003 From: urpala at cc.helsinki.fi (Uoti A Urpala) Date: Sat Feb 14 14:09:46 2004 Subject: [Xpilot-hacks] What goes... where is xpilot heading? In-Reply-To: <20030708122915.24910.qmail@web11508.mail.yahoo.com> "from Jarrod Miller at Jul 8, 2003 05:29:15 am" Message-ID: <200307081459.h68Exbv30617@sirppi.helsinki.fi> > > The mapeditor would be obsolete with polygon maps > > anyway. > > Not really, as I'm sure there's probably people who'd > rather continue working with the block format. We'd Yes, certainly there would still be some interest in old block maps. However, I think they wouldn't have a high priority (so it wouldn't matter much whether the best editor for block maps was included with the rest of Xpilot sources). > The dynamic editing of server option values through an > external gui is deeply integrated into the server If you mean just the basic option values ("another way to send '/set' or '/get' commands to the server") that's pretty trivial. If you mean more complex editing of the map and its current state, many of the data structures have changed with the new map format. Either way, there isn't much that would be easier to merge that write from scratch. > code. There's all of Dik's scoreserver stuff too, > which is awesome. I'm not familiar with that part. Could you tell what are its main advantages over other versions? > This is my point. The mapeditor is NOT a separate > program from the server at all in XP++, its directly > integrated into the server code, along with a lot of It was still a separate binary right? If you mean the shared code and the protocol between the editor and the server are such that the programs can not easily be changed independently, or the server features easily used from a program coded in another language, I'd say that is a serious weakness. Neither C nor C++ is well suited to coding a map editor. Their main advantage is that to compile the other Xpilot sources you have to get a C build environment working anyway, so the map editor probably works too. Coding in a language like Python gives much better productivity (I don't think this is a matter of personal preference about languages; other people might primarily pick other high-level scripting languages, but Python is one example of a language that does work substantially better than C++ in this task). I'm not saying you necessarily made a mistake when you coded the editor in C++; if it was the only language you were familiar with that could be used for the task, it might have been the right choice to use C++ instead of learning a more appropriate language (especially when considering the build advantage mentioned above). However, a polygon map editor is substantially more complex than a block map editor, and the amount of extra work required when coding in C++ is also greater. Therefore I don't want the implementation of the map editor to be tied to the implementation of the server in a way that would require them to be coded in the same language. > the rest of the gui frontend code we created. We've > put a lot of the code into classes that are reused in > multiple places. If the current implementations use the same library-style code, that doesn't prevent changing them independently from each other, unless the library code in question expects other parts to use exactly the same version. > > My opinion is still that moving to C++ would not bring many > > concrete benefits for a program like Xpilot. > > I honestly dont think XPilot will attract many new > programers without the move to C++. Almost all new I do not believe that people are currently looking at Xpilot sources with the intent to contribute code, but giving up when they see it's C instead of C++. > games are written in C++. Adding things like cross > platform sound (something XPilot badly needs) would be > quite difficult, without using a crossplatform > library, everyone of which Ive seen uses C++. It seems plausible that new developers (or old ones) might want to use libraries written in C++ (better library interfaces are one of its main advantages over C IMO). However, I don't think that moving to C++ would make those currently uninterested developers start working on Xpilot. From millerjl98 at yahoo.com Wed Jul 9 11:03:52 2003 From: millerjl98 at yahoo.com (Jarrod Miller) Date: Sat Feb 14 14:09:46 2004 Subject: [Xpilot-hacks] What goes... where is xpilot heading? In-Reply-To: <200307081459.h68Exbv30617@sirppi.helsinki.fi> Message-ID: <20030709140352.45930.qmail@web11501.mail.yahoo.com> > > code. There's all of Dik's scoreserver stuff too, > > which is awesome. > > I'm not familiar with that part. Could you tell what > are its main > advantages over other versions? Well, the ScoreServer is a separate binary, than can be run from anywhere. It doesnt have to be on the same machine at all. In all reality a scoreserver could be set up on the opposite side of the planet, because it connects similar to the way a player does (or in XP++ the way the OptionsControl from the MapEditor does.) The Scoreserver as it stands now, uses an XML configuration file, for settings. The default setup is to not store the Score data permenantly, I believe, but with the alteration of just a few options, the scoreserver will store the data in an XML format, so that its carried across between restarts. There's even hooks in there to allow classes to be added so that the data can be stored in MySQL or something like that. At least thats what I remember. The Scoreserver can also be configured to listen on a port, and when a user hits that port with their WebBrowser, it serves a generated page with the ScoreData. I dont know how this compares to other ScoreServers, as I havent used any others. It already does ranking and other things too. > It was still a separate binary right? If you mean > the shared code and > the protocol between the editor and the server are > such that the > programs can not easily be changed independently, or > the server > features easily used from a program coded in another > language, I'd say > that is a serious weakness. Actually, in XP++ there's basically 4 binaries, in the main package. Theres: XPilot(.exe) which is the main interface. This runs the main dialog, which everything else is run from. The MapEditor, ShipEditor, XPWhere (meta interface), Keyboard Editor, and the Client Options Editor (which lets you change all the options similar to the way you can from the client now, but in a GUI similar to the rest of the FLTK stuff), are all part of this binary. XPilotClient(.exe) which is of course the client. The plan was/is to also integrate the Keyboard Editor (so that the keyboard could be edited without leaving the Client. The ClientOptions stuff would also be integrated here. Reworking the entire Client GUI is where we stalled out at. XPilotServer(.exe) this is an interfaceless Daemon style process that is started/stopped/modified by the main program (XPilot.exe). From the main program you could select a map using a "File/Open" style Dialog Box (I think there was very little left to encapsulate before the server would be able to run multiple maps simultaneously. This way there'd be just 1 server process, but many maps running and available on the metaserver. This may even be working, but I dont think it was totally finished.) Once the server was running, with the push of a button you could connect to it and in realtime from a gui change any options you wanted. The server control to do that was also written in such a way that if more than one admin was connected to the server, changes made by one were seen by all in realtime. XPilotScoreServer(.exe) this is the scoreserver binary I mentioned above. >Coding in a language like Python gives much > better productivity > (I don't think this is a matter of personal > preference about > languages; other people might primarily pick other > high-level > scripting languages, but Python is one example of a > language that does > work substantially better than C++ in this task). Everytime I've had do deal with a project where the main program was in one language, but associated tools were in another, its been a nightmare. I just dont see how it helps to write some parts of the program group in one language, and other parts in another, especially in this case, where it'd be more valuable to have the editor's share code with the client/server. I dont see how its more productive to have to recode how to handle say, a shipshapefile if the code to do it is already there in the client. Why not just have one Class that handles Ships and anything that has to handle ships, be it Server/Client/ShipEditor just uses that class, rather than duplicating effort all the time. So say you add a new feature to the Ship class, say a Secondary Engine location. Every program immediately knows about it, and they all draw it the same way. (its not this way in XP++ yet, but only because I didnt get into integrating the two classes. Its one of the very next things on my list todo.) > However, a polygon map editor is substantially more > complex than a > block map editor, and the amount of extra work > required when coding in > C++ is also greater. Therefore I don't want the > implementation of the > map editor to be tied to the implementation of the > server in a way > that would require them to be coded in the same > language. And I dont agree, sorry. > I do not believe that people are currently looking > at Xpilot sources > with the intent to contribute code, but giving up > when they see it's C > instead of C++. Well, If I was looking to get involved in a new project, I'd be turned away. > It seems plausible that new developers (or old ones) > might want to use > libraries written in C++ (better library interfaces > are one of its > main advantages over C IMO). However, I don't think > that moving to C++ > would make those currently uninterested developers > start working on > Xpilot. I guess maybe my main problem is I dont see how it benefits at all especially long term, to have a program spread across several languages, especially if it can all be done in just one. You just end up with code/programs that's really neat looking, but with noone to support it, because your original developers have moved on. Jarrod __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From urpala at cc.helsinki.fi Wed Jul 9 12:50:25 2003 From: urpala at cc.helsinki.fi (Uoti A Urpala) Date: Sat Feb 14 14:09:46 2004 Subject: [Xpilot-hacks] What goes... where is xpilot heading? In-Reply-To: <20030709140352.45930.qmail@web11501.mail.yahoo.com> "from Jarrod Miller at Jul 9, 2003 07:03:52 am" Message-ID: <200307091550.h69FoPv06822@sirppi.helsinki.fi> > were in another, its been a nightmare. I just dont see > how it helps to write some parts of the program group > in one language, and other parts in another, Of course using multiple languages for the sake of it isn't beneficial. But do you really mean you don't see how different languages might be appropriate for different programs, and those programs might be parts of the same program group? Do you understand that for some tasks you can have several times higher productivity by using a language other than C++? > client/server. I dont see how its more productive to > have to recode how to handle say, a shipshapefile if > the code to do it is already there in the client. Why Because the benefits of using a more appropriate language far outweight the cost of having to reimplement some code. I have so far written two Xpilot utilities using Python: the xp->xp2 map conversion script (mapconvert.py in the top level directory of the source tree) and the polygon map editor that I wrote last year (somewhat illogically in contrib/jxpmap/python). The latter is "usable", but not quite complete enough that you'd want to make real maps with it - I'm not sure whether I'll find time to continue work on it. In the first case, I reimplemented parsing of the old map format; in the second, the parsing of the new map format. In both cases I could code them in far less total time than C or C++ would have required. > I guess maybe my main problem is I dont see how it > benefits at all especially long term, to have a > program spread across several languages, especially if > it can all be done in just one. You just end up with I find "especially if it can all be done in just one" to be a somewhat odd comment. Of course it's possible to code them in C++; there aren't many tasks where it would be impossible to use it. But C++ really isn't a language you should think of first when you face a programming task. Do you have experience in any other languages? Especially higher-level ones? (Not a well-defined term, but let's say at least languages with built-in gargabe collection - though Java isn't that high level otherwise...) > code/programs that's really neat looking, but with > noone to support it, because your original developers > have moved on. You're more likely to get the programs done in the first place if use appropriate languages. Try to implement even the current functionality of the Python map editor in C++ and see how many days that takes you. From dick at buckosoft.com Wed Jul 9 21:41:10 2003 From: dick at buckosoft.com (Dick Balaska) Date: Sat Feb 14 14:09:46 2004 Subject: [Xpilot-hacks] What goes... where is xpilot heading? In-Reply-To: <200307081459.h68Exbv30617@sirppi.helsinki.fi> References: <200307081459.h68Exbv30617@sirppi.helsinki.fi> Message-ID: <3F0CB626.9080400@buckosoft.com> I agree with, and back Jarrod on everything he said. Uoti A Urpala wrote: >>>The mapeditor would be obsolete with polygon maps >>>anyway. >> >>Not really, as I'm sure there's probably people who'd >>rather continue working with the block format. We'd > > > Yes, certainly there would still be some interest in old block maps. > However, I think they wouldn't have a high priority (so it wouldn't > matter much whether the best editor for block maps was included with > the rest of Xpilot sources). > > >>The dynamic editing of server option values through an >>external gui is deeply integrated into the server > > > If you mean just the basic option values ("another way to send '/set' > or '/get' commands to the server") that's pretty trivial. If you mean > more complex editing of the map and its current state, many of the > data structures have changed with the new map format. Either way, > there isn't much that would be easier to merge that write from > scratch. > > >>code. There's all of Dik's scoreserver stuff too, >>which is awesome. > > > I'm not familiar with that part. Could you tell what are its main > advantages over other versions? > > >>This is my point. The mapeditor is NOT a separate >>program from the server at all in XP++, its directly >>integrated into the server code, along with a lot of > > > It was still a separate binary right? If you mean the shared code and > the protocol between the editor and the server are such that the > programs can not easily be changed independently, or the server > features easily used from a program coded in another language, I'd sa > that is a serious weakness. Yes, it is a weakness. One of the stupidest features is that it allows you to edit the blocks of the map in a map window, while flying a client in another window, and seeing the map change in the client. Who the hell would want dynamically changing maps? Even more stupid, is because of the way XP++ throws C++ objects around, 2 or more people can have map editors and/or game clients attached to the same server and see each other's changes. Ew! Much better is: 1) Edit map in k001 python editor. 2) Start server with map. 3) Fly around and think about changes to your map. 4) exit client. 5) exit server. 6) repeat. Uoti is right. Seamless integration of the components of a project or system is backwards and a waste. > > Neither C nor C++ is well suited to coding a map editor. Huh? > Their main > advantage is that to compile the other Xpilot sources you have to get > a C build environment working anyway, so the map editor probably works > too. Coding in a language like Python gives much better productivity > (I don't think this is a matter of personal preference about > languages; other people might primarily pick other high-level > scripting languages, but Python is one example of a language that does > work substantially better than C++ in this task). Could you please point me to a gui editor (for any project) written in Python? (It doesn't have to have any reliable UDP connectivity because we've decided that's a worthless feature.) I think it is so cool that python doesn't require you to get a build environment working. Oops, Mailman doesn't work with Python 2.0. > I'm not saying you > necessarily made a mistake when you coded the editor in C++; if it was > the only language you were familiar with that could be used for the > task, it might have been the right choice to use C++ instead of > learning a more appropriate language (especially when considering the > build advantage mentioned above). More appropriate? I'm speechless. (I had typed a couple of things here, but i deleted them) > However, a polygon map editor is substantially more complex than a > block map editor, Why? > [ in another mail Uoti wrote ] > But C++ really > isn't a language you should think of first when you face a programming > task. Do you have experience in any other languages? (Raises hand) > Especially > higher-level ones? (Not a well-defined term, but let's say at least > languages with built-in gargabe collection - though Java isn't that > high level otherwise...) IMHO, Java's garbage collection is more trouble than it's worth. Unless you're one of those people who writes lazy code because you don't understand what you're doing. Java is the only "system" that i've ever got a "out of memory" error on. A friend taught me a couple of tricks for the garbage collector. -Yea for that.- Java lacks operator overloading; a great feature when doing math. Python? I see no advantages for most projects. Mailman is cool. What's up with that white space thing? I just edited your source file with tabs=8 instead of tabexpand and silently broke your functionality. No compiler complaints, and visually the file is identical. -Yea for that.- Perl is tr?s chic. Do i want to write a real-time game server, or a gui map editor in it? That's not really it's thing. Visual Basic is interesting. I can write a single line of code which launches M$ Word, connects to it and gives me access to a document. Unfortunately, there's a million things that can go wrong in the underlying COM setup in that one line of code and the only out is "Application error. Click to terminate". -Yea for that.- C++ _is_ the first language i think of for most projects; especially games. What else gives me machine native binaries in an object oriented format? What else gives me access to and allows me to control things like hyperthreading and FPU, and dare i say it, memory access and usage? Oh, you want to write some web page/database thingy? Sure Tomcat/Java is a "faster to production" solution (and a rather elegent one). But to write game code in something you can't even control memory usage and thread execution? ===================================================================================== Someone wrote: >> IIRC the main >> reason that Uoti wasn't given CVS access was that his style of development >> was too 'radical'. It would lead to a CVS version that was either >> unplayable or seriously lacking some important features for a long time. >> The preferred style is to develop new stuff separately until it works >> with most other parts of the code before patching CVS. Uoti wrote: > I don't think that is a fair description of my style of development. I > think that CVS should be kept usable, and major rewrites should be > developed separately until they work "in real use". I think my main > disagreement with the maintainers (mainly Bert) was about the value of > backwards compatibility. My view was that there were several features > in Xpilot that were badly designed and implemented, were not in wide > use, and could thus be removed or changed (instead of spending time to > keep them working exactly the same way when other parts of the code > changed). So maybe you could say that the disagreement was not about > whether important features should be kept working, but about whether > some existing features were important or insignificant and > undesirable. Actually, i had issues with the lack of robots; which is hardly an insignificant feature. Yes, the current robots are dated, and not very intelligent. But they are the enemy a newbie sees first, and make for good practice. And in some maps they can be ok (fishfight). Your argument that "robots are stupid and nobody uses them anyway" is what backed me away from integrating your polygon code into the base. Targets you said were easily implemented should anyone want them. That was fine with me. What other features were there? The maintainers also had issue with you claiming the xpilot.sf.net domain and not giving it up when asked. (Yes, you were there first, and the maintainers have no legal standing in the GPL world to force you to give it to us.) (I also have issue with you never spelling XPilot correctly ;) I also had issue with your attitude, which is basically "All non-Uoti ideas are stupid". In order to be a member of a team, you have to be more tolerant of other people and their ideas. Here; here is a classic Uoti example from this thread: > If you mean just the basic option values ("another way to send '/set' > or '/get' commands to the server") that's pretty trivial. If you mean > more complex editing of the map and its current state, many of the > data structures have changed with the new map format. Either way, > there isn't much that would be easier to merge that write from > scratch. So, what this says is: without having a clue, you've reduced our work to > ("another way to send '/set' or '/get' commands to the server") and dismissed it. Then further, without any understanding of our work, you've decided that our work is incompatible with yours and therefore should be thrown away and written from scratch. Elsewhere in this mail one can presume that this "writing from scratch" shoud be done by someone not as stoopid as us, for we were so dumb that we actually wrote code in C++. That leaves ... you! ===================================================================================== XPilot++ has indeed stalled. The plan was to release it as XPilot 5.0. I guess i lost interest because... 1) Jarrod got busy with Real Life and i was working solo and it wasn't as much fun. 2) I had to back down my connection to 64Kb (for $300/month) because i couldn't afford $600/month for a minimal XPilot playable 128Kb. If i couldn't play, it wasn't much fun developing alone. 3) Uoti finally convinced me that i'm stupid, C++ is worthless and stupid, XPilot++ is worthless and stupid, and everyone wants polygon Blood's more than they want newbie friendliness and integrated tools. I'm surprised that Uoti's worried about when he should write the "meta server in a day" code. Has there been any problems with the current meta servers? Hey, who do you suppose is http://www.xpilot.net ? (BTW Jarrod, my last Windows xp++ workspace not checked in contains replacing .xpm with .png) dik From urpala at cc.helsinki.fi Thu Jul 10 02:35:53 2003 From: urpala at cc.helsinki.fi (Uoti A Urpala) Date: Sat Feb 14 14:09:47 2004 Subject: [Xpilot-hacks] What goes... where is xpilot heading? In-Reply-To: <3F0CB626.9080400@buckosoft.com> "from Dick Balaska at Jul 9, 2003 08:41:10 pm" Message-ID: <200307100535.h6A5Zrp13694@sirppi.helsinki.fi> Dick Balaska wrote: > I agree with, and back Jarrod on everything he said. The later parts of your post sound quite offended. However, I think you have misunderstood some of the things I said. If you again reply with such a hostile tone I hope you read my post twice and think if you really have reason for it. > > programs can not easily be changed independently, or the server > > features easily used from a program coded in another language, I'd say > > that is a serious weakness. > > > Yes, it is a weakness. One of the stupidest features is that it allows > you to edit the blocks of the map in a map window, while flying a client > in another window, and seeing the map change in the client. Being able to edit the map while the server is running is useful. However, it can be implemented in a language-independent way. For example, the current protocol between the client and the server is such that one side could be recoded in another language without problems. > > Neither C nor C++ is well suited to coding a map editor. > > Huh? Higher-level languages can be used as the map editor does not require high speed. > > Their main > > advantage is that to compile the other Xpilot sources you have to get > > a C build environment working anyway, so the map editor probably works > > too. Coding in a language like Python gives much better productivity > > (I don't think this is a matter of personal preference about > > languages; other people might primarily pick other high-level > > scripting languages, but Python is one example of a language that does > > work substantially better than C++ in this task). > > Could you please point me to a gui editor (for any project) written > in Python? http://www.thekompany.com/products/blackadder/ > (It doesn't have to have any reliable UDP connectivity because we've > decided that's a worthless feature.) I'm not sure what your point is. Do you think that implementing UDP connectivity in Python would be problematic? (It wouldn't.) > I think it is so cool that python doesn't require you to get a build > environment working. Oops, Mailman doesn't work with Python 2.0. I did not talk about the benefits of not having to compile programs. On the opposite, I said that as the client and server require a C build environment anyway, C and C++ have the advantage of not requiring more external software. Sure, there can be machines with outdated Python versions or no Python installed at all (though if the C++ compiler is as old as Python 2.0, it probably has problems compiling modern C++ code too). > > task, it might have been the right choice to use C++ instead of > > learning a more appropriate language (especially when considering the > > build advantage mentioned above). > > More appropriate? I'm speechless. > (I had typed a couple of things here, but i deleted them) A person who already knew C++ and several other languages fluently could complete the project more quickly and/or produce a better result by choosing one of the other languages instead of C++. Do you not believe this to be true, or did you think I meant something else by "appropriate language" above? > > However, a polygon map editor is substantially more complex than a > > block map editor, > > Why? Block maps contain a rather limited amount of information. Polygon maps allow tuning more things, and also require more support from the editor to prevent taking care of the details from becoming tedious. You could compare them as an application to write one-line texts (a simple UI is very efficient here) and one to write books (requires more functionality to be comfortable). I'm not claiming the difference between the map formats is as large as that between a one-line text and a book, but it should give you an idea of why more is required from the editor. > > Especially > > higher-level ones? (Not a well-defined term, but let's say at least > > languages with built-in gargabe collection - though Java isn't that > > high level otherwise...) > > IMHO, Java's garbage collection is more trouble than it's worth. Unless Would you really prefer having to write explicit free() calls? The problems you had sounded more like implementation problems in the Java system you were using, rather than with the language syntax. I haven't had such problems with Python at least (it generally uses much less memory than Java platforms, though I think Java implementations have improved too). > -Yea for that.- Java lacks operator overloading; a great feature > when doing math. As I said earlier, I don't consider Java to be a really high-level language. > Python? I see no advantages for most projects. Mailman is cool. How much do you know about Python? "No advantages" compared to what? > What's up with that white space thing? I just edited your source White space intendation works well in practice. > Perl is tr?s chic. Do i want to write a real-time game server, or a > gui map editor in it? That's not really it's thing. It probably isn't. > Visual Basic is interesting. I can write a single line of code > out is "Application error. Click to terminate". -Yea for that.- Few people think highly of Visual Basic as a language. > C++ _is_ the first language i think of for most projects; especially games. > What else gives me machine native binaries in an object oriented format? > What else gives me access to and allows me to control things like > hyperthreading and FPU, and dare i say it, memory access and usage? C++ is appropriate for many game uses. I'm don't claim that it would be a bad language; it can be the best choice for uses that require the best possible performance. However, speed isn't the most important feature of a map editor (and it doesn't require the features you listed above either). I wouldn't want to rewrite the server or client in Python, though it might be useful to write the client in combined C and Python, using C for high-speed frame drawing and Python for advanced GUI features. > Actually, i had issues with the lack of robots; which is hardly an > insignificant feature. Yes, the current robots are dated, and not very > intelligent. But they are the enemy a newbie sees first, and make for > good practice. And in some maps they can be ok (fishfight). > Your argument that "robots are stupid and nobody uses them anyway" is > what backed me away from integrating your polygon code into the base. IIRC my opinion was that some kind of obstacles were needed for single-player maps, but robots filled that role rather badly. I also did not claim that "nobody uses them anyway". Partial quote from one of the mails that discussed the removal of robots: """ > Why do you think so many maps have been designed > for robot play? Because people have wanted to create a single-player map? Unfortunately making a good one seems to be impossible in the current XPilot version. Robots on maps like New Dark Hell are mostly minor annoyances. """ Also, at that time I said myself that the polygon version was not yet ready to become the official version to be used by everyone. > The maintainers also had issue with you claiming the xpilot.sf.net domain > and not giving it up when asked. (Yes, you were there first, and the At the time I registered the project I didn't expect the official CVS to move to Sourceforge. I didn't exactly refuse to give it up. I sent one mail about possible difficulties in trying to change the name (at the time Sourceforge had bad problems with rapid growth). In response, Winni suggested registering another project and waiting until it started working (which sometimes took a long time then) before the name switch. Before I could reply to that (less than 1 hour later) he sent another mail saying not to bother, it would be easiest if they just used another name. > > If you mean just the basic option values ("another way to send '/set' > > or '/get' commands to the server") that's pretty trivial. If you mean > > more complex editing of the map and its current state, many of the > > data structures have changed with the new map format. Either way, > > there isn't much that would be easier to merge that write from > > scratch. > > So, what this says is: > without having a clue, you've reduced our work to > > ("another way to send '/set' or '/get' commands to the server") > and dismissed it. You misunderstood what I meant. I didn't claim that all you had done was writing another way of setting options. I said that it was the only part that was likely to work in the polygon version. Even when running old block maps the server works differently internally, and the map cannot be edited in the same way while running. > Elsewhere in this mail one can presume that this "writing from scratch" > shoud be done by someone not as stoopid as us, for we were so dumb that we > actually wrote code in C++. That leaves ... you! I didn't claim that writing code in C++ was dumb. While I don't see big benefits in moving the client and server from C to C++, it isn't worse for them either. Another language would be better suited for the map editor, but I said it might not be worth using another language if you were most familiar with C++, and the choice for language matters less for a block map editor which is simpler. I did oppose the idea of coupling the map editor to the server and client code so tightly that it would have to be written in C++. > 3) Uoti finally convinced me that i'm stupid, C++ is worthless and > stupid, XPilot++ is worthless and stupid, and everyone wants I do not think C++ is worthless or stupid. It has important uses. However, as I said I don't think it's the kind of language you should think of using first when facing a programming task. I haven't commented on the total value of XP++ in this thread. > polygon Blood's more than they want newbie friendliness and > integrated tools. It does have quite a lot more than just polygons nowadays. > I'm surprised that Uoti's worried about when he should write the > "meta server in a day" code. Has there been any problems with the > current meta servers? I did not bring that up, only commented on the feasibility of coding new meta servers that others were already discussing. There have been no significant problems AFAIK, but I don't think it was all that farfetched think of the possibility of requiring new metas when there had been no sign of activity from their maintainers for a long time. From ksoderbl at niksula.hut.fi Thu Jul 10 11:49:28 2003 From: ksoderbl at niksula.hut.fi (=?ISO-8859-1?Q?Kristian_S=F6derblom?=) Date: Sat Feb 14 14:09:47 2004 Subject: [Xpilot-hacks] What goes... where is xpilot heading? In-Reply-To: <3F0CB626.9080400@buckosoft.com> Message-ID: Hello. So finally one of the maintainers speak. Let me tell you a bit about my work and my opinions (caution: this mail is a bit long). On Wed, 9 Jul 2003, Dick Balaska wrote: > Actually, i had issues with the lack of robots; which is hardly an > insignificant feature. Yes, the current robots are dated, and not very > intelligent. But they are the enemy a newbie sees first, and make for > good practice. And in some maps they can be ok (fishfight). > Your argument that "robots are stupid and nobody uses them anyway" is > what backed me away from integrating your polygon code into the base. I'm not sure how familiar you are with the 4.5.4X code base. Late last year I had done some small hacks to Erik Andersson's (Mara) client and noticed that the main XPilot development had stalled or seemed not to move forward from 4.5.4. Also, I had taken a look at Uoti's 4.3.1X and saw that development there had also at least temporarily stopped. I also knew about XPilot++, but was not familiar to it since it was not used on any real servers. So what I wanted was a unified client that would have all the nice features of Mara's client and which you could play on both block based and polygon based maps, so that you would not need to switch client depending on what server / map you played on. It was not so difficult to merge the 4.3.1X and 4.5.4 clients, it took about 2 months or calendar time. Probably it would have taken far less time had I known the code better when I started merging. I did the merge by doing a diff between 4.3.1 and 4.3.1X and then I moved the stuff from the diff into the 4.5.4 client. After I got the client working I added Mara's stuff to it and started using that client always when I played. The server side was much more difficult and took longer to merge. I started working on this because I had seen that the polygon code worked and it seemed advanced and powerful and I didn't want Uoti's work to go to waste. The merge is still not 100% complete but quite close. One of the main problems was that much of the code in 4.5.4 assumes the map is block based and needed changes to work on a polygon map. The polygon version, 4.3.1X, lacked robots, cannons, wormholes and warping, support for the old map format, the laser didn't seem to work properly and there was some other things too. The merging of the servers seemed very difficult. The way I started working on it was the same way as with the client, using a diff. I gradually did changes to 4.5.4 so that it would be more compatible with the polygon approach of doing things (that is try to not use World.block for anything etc). Then I added the polygon wall code and support in the map loader to check if the map was an xp (block based) or xp2 (polygon map). Now I had a hybrid server which could serve both as an "old" server (using the 4.5.4 code) and as a polygon server (using the 4.3.1X code). The code was somewhat cleaned up, I moved the details of the xp file format to src/server/xpmap.c and same for the xp2 map (moved to xp2map.c). Now, since the polygon way of doing things is more general, I wanted the server internals to be such that it would always use the polygon code, even if the map was block based. One additional advantage of this approach is that the polygon code fixed a few bugs in the game, one is that the ships now "edgebounce" that is the ships can't enter the walls as in 4.5.4. Also the analytical collision detection had been extended so that it would detect some hits that the 4.5.4 code would not. The next step was to write code to transform the block walls into polygons in the server so that it would use the polygon code internally, even if you were playing on a block based map. This was not too difficult, my first idea was to have one polygon per block, but I improved on this just a little bit, and joined horizontal blocks to form polygons that are one block high, but can be several blocks wide. Conversions were also needed for other map objects, for example the treasure box. (btw, If you want to see the created polygons you can still start the server with the -polygonMode flag (when you have an xp map file)). At this time the server already worked quite well and could be used to host a Blood's music game. So I started running a test server and one problem found was that whn you had connected to your own team's ball and it would hit an enemy treasure box it did not break, as it was supposed to. Now I had to ask Uoti's advice and with his help this issue could be fixed. The fix involved extending the way the polygon server determines if some object can hit another. This new approach was helpful when I started adding support for the missing map objects. Ok anyway, the 4.5.4X now has support for cannons, targets and robots and they seem to work as in 4.5.4. Support for warping is almost complete (only minor details to fix), wormholes are currently missing but I believe that they can be added quite soon. I remember smart missile navigation is still block based. Btw, if you think the robots are too lame, we could add in Throat's "suirobots" which at least are quite aggressive. One other nice feature of 4.5.4X is the game speed which is independent of server FPS, so you can run the server at high fps and still the game will be playable. My opinion on the future of XPilot is that if XPilot stays at 4.5.4 it will not have a very bright future. Some people will play it for sure, but it will not be attractive for newbies. So somehow a new XPilot 5 should now be created. Of course I think that the 4.5.4X code base should be used, I've spent a lot of time working on it after all. The 4.5.4X code not only fixes a lot of bugs in 4.5.4, it also is quite backwards compatible and the code has been cleaned up alot. I've done a lot of changes to increase the maintainability and readability of the code. Just one example: I changed almost all functions taking an index to the player table to take a the player pointer instead. The advantage is you don't have to do "player *pl = Players[ind];" all over the place. The other advantage is that it is safer. It is easy to confuse the player id with the index and if you do that the compiler will not notice it. Also if you use the index you end up with functions which uses two references to a player: both the index and the player pointer, which is a bit confusing. > Elsewhere in this mail one can presume that this "writing from scratch" > shoud be done by someone not as stoopid as us, for we were so dumb that we > actually wrote code in C++. That leaves ... you! I've taken a quick look at XPilot++ code and it looks like you've taken the old code and you use that and then you have written a lot of new C++ code. As someone mentioned, I've asked about merging 4.5.4X with xp++ to create XPilot 5. One way this could be done, would be to take the 4.5.4X code base, turn that to C++ and then add the other C++ stuff you've written to that. There are of course 2 other ways: use only 4.5.4X or use only xp++. Now, using only 4.5.4X could work if we just added the missing things. Using only xp++ might also be possible, but I think that would not be so clever, since then it would be even more difficult to merge the polygon stuff to official XPilot later. Merging it once was already quite a big job. One problem with the XPilot 4.5.4 code is that it is quite difficult to understand. Some functions are very long and difficult to understand, and low level details are spread all over the place. Cleaning this does not require C++, only that the big functions are broken down to smaller ones that you can understand and that duplicate code is moved to functions or macros and that you don't mix "high level" and "low level" code. So if you want to do something in the code you don't just write and read data structures and global variables directly, you call a function to do it for you. One example here is the shipshapes. There is no advantage in writing something like pl->ship->pts[0][pl->dir].x all over the place. The same thing can be done with a macro, for example Ship_get_point(pl->ship, 0, pl->dir).x, this is way more powerful (can be a macro of function, looks cleaner, and allows changing the shipshape structure. So before starting to add a lot of C++ hacks to the code it would be good to clean the old code up. Ok this mail for sure is long enough now. I'm hoping that somehow we could cooperate to create the next XPilot version, which would be good enough that newbies would want to play it. I was thinking that later one cool thing would be to implement a client in OpenGL and SDL, also with sound support. Playing with such a client on a polygon map with nice textures and stuff at 50 or 100 fps should be the first thing newbies experience when they try XPilot. This way they see it not as some ancient hack but as a game that has a future. -- Kristian S?derblom / kps / Samaseon @ XPilot From kimiko at xpilot.org Fri Jul 11 18:03:49 2003 From: kimiko at xpilot.org (Kimiko Koopman) Date: Sat Feb 14 14:09:47 2004 Subject: [Xpilot-hacks] Dick & Uoti Message-ID: <20030711210349.GA3294@brokenmoon2.xs4all.nl> Hi there. I think that you both (and Kristian as well) have good arguments on how to continue with XPilot development. However, it is not very productive to go on arguing. So, Dick, please knock off the sarcasm, and Uoti, please consider that working together means that you may both have to give in a little. How you work out your differences of opinion is up to you, but please do so in a civil manner. It would be a real shame if XPilot 5 would never see the light of day just because you cannot cooperate. Kimiko From wj at suetholz.net Thu Jul 24 02:26:21 2003 From: wj at suetholz.net (William Suetholz) Date: Sat Feb 14 14:09:47 2004 Subject: [Xpilot-hacks] Joystick abilities Message-ID: <1059024381.8304.13.camel@localhost> Hello, I have implemented support for handleing a joystick under linux. It is simple, but, I did add in options for button definitions. It only supports the X and Y axes at this time. I will be adding in more later. This required makeing a new source module, and some minor modifications to join.c, configure.c, xpclient.h, and default.c. The joystick I have has 26 buttons and 8 axes shown under linux. There are two slider switches labeled Mode, and Alt. I am currently using the mode buttons to define Mode 1, Mode 2, and Mode 3. I was thinking of using the Alt buttons to define different button mappings.. Alt 1 for a shoot-em-up, Alt 2 for bloods. But this has not been done yet. As it sits, the code is working, and did not require any changes to the server code, since I'm using the function defined for mouse movement to get the ship pointed the correct way. Special thanks to BenUrban and NodeZ for their help there.. What ifdef should I use to keep things happy on non-linux boxes? Let me know what to do to submit these changes... Bill Suetholz From urpala at cc.helsinki.fi Thu Jul 24 03:42:27 2003 From: urpala at cc.helsinki.fi (Uoti A Urpala) Date: Sat Feb 14 14:09:47 2004 Subject: [Xpilot-hacks] Joystick abilities In-Reply-To: <1059024381.8304.13.camel@localhost> "from William Suetholz at Jul 24, 2003 00:26:21 am" Message-ID: <200307240642.h6O6gRs23133@sirppi.helsinki.fi> > As it sits, the code is working, and did not require > any changes to the server code, since I'm using the > function defined for mouse movement to get the ship > pointed the correct way. I suppose you implemented it so that pointing the joystick in some direction immediately points the ship that way. How does your code work if the ship cannot be turned (there's a wall in the way)? Also, how do you determine which way the ship is currently pointing on the server? You can get a recent direction from the last received frame, but you cannot be sure how many of your previously sent turn packets were handled by the server before generating that position and how many are still in the network. From wsuetholz at centonline.com Fri Jul 25 03:56:19 2003 From: wsuetholz at centonline.com (William Suetholz) Date: Sat Feb 14 14:09:47 2004 Subject: [Xpilot-hacks] Joystick abilities In-Reply-To: <200307240642.h6O6gRs23133@sirppi.helsinki.fi> References: <1059024381.8304.13.camel@localhost> <200307240642.h6O6gRs23133@sirppi.helsinki.fi> Message-ID: <20030725015619.319a9991.wsuetholz@centonline.com> On Thu, 24 Jul 2003 09:42:27 +0300 (EET DST) Uoti A Urpala wrote: > > As it sits, the code is working, and did not require > > any changes to the server code, since I'm using the > > function defined for mouse movement to get the ship > > pointed the correct way. > > I suppose you implemented it so that pointing the joystick in some > direction immediately points the ship that way. How does your code > work if the ship cannot be turned (there's a wall in the way)? Also, > how do you determine which way the ship is currently pointing on the > server? You can get a recent direction from the last received frame, but > you cannot be sure how many of your previously sent turn packets were > handled by the server before generating that position and how many are > still in the network. I implemented it by taking the current heading, and calculating what the new heading should be, and sending the appropriate mouse mode command to adjust the heading. It works the same way as the mouse mode works when things get in the way of turning.. I'm not sure what to do about the lag issue you describe.. The best solution I can come up with is have the client always know which way it should be pointing, noticing when it gets updates back from the server, and possibly reacting to the heading not changing to what it thinks it should be.. This has a possible problem with things getting in the way, but could be feasible. Bill Suetholz From urpala at cc.helsinki.fi Fri Jul 25 03:00:19 2003 From: urpala at cc.helsinki.fi (Uoti A Urpala) Date: Sat Feb 14 14:09:47 2004 Subject: [Xpilot-hacks] Joystick abilities In-Reply-To: <20030725015619.319a9991.wsuetholz@centonline.com> "from William Suetholz at Jul 25, 2003 01:56:19 am" Message-ID: <200307250600.h6P60Js25898@sirppi.helsinki.fi> William Suetholz wrote: > It works the same way as the mouse mode works when things get in > the way of turning.. If you mean "the result is the same as if mouse mode had sent the same turn packets", then that's obviously true, but doesn't really answer the question. The interesting part is, what are those turn packets that the joystick mode is going to send? > I'm not sure what to do about the lag issue you describe.. > > The best solution I can come up with is have the client always > know which way it should be pointing, noticing when it gets updates > back from the server, and possibly reacting to the heading not > changing to what it thinks it should be.. This has a possible If you immediately "correct" the difference between the received direction and the desired one whenever you get a frame, it's going to fail badly when latency is a couple of frames (likely on a 50 FPS server). > problem with things getting in the way, but could be feasible. It probably could be made to work acceptably, but it's not a trivial problem. From wsuetholz at centonline.com Fri Jul 25 17:49:26 2003 From: wsuetholz at centonline.com (William Suetholz) Date: Sat Feb 14 14:09:47 2004 Subject: [Xpilot-hacks] Joystick abilities In-Reply-To: <200307250600.h6P60Js25898@sirppi.helsinki.fi> References: <20030725015619.319a9991.wsuetholz@centonline.com> <200307250600.h6P60Js25898@sirppi.helsinki.fi> Message-ID: <20030725154926.0c9f0f58.wsuetholz@centonline.com> On Fri, 25 Jul 2003 09:00:19 +0300 (EET DST) Uoti A Urpala wrote: > William Suetholz wrote: > > It works the same way as the mouse mode works when things get in > > the way of turning.. > > If you mean "the result is the same as if mouse mode had sent the same > turn packets", then that's obviously true, but doesn't really answer > the question. The interesting part is, what are those turn packets > that the joystick mode is going to send? Calculation of the difference between the direction the client currently thinks it's at, and the direction it wants to be pointing. Because the circle is 0-128 degrees, I break at 64 to determine if it is negative or positive turn direction. > > > I'm not sure what to do about the lag issue you describe.. > > > > The best solution I can come up with is have the client always > > know which way it should be pointing, noticing when it gets updates > > back from the server, and possibly reacting to the heading not > > changing to what it thinks it should be.. This has a possible > > If you immediately "correct" the difference between the received > direction and the desired one whenever you get a frame, it's going to > fail badly when latency is a couple of frames (likely on a 50 FPS > server). Yes, I had thought of that. Does the client keep track of latency, and could it allow for latency * 1.5 time for the heading to change? This would possibly mean integrating some kind of timer code in the client. I really haven't looked into that side of things too much. Does the heading get changed when bouncing into things, or, only when the user requests a change? And when the user dies of course. Maybe the code that gets the new heading could see if it changed, and if so, check to see if it matches the current joystick defined heading, and then adjust the heading at that time.. That would, however increase the latency for heading changes indicated by the joystick. This isn't a problem for the mouse, because all it's doing is sending deltas of mouse movements, rather than saying in the client that THIS is the heading I want now. The other option is to always send the rotation based on the difference between the old joystick heading, and the new joystick heading.. Maybe this idea could be workable?? > > > problem with things getting in the way, but could be feasible. > > It probably could be made to work acceptably, but it's not a trivial > problem. Any pointers/suggestions on the proper way to handle this issue would be welcome. For the most part I've played on servers that have low latency for me, and it works great. I have noticed on one the problems that seem to be caused by latency, and the joystick code trying to adjust the heading too much when the joystick moves a little bit, because the heading from the server hasn't changed yet. That seems to be exactly what you are worried about. Bill Suetholz From deity at home.se Sun Jul 27 19:37:28 2003 From: deity at home.se (Erik Andersson) Date: Sat Feb 14 14:09:47 2004 Subject: [Xpilot-hacks] Joystick abilities Message-ID: <1059345448.5c853680deity@home.se> What if we change things so that the client sends wanted direction instead if relative turns to the server? (could remove disappearing turns from wallcollisions with already existing hack in 4.5.4X) Pros: easier to implement this joystick thing from what I can understand, possibly easier to play lagged if the client immediately can show what your direction _will_ be... some old hack tried to do this a couple of years ago iirc Cons: not sure, except maybe it would be easier to make some autoaim hacks etc. /virus From wj at suetholz.net Mon Jul 28 00:25:04 2003 From: wj at suetholz.net (William Suetholz) Date: Sat Feb 14 14:09:47 2004 Subject: [Xpilot-hacks] Joystick abilities References: <1059345448.5c853680deity@home.se> Message-ID: <000a01c354b7$d6eb0260$80fca8c0@WJSLAPTOP> Hello, I was trying to avoid having to change the server side of things.. Because, I didn't want to depend on the server getting upgraded in order to allow joystick playing. The one big problem I see with sending one packet with the direction, is that it's possible to have it not make it to the server... I have found out that what I was doing was incorrect, because the move command takes a maximum of 4 units to move in + or - direction.. I was sending the whole adjustment in one packet, and the server was only adjusting my heading by 4 units.. I never noticed on servers that were not lagged, because of it was sending sufficient motion commands that it ended up evening out. But, when I'm lagged it results in a "loose/wiggly" heading controls.. I am working on fixing this problem, but, will have to wait until tommorow to test my thoughts. Bill Suetholz ----- Original Message ----- From: "Erik Andersson" To: Cc: Sent: Sunday, July 27, 2003 5:37 PM Subject: Re: Re: [Xpilot-hacks] Joystick abilities What if we change things so that the client sends wanted direction instead if relative turns to the server? (could remove disappearing turns from wallcollisions with already existing hack in 4.5.4X) Pros: easier to implement this joystick thing from what I can understand, possibly easier to play lagged if the client immediately can show what your direction _will_ be... some old hack tried to do this a couple of years ago iirc Cons: not sure, except maybe it would be easier to make some autoaim hacks etc. /virus _______________________________________________ Xpilot-hacks mailing list Xpilot-hacks@nslug.ns.ca http://nslug.ns.ca/cgi-bin/mailman/listinfo/xpilot-hacks From urpala at cc.helsinki.fi Mon Jul 28 09:11:21 2003 From: urpala at cc.helsinki.fi (Uoti A Urpala) Date: Sat Feb 14 14:09:47 2004 Subject: [Xpilot-hacks] Joystick abilities In-Reply-To: <000a01c354b7$d6eb0260$80fca8c0@WJSLAPTOP> "from William Suetholz at Jul 27, 2003 10:25:04 pm" Message-ID: <200307281211.h6SCBLk07323@sirppi.helsinki.fi> > I have found out that what I was doing was incorrect, because > the move command takes a maximum of 4 units to move in + or - > direction.. I was sending the whole adjustment in one packet, and You mean a single pointer move packet can only result in the ship turning by a maximum of 4 units? That's not true unless I've missed something in the code. If you're using the old mouse control mode (turnresistance != 0, you shouldn't use that), then there are limits for a single packet, but even then it's not a constant 4 units but dependent on exactly what your settings are. From wsuetholz at centonline.com Mon Jul 28 15:45:01 2003 From: wsuetholz at centonline.com (William Suetholz) Date: Sat Feb 14 14:09:48 2004 Subject: [Xpilot-hacks] Joystick abilities In-Reply-To: <200307281211.h6SCBLk07323@sirppi.helsinki.fi> References: <000a01c354b7$d6eb0260$80fca8c0@WJSLAPTOP> <200307281211.h6SCBLk07323@sirppi.helsinki.fi> Message-ID: <20030728134501.6d583b0f.wsuetholz@centonline.com> On Mon, 28 Jul 2003 15:11:21 +0300 (EET DST) Uoti A Urpala wrote: > > I have found out that what I was doing was incorrect, because > > the move command takes a maximum of 4 units to move in + or - > > direction.. I was sending the whole adjustment in one packet, and > > You mean a single pointer move packet can only result in the ship > turning by a maximum of 4 units? That's not true unless I've missed > something in the code. If you're using the old mouse control mode > (turnresistance != 0, you shouldn't use that), then there are limits > for a single packet, but even then it's not a constant 4 units but > dependent on exactly what your settings are. I am presently changing code in the 4.5.4X-1 branch of xpilot. So, I don't know exactly what you mean by old code? What I reported is the observed behavior, by examining the heading changes that happened when trying to adjust the heading. I have not looked into the server code at all. I was actually planning to make an option in the joystick code to indicate the maximum turn units to send. I'm not sure if I was connecting to a 4.5.4X-1 server or a 4.5.4 server when I did the tests. Hopefully, I will get a chance to look into this more tonight. Bill Suetholz From urpala at cc.helsinki.fi Mon Jul 28 16:43:32 2003 From: urpala at cc.helsinki.fi (Uoti A Urpala) Date: Sat Feb 14 14:09:48 2004 Subject: [Xpilot-hacks] Joystick abilities In-Reply-To: <20030728134501.6d583b0f.wsuetholz@centonline.com> "from William Suetholz at Jul 28, 2003 01:45:01 pm" Message-ID: <200307281943.h6SJhXu02439@sirppi.helsinki.fi> William Suetholz wrote: > > > the move command takes a maximum of 4 units to move in + or - > > You mean a single pointer move packet can only result in the ship > > turning by a maximum of 4 units? That's not true unless I've missed > > something in the code. If you're using the old mouse control mode > > (turnresistance != 0, you shouldn't use that), then there are limits > I am presently changing code in the 4.5.4X-1 branch of xpilot. So, I > don't know exactly what you mean by old code? What I reported is the Old mouse control _mode_, not code. Your turnresistance setting should be 0; if it isn't, you're using the old mode which has some strange "features". Turnresistance 0 is the default in the 4.5.4X-1 client, but if you have an .xpilotrc left from an old version of xpilot it might still contain an obsolete setting. > code to indicate the maximum turn units to send. I'm not sure if I > was connecting to a 4.5.4X-1 server or a 4.5.4 server when I did the > tests. It doesn't matter which server version it was. I created the new mouse control mode before the polygon stuff, and even the official versions have contained support for it for quite some time. If you connect to a really old server with turnresistance 0, you can't turn at all, so it's easily noticeable. From deity at home.se Tue Jul 29 14:25:22 2003 From: deity at home.se (Erik Andersson) Date: Sat Feb 14 14:09:48 2004 Subject: [Xpilot-hacks] Joystick abilities Message-ID: <1059499522.c837ec20deity@home.se> My original answer seems to have been lost =( >The one big problem I see with sending one packet >with the direction, >is that it's possible to have it not make it to the >server... Actually your example is an instance where sending wanted direction directly is advantagous: A lost relative turn effects the result of all concurrent relative turns until you die. A lost direction will be lost, but all subsequent turns will arrive unmolested as they incorporate all previous actions (the client keeps track of this) Relative turns actually makes life unnessessarily bad for players with lossy link. This could also be linked with a clientside indicator of your _will be_ direction, maybe making shiphandling easier on laggy servers. /virus From wsuetholz at centonline.com Tue Jul 29 20:21:55 2003 From: wsuetholz at centonline.com (William Suetholz) Date: Sat Feb 14 14:09:48 2004 Subject: [Xpilot-hacks] Joystick abilities In-Reply-To: <200307281943.h6SJhXu02439@sirppi.helsinki.fi> References: <20030728134501.6d583b0f.wsuetholz@centonline.com> <200307281943.h6SJhXu02439@sirppi.helsinki.fi> Message-ID: <20030729182155.3af4da6d.wsuetholz@centonline.com> On Mon, 28 Jul 2003 22:43:32 +0300 (EET DST) Uoti A Urpala wrote: > William Suetholz wrote: > > > > the move command takes a maximum of 4 units to move in + or - > > > > You mean a single pointer move packet can only result in the ship > > > turning by a maximum of 4 units? That's not true unless I've missed > > > something in the code. If you're using the old mouse control mode > > > (turnresistance != 0, you shouldn't use that), then there are limits > > > I am presently changing code in the 4.5.4X-1 branch of xpilot. > > What I reported is the observed behavior. > > Your turnresistance setting should > be 0; if it isn't, you're using the old mode which has some strange > "features". Turnresistance 0 is the default in the 4.5.4X-1 client, > but if you have an .xpilotrc left from an old version of xpilot it > might still contain an obsolete setting. > I did have turnresistance set to 0.12. When I set turnresistance to 0, I get uncontrollable movements in mouse mode. And, the same/similar behaviour in joystick mode. If it wasn't for the mouse mode acting the same, I would think that I really messed up the joystick stuff (which is probably true anyways :-). I still need to add in code to check to make sure that the heading got updated within a few frames, of sending the movement command. In mouse mode, just a little movement will result in spinning all the way around quickly with turnresistance at 0. Bill From wsuetholz at centonline.com Tue Jul 29 20:25:23 2003 From: wsuetholz at centonline.com (William Suetholz) Date: Sat Feb 14 14:09:48 2004 Subject: [Xpilot-hacks] Joystick abilities In-Reply-To: <1059499522.c837ec20deity@home.se> References: <1059499522.c837ec20deity@home.se> Message-ID: <20030729182523.2972784f.wsuetholz@centonline.com> On Tue, 29 Jul 2003 19:25:22 +0200 "Erik Andersson" wrote: > > My original answer seems to have been lost =( > > >The one big problem I see with sending one packet >with the direction, > >is that it's possible to have it not make it to the >server... > > Actually your example is an instance where sending wanted direction directly is advantagous: A lost relative turn effects the result of all concurrent relative turns until you die. A lost direction will be lost, but all subsequent turns will arrive unmolested as they incorporate all previous actions (the client keeps track of this) > Relative turns actually makes life unnessessarily bad for players with lossy link. > This could also be linked with a clientside indicator of your _will be_ direction, maybe making shiphandling easier on laggy servers. > Well, the delta based upon what the client thinks the heading SHOULD be does have the wrong heading problem.. This requires code to check the current heading on every frame, and after a certain number of frames, try adjusting the heading again.. This would be much simpler if there was a way to tell the server, that this is the new heading, rather than having to use relative movement commands. But, I still would like to get this done without modifications to the server code. Bill From pforman at rocketjets.com Tue Jul 29 19:20:59 2003 From: pforman at rocketjets.com (Paul Forman) Date: Sat Feb 14 14:09:48 2004 Subject: [Xpilot-hacks] Joystick abilities In-Reply-To: <20030729182155.3af4da6d.wsuetholz@centonline.com> Message-ID: On Tuesday, July 29, 2003, at 05:21 PM, William Suetholz wrote: >> Your turnresistance setting should >> be 0; if it isn't, you're using the old mode which has some strange >> "features". Turnresistance 0 is the default in the 4.5.4X-1 client, >> but if you have an .xpilotrc left from an old version of xpilot it >> might still contain an obsolete setting. >> > > I did have turnresistance set to 0.12. You've probably already discovered this, but if you set turnResistance to 0, you need to bring turnSpeed *way* down. It's such a normal thing for mouse players that it gets forgotten sometimes. Try your joystick code with a turnRes of 0 and a turnSpeed of around 10 before you decide it's broken... > When I set turnresistance to 0, I get uncontrollable movements in > mouse mode. And, the same/similar behaviour in joystick mode. If it > wasn't > for the mouse mode acting the same, I would think that I really messed > up the joystick stuff (which is probably true anyways :-). I still > need > to add in code to check to make sure that the heading got updated > within > a few frames, of sending the movement command. > > In mouse mode, just a little movement will result in spinning all the > way around quickly with turnresistance at 0. > > Bill > _______________________________________________ > Xpilot-hacks mailing list > Xpilot-hacks@nslug.ns.ca > http://nslug.ns.ca/cgi-bin/mailman/listinfo/xpilot-hacks > From wsuetholz at centonline.com Wed Jul 30 02:49:21 2003 From: wsuetholz at centonline.com (William Suetholz) Date: Sat Feb 14 14:09:48 2004 Subject: [Xpilot-hacks] Joystick abilities References: Message-ID: <001601c3565e$535a5790$80fca8c0@WJSLAPTOP> That would explain things.. Bill ----- Original Message ----- From: "Paul Forman" To: Sent: Tuesday, July 29, 2003 5:20 PM Subject: Re: [Xpilot-hacks] Joystick abilities > > On Tuesday, July 29, 2003, at 05:21 PM, William Suetholz wrote: > >> Your turnresistance setting should > >> be 0; if it isn't, you're using the old mode which has some strange > >> "features". Turnresistance 0 is the default in the 4.5.4X-1 client, > >> but if you have an .xpilotrc left from an old version of xpilot it > >> might still contain an obsolete setting. > >> > > > > I did have turnresistance set to 0.12. > > You've probably already discovered this, but if you set turnResistance > to 0, you need to bring turnSpeed *way* down. > > It's such a normal thing for mouse players that it gets forgotten > sometimes. > > Try your joystick code with a turnRes of 0 and a turnSpeed of around 10 > before you decide it's broken... > > > > When I set turnresistance to 0, I get uncontrollable movements in > > mouse mode. And, the same/similar behaviour in joystick mode. If it > > wasn't > > for the mouse mode acting the same, I would think that I really messed > > up the joystick stuff (which is probably true anyways :-). I still > > need > > to add in code to check to make sure that the heading got updated > > within > > a few frames, of sending the movement command. > > > > In mouse mode, just a little movement will result in spinning all the > > way around quickly with turnresistance at 0. > > > > Bill > > _______________________________________________ > > Xpilot-hacks mailing list > > Xpilot-hacks@nslug.ns.ca > > http://nslug.ns.ca/cgi-bin/mailman/listinfo/xpilot-hacks > > > > _______________________________________________ > Xpilot-hacks mailing list > Xpilot-hacks@nslug.ns.ca > http://nslug.ns.ca/cgi-bin/mailman/listinfo/xpilot-hacks > From deity at home.se Mon Jul 28 17:59:11 2003 From: deity at home.se (Erik Andersson) Date: Sat Feb 14 14:09:48 2004 Subject: [Xpilot-hacks] Joystick abilities Message-ID: <1059425951.4e5ff9e0deity@home.se> >The one big problem I see with sending one packet >with the direction, >is that it's possible to have it not make it to the >server... err that is actually an instance where sending direction directly is advantageous. The loss of a single turn (as it works now) will effect the result of all concurrent turns until the player dies, when sending turns directly only the disappearing turn will be affected, as the next turn will incorporate it. Infact from performance point of view sending turnchanges instead of wanted direction borders on being stupid ;) /virus /virus From wsuetholz at centonline.com Wed Jul 30 14:44:40 2003 From: wsuetholz at centonline.com (William Suetholz) Date: Sat Feb 14 14:09:48 2004 Subject: [Xpilot-hacks] Joystick abilities In-Reply-To: <1059425951.4e5ff9e0deity@home.se> References: <1059425951.4e5ff9e0deity@home.se> Message-ID: <20030730124440.6ef5c4a4.wsuetholz@centonline.com> On Mon, 28 Jul 2003 22:59:11 +0200 "Erik Andersson" wrote: > >The one big problem I see with sending one packet >with the direction, > >is that it's possible to have it not make it to the >server... > > err that is actually an instance where sending direction directly is advantageous. The loss of a single turn (as it works now) will effect the result of all concurrent turns until the player dies, when sending turns directly only the disappearing turn will be affected, as the next turn will incorporate it. > > Infact from performance point of view sending turnchanges instead of wanted direction borders on being stupid ;) > If you can point me to an existing command in the xpilot server that I can use to set the direction directly, I will use it. As I've said before, I want this to be able to be used without the server having to be upgraded. Later on, code can be added to check for the presence of a SetHeading type command in the server and use that if it's there, but, I don't see that command being there now. If it's stupid/silly to want a change to work on older servers, then I qualify. Bill Suetholz