On Sat, Feb 23, 2008 at 12:53:13AM -0500, Bill Balcerski wrote: > /* Start patch description */ > * lame refit [...] > /* End patch description */ > > I would strongly > urge community review of this patch and would like to know the > opinions of the Bronco server operators as to whether they support > this change to refit. I support the change as a SYSDEF option, and so I accepted the patch. I don't have any need for the option on the two servers that I'm operating. I agree that the original code was probably a mistake, having reviewed the earliest sources that my research assistant could uncover. I've also researched xtrek 1.2, which already had p_shield and p_damage, and p_damage increased with damage done, same as with Netrek. It does seem possible that the implementation of refit restrictions was done wrongly. Either way, I could not find anything conclusive as to how it was to be designed. > On a minor note, clients with a repair/refit > timer will be broken if there is a server configurable refit time > without a feature packet to tell the client about the refit criteria, > as refit conditions are hard coded into some clients. Please fix this. We can't have these clients misbehave as a result of a server side policy change. On Sat, Feb 23, 2008 at 01:37:54AM -0500, Karthik Arumugham wrote: > What clients have a refit condition coded into them? Ideally refit timer support should be supplied by the server, so that this situation need not occur again with the next change. On Sat, Feb 23, 2008 at 07:16:19AM -0500, Bill Balcerski wrote: > What I object to is that there are certain numeric gameplay values > that are ingrained into clue players, and affect how we play. [...] Yes, but they can change, or they wouldn't be clue. > At the very least, the > refit rules should be in the server options so a player doesn't have > to guess as to the refit rules every time the play. The client should display the refit rules at the time of refit opportunity. > For things existing in a blessed client > already, I didn't see the need to feature packet it. I'd like to see those other clients have feature packets added, or if they cannot comply with current development schedules remove their key. On Sat, Feb 23, 2008 at 02:30:29PM +0100, Rado S wrote: > This applies to so many features that could be changed by sysdef or > code hacks... but there is only limited space to display it all. > What's important to list first until the space runs out? Yes, that's a challenge. How not to make some things appear more important just because some developer was concerned about them. Not you, Rado. > > From Paradise 2000 README: > Please, can we focus on replacing that with a more useful standard > P-client rather than using this as a reference for anything? > Avoid any reference to it in the future, thank you. While the key is present and people use it, I think we need to continue to refer to it as necessary. > > On Sat, Feb 23, 2008 at 1:37 AM, Karthik Arumugham <karthik at karthik.com> wrote: > > > It would be nice if the current key maintainer would review the > > > features being added to clients instead of simply blindly > > > issuing keys, as well. (No offense intended, Carlos; I know you > > > don't really have too much extra time to spend on Netrek, but we > > > DO need reviews of things like this before issuing keys.) > > Why does this sound so familiar to me? > I guess because I raised this issue some months ago. > Is there _now_ enough need for a change? Nothing has changed in the situation, except a few people have made patches and some others have noticed them. If you can out-do the current key maintainer and convince all server operators to follow your key list, go ahead. I don't see that as likely. Carlos at least has our trust. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/