Hi James. Thank you for taking the time to respond. Oh yes; I realize that most of us already have allocated our thin time resources. I fully expect to be handling any coding work on my own. Of you, and the list, I'm simply seeking advice, so that I spend my time productively, rather than trying something that I would know to be a bad idea if I had additional experience with the game. Particularly when considering your remarks about targeting, I'm beginning to feel that I will almost certainly need to use a modified server. If an automatic targeting calculation wouldn't be affective client-side, then I'd need to modify the server so that torpedoes have a homing function. The simple way that I've made smart/tracking projectiles/missiles work in other games is to have them always turn toward their target, but to restrict them with a maximum turning rate. That way, they're guided, and will hit someone that isn't avoiding, or is sitting stationary, but will only occasionally hit someone that is actively avoiding. Changing the way that torpedoes work would absolutely require me to change the server, unless this could be implemented as a configurable server option. I don't know too much about how server options work yet, or how/if clients are notified about game-specific mods yet, so don't know how practical that approach would be. As I have read through the guides, I've found places where people talk about cyborg clients. It seems like these clients do assist with aiming/targeting, unless I've misread. If targeting from a client was impractical, then I don't understand how cyborgs can be a bother in that regard. In Mactrek, there is a "l" key that seems to lock on to the nearest ship. Perhaps that is only for tracking/viewing purposes? I don't mean to dismiss your advice about targeting. I'm just trying to be sure that all options are out before I add server modifications to client modifications on the to-do list. *smile* If I must modify the server, also, then this means that Audiotrek/Sonictrek/what-ever will end up being a separate game. There is still value in that case, since I'm not having to start from scratch, but I'd hoped that I could find a way to have an audio client work with the regular Netrek. If I do need to fork off in to another project, do you think that I should consider one of the Netrek variants? I saw one called Paradise. I vaguely understand that there are some disagreements over how many ship types are available in that one, but, if I'm forking, I would have the option to restrict/customize that stuff, anyway. My reasoning for considering a variant like that is that it might give me a larger inventory of features to call upon, even if I strip some away in the final version of what I use. Will your client work with Paradise or other variants? Looking through your code, I think that I saw a reference in your ship capabilities module to the Galaxy cruiser that I remember is part of Paradise. Remember that, at least for now, I'm looking at the old tarball of our client. I'll get the newer version that you referenced today. Finally, one technical question about your client. The way that I'll probably begin work is to try to strip away as much of the high level code as possible until I'm left with the code that manages communication with the server. Looks like you keep most of that in client.py. Its also easy to see how you trap key presses in the main module, and how those simply call functions that transmit the appropriate message to the server. It isn't, however, obvious to me how events from the server are dispatched inside your code. For example, if some game object moves, or if someone sends a message, then client.py must switch control to a function in your client that responds to that like an event handler. I can't find these handlers, though. Lastly, is the Netrek client/server protocol documented somewhere outside of reverse-engineering the code? I've Googled quite a bit, but can't find it, if its out there. If it isn't, then I'm probably much better off building on your client.py module, rather than trying to create something myself. Thanks again for your experienced input. Bryan -----Original Message----- From: netrek-dev-bounces at us.netrek.org [mailto:netrek-dev-bounces at us.netrek.org] On Behalf Of James Cameron Sent: Tuesday, March 16, 2010 11:00 PM To: Netrek Development Mailing List Subject: Re: [netrek-dev] Audio-based Netrek Client G'day Bryan, Yes, I find the situation novel and the concept interesting, but I've an existing sighted community to protect and nurture, so I lack the time to become directly involved in your project idea. I've done technical work for the disabled population in Australia, some of it can be found at http://quozl.us.netrek.org/tad/ ... so I've a fair idea of what you are up against. Netrek could certainly be cast into an audio format, either as a side on two dimensional space (like the Doom or Quake you mentioned, with the player positioned within the space), or if suitable multi-channel audio equipment was available as a two dimensional space with axis perpendicular to the player, and the player outside the space on a third axis. A sighted player uses peripheral and near field vision for parallel assessment of object locations. Object positioning for blind players could be presented using one of those pixel line devices, when the object is selected from a list. An automatic targeting feature would either not be fair, or would not be effective. The latter is the most likely, in my opinion. Effectiveness is destroyed by dodging, and network latency. Yes, the simulation frame rate is controlled in ntserv/daemon.c, and we had a configuration option not so long ago that allowed this rate to be varied in a way that would vary the apparent physics of the game. The netrek-client-pygame is not in model view controller pattern, so you'll have a hard time isolating the view components. Not impossible, just hard. The client is updated about weekly at the moment; you must examine the darcs source repository for updates. The tar.gz releases are very infrequent. -- James Cameron http://quozl.linux.org.au/ _______________________________________________ netrek-dev mailing list netrek-dev at us.netrek.org http://mailman.us.netrek.org/mailman/listinfo/netrek-dev