[CF-Devel] I have a few patches for you
crossfire-devel at archives.real-time.com
crossfire-devel at archives.real-time.com
Mon Dec 27 15:29:02 CST 2004
Took a quick look - a few comments:
Munteanu Eduard Gabriel wrote:
>
2) settings.diff
>
- now we can modify the behavior of stats rolling, by changing the
>
minimum and maximum sum of stats that can be rolled during character
>
creation, which can be achieved by editing the settings file
>
(min_initial_stats_sum, max_initial_stats_sum).
Seems reasonable. The comment about it could possibly take a large number of
rolls to get valid stats is reasonable, but in most cases, shouldn't be an issue.
The problem probably really occurs if the min stats is set to some value close
to the max threshold - if it is set to 133 for example, that means the average
stat roll for all the stats would 19.
That could take a very long time - I think it may be reasonable that if the
stat total is above some percentage of maximum allowed stats (90%?) to at least
print a warning.
Also, instead of hardcoding the value '7' in the load_settings for min values,
you should use the NUM_STATS value instead. Unlikely new stats will be added,
but you never no.
>
- when the server starts and loads settings, if the settings file is
>
misconfigured, the default behavior is to die by calling LOG(logLevel,
>
..., ...), where logLevel is llevFatal by default (but can be changed by
>
modifying INIT_LOAD_SETTINGS_LOGLEVEL).
I don't think I like that as a default.
The real case here is that different errors have different priorities. As
mentioned above, something like the stat average being too high might be a
warning, something like invalid values might be a warning (because it just falls
back to built in defaults), but there can certainly be cases where something
should really be fatal.
One real concern I have here is the potential for values currently in the
settings files to be obsoleted. This would mean a player using their old
settings file would find that there server no longer starts - this would be very
obnoxious for those servers that automatically restart on failure.
I think the default should be to log the errors, but not actually halt.
>
- janitorial work
>
3) sighup_reload_settings.diff
>
- this is highly experimental: the server now behaves differently when
>
it recieves a SIGHUP signal, by reloading the settings file (if there
>
are errors in the settings file, the server does _not_ die; here,
>
logLevel is llevError)
Don't like that as is - sighup right now is the only signal one can send to
the server to get it to shut down cleanly. Changing that behaviour is likely to
cause confusion.
Using another signal for the reload of data (sigusr1 perhaps) is more
reasonable. However, I'm not sure how much I like the idea - certainly, it is
convenient to be able to reload those values. However, at the same time, I'm
fearful that people will use it and get strange side effects and file bugs
against them, of which there may be no way to fix them - if you make a function
available, people then expect to be able to use it.
If sufficient disclaimers are placed perhaps it is then reasonable.
>
>
I hope my future patches will include both client and server side
>
changes that will allow, if the server administrator permits it, the
>
clients to manually setup their character's stats.
>
Please tell me if you liked this patch.
Other than those minor notes, it looks good.
_______________________________________________
crossfire-devel mailing list
crossfire-devel at lists.real-time.com
https://mailman.real-time.com/mailman/listinfo/crossfire-devel
More information about the crossfire
mailing list