Re: [crossfire] Character names, was Re: Changing connection texts
Even the old method of just releasing something every few months with version number++ worked out reasonably good. There was never a perfect version, but new features got out there, bugs would be found, etc. I might be more inclined to call it version 1.50 - the trunk has moved quite a bit from 1.12, but is still compatible with it (the way some things work is different). I'm not sure what the goal for 2.0 is - needs to be something realistic, but I could also see that where we are may be half way there. then every few months, make a new release - 1.51, 1.52, or maybe skip going to 1.60, 1.70, etc. if significant changes. Fine by me, as long as someone actually manages the releases :) Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Character names, was Re: Changing connection texts
Nicolas Weeger wrote: The release methodology sort of needs to be sorted out - if we plan to do a lot of cleanup (which may break things), I'd sort of like to do that before the first rc - typically you make an rc when you think you are about ready and are trying to sort out bugs. Otherwise, I could see various servers running that, and then when rc2, suddenly a lot more stuff gets broken because of code cleanup, which isn't really the way to move. We need someone willing to decide what needs to be fixed, and enforce the rules, create branches, things like that. Though to be honest, I'd suggest we just take current code, label it 1.90, and see what happens. Even the old method of just releasing something every few months with version number++ worked out reasonably good. There was never a perfect version, but new features got out there, bugs would be found, etc. I might be more inclined to call it version 1.50 - the trunk has moved quite a bit from 1.12, but is still compatible with it (the way some things work is different). I'm not sure what the goal for 2.0 is - needs to be something realistic, but I could also see that where we are may be half way there. then every few months, make a new release - 1.51, 1.52, or maybe skip going to 1.60, 1.70, etc. if significant changes. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Character names, was Re: Changing connection texts
I don't like the idea of putting an actual exit in the code or something - that could be pretty annoying if it is a section of code not executed very often, but someone runs into and causes the server to exit (really annoying for server admins who servers suddenly start exiting through no fault of their own) #ifdefs, if done on date, can at least be interesting - if the code ceases to compile, pretty clear something needs to be done, but at least running servers won't be directly affected. I wonder if just standardizing a comment to use might work - something like: /* Removeme - 2010-06-01 ... (not sure if the date should be the time of the comment, or targeted time to remove the code). At least in that way, a simple grep can be used to find all of those, and decide which of them qualify for removal. I was thinking of an exit() in the main() function directly, with a pointer to the code to remove :p The release methodology sort of needs to be sorted out - if we plan to do a lot of cleanup (which may break things), I'd sort of like to do that before the first rc - typically you make an rc when you think you are about ready and are trying to sort out bugs. Otherwise, I could see various servers running that, and then when rc2, suddenly a lot more stuff gets broken because of code cleanup, which isn't really the way to move. We need someone willing to decide what needs to be fixed, and enforce the rules, create branches, things like that. Though to be honest, I'd suggest we just take current code, label it 1.90, and see what happens. Probably so - and in the case of some patches/contributions, need to figure out if we're going to accept them or not - no reason for them to just sit in limbo. Yup, not nice for people. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Character names, was Re: Changing connection texts
I wonder if you could do that if #ifdef's :) Why #ifdef's? Just put the check in the code, at least it won't be forgotten! Yeah, no account support isn't hard, because that basically just uses the code that is there instead of the new code. So very simple, it is just having some legacy code sit around. Yup. Fair enough. I was thinking of going through and cleaning up a bunch of the protocol stuff - there are like 20 different setup options. Some are actual choices (mapsize, do you want lighting, etc). But a fair a number are related to protocol versions (I support these protocol commands - use them if possible) Seems ok. And while we're at it, let's ensure documentation is uptodate! :) That may not be a bad idea. It's been a _long_ time since any official release. I don't think 2.0 is ready right now for a release, but the amount of cleanup/fixes probably isn't huge. Then let's do 2.0rc1, and see what needs cleaning. Concentrating on serious issues first, and just declare 2.0 is the first in a branch of major changes, expect some issues to be around :) Related, maybe the various trackers (bug, patch, feature request) could be pruned / cleaned. Much stuff is really obsolete, I think. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Character names, was Re: Changing connection texts
Nicolas Weeger wrote: I wonder if you could do that if #ifdef's :) Why #ifdef's? Just put the check in the code, at least it won't be forgotten! I don't like the idea of putting an actual exit in the code or something - that could be pretty annoying if it is a section of code not executed very often, but someone runs into and causes the server to exit (really annoying for server admins who servers suddenly start exiting through no fault of their own) #ifdefs, if done on date, can at least be interesting - if the code ceases to compile, pretty clear something needs to be done, but at least running servers won't be directly affected. I wonder if just standardizing a comment to use might work - something like: /* Removeme - 2010-06-01 ... (not sure if the date should be the time of the comment, or targeted time to remove the code). At least in that way, a simple grep can be used to find all of those, and decide which of them qualify for removal. Fair enough. I was thinking of going through and cleaning up a bunch of the protocol stuff - there are like 20 different setup options. Some are actual choices (mapsize, do you want lighting, etc). But a fair a number are related to protocol versions (I support these protocol commands - use them if possible) Seems ok. And while we're at it, let's ensure documentation is uptodate! :) Yep - I noticed some things fairly out of date. That may not be a bad idea. It's been a _long_ time since any official release. I don't think 2.0 is ready right now for a release, but the amount of cleanup/fixes probably isn't huge. Then let's do 2.0rc1, and see what needs cleaning. Concentrating on serious issues first, and just declare 2.0 is the first in a branch of major changes, expect some issues to be around :) The release methodology sort of needs to be sorted out - if we plan to do a lot of cleanup (which may break things), I'd sort of like to do that before the first rc - typically you make an rc when you think you are about ready and are trying to sort out bugs. Otherwise, I could see various servers running that, and then when rc2, suddenly a lot more stuff gets broken because of code cleanup, which isn't really the way to move. Related, maybe the various trackers (bug, patch, feature request) could be pruned / cleaned. Much stuff is really obsolete, I think. Probably so - and in the case of some patches/contributions, need to figure out if we're going to accept them or not - no reason for them to just sit in limbo. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Character names, was Re: Changing connection texts
Yep - that is my next step or work.
The only complication in all of this is player name uniqueness. If we go
by the idea of storing player files as lower case names, so there can only
be one 'Mark' player on a server, regardless of capitalization (mark, mArk,
etc), ideally you want to convert all existing player files to be all lower
case.
Seems ok by me - any storage mechanism is ok as long as it works :)
The problems we run into is that tends not to be done/not clear what
'some time' is. 6 months? 3 years?
Add near your checking code:
if (current_date() = may 2010) {
LOG(llevError, obsolete code detected!\n);
exit(5);
}
Issue solved :)
But there are really 2 cases of legacy supported needed - legacy support
for login without the account support (for old clients), and player file
naming.
No account support shouldn't be too hard to compensate.
Clients can reply to arbitrary queries, IIRC - so just emulate accounts
through that.
The second one, as I note above, can be eliminated with some scripts.
The first one probably needs some support - maybe 6 months after we release
a client that supports it?
If it's on the trunk branch, I'd suggest to remove it after some days only.
Trunk is supposed to be unstable.
Or, another option I'd prefer, we forget 1.x, declare current trunk 2.0, and
then start fixing stuff.
Nicolas
--
http://nicolas.weeger.org [Mon p'tit coin du web]
signature.asc
Description: This is a digitally signed message part.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Character names, was Re: Changing connection texts
True - there is no migration plan/support. However, there are some number of servers right now that running trunk bits. But maybe we just state all trunk servers must convert over, and let them deal with any conflicts they have on their own. As I see it, first will be server-side support (which you started to implement), then client-side. So let's add a new use_account SETUP setting sent by clients. If set, use account mode, then use regular/current player login. Obviously add options in account management to link an character to an account :) And after some time remove legacy support. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Character names, was Re: Changing connection texts
Nicolas Weeger wrote: True - there is no migration plan/support. However, there are some number of servers right now that running trunk bits. But maybe we just state all trunk servers must convert over, and let them deal with any conflicts they have on their own. As I see it, first will be server-side support (which you started to implement), then client-side. So let's add a new use_account SETUP setting sent by clients. If set, use account mode, then use regular/current player login. Obviously add options in account management to link an character to an account :) Yep - that is my next step or work. The only complication in all of this is player name uniqueness. If we go by the idea of storing player files as lower case names, so there can only be one 'Mark' player on a server, regardless of capitalization (mark, mArk, etc), ideally you want to convert all existing player files to be all lower case. Otherwise you could get the case where I create a new character, and it is called Mark, and the save file is Mark.pl Now somone else goes and creates a character called mark, save file mark.pl. Because the existing save fail is not in all lowercase, the second one is valid. Now I can think of various ways to handle this - all new characters have save files all in lower case, but if old characters, we have legacy support and look for them in upper case. I'd rather just write a conversion script and tell server admins to run it, so we don't have to have that code around, which we know would only be used for transition. And after some time remove legacy support. The problems we run into is that tends not to be done/not clear what 'some time' is. 6 months? 3 years? But there are really 2 cases of legacy supported needed - legacy support for login without the account support (for old clients), and player file naming. The second one, as I note above, can be eliminated with some scripts. The first one probably needs some support - maybe 6 months after we release a client that supports it? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Character names, was Re: Changing connection texts
Looking at the code, something vaguely related here is character naming standards. Right now, character names are limited to letters and - or _, and the - or _ can not be the first letter. Spaces and numbers are not allowed. I can certainly understand spaces, as on unixlike systems, spaces in file names are a pain to deal with. But not sure why restrictions on numbers (like the - or _, I could perhaps see why we wouldn't want a character to start with number. But why shouldn't Mark99 be allowed? Ok by me to allow numbers. The other oddity (IMO) is that names are case sensitive. Thus, Mark and mark are 2 different characters. That to me isn't great. If I was adventuring with a person, I might remember their name, but probably wouldn't remember the details on its capitalization - it could be odd to find out the 'dave' I'm not adventuring with is not the same player as the 'Dave' I adventure with last week. Well, could make sense too, yes. So my suggestions on this: - Allow numbers in names - just the name can not start with a number. - Going forward, names should be unique in a case insensitive manner. The player can still choose variations on capitalization, you just can't have a 'mark' and 'Mark'. To handle that last one, simplest thing is to just store all character related files in a lower case version of the name (so Mark would be stored as mark/mark.pl for example). That's easy to do and solves the problem. The thing that is harder to solve is existing player files. Writing a script to rename them is straightforward. The hard part is dealing with any names that conflict (eg, server has existing Mark and mark). Unless I'm mistaking, there is no 1.x = 2.0 migration script for players, meaning people will have to restart their character. So name collision issues shouldn't matter. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Character names, was Re: Changing connection texts
Nicolas Weeger wrote: So my suggestions on this: - Allow numbers in names - just the name can not start with a number. - Going forward, names should be unique in a case insensitive manner. The player can still choose variations on capitalization, you just can't have a 'mark' and 'Mark'. To handle that last one, simplest thing is to just store all character related files in a lower case version of the name (so Mark would be stored as mark/mark.pl for example). That's easy to do and solves the problem. The thing that is harder to solve is existing player files. Writing a script to rename them is straightforward. The hard part is dealing with any names that conflict (eg, server has existing Mark and mark). Unless I'm mistaking, there is no 1.x = 2.0 migration script for players, meaning people will have to restart their character. So name collision issues shouldn't matter. True - there is no migration plan/support. However, there are some number of servers right now that running trunk bits. But maybe we just state all trunk servers must convert over, and let them deal with any conflicts they have on their own. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Character names, was Re: Changing connection texts
Nicolas Weeger wrote: Hello. One thing I did think of might be DM access - maybe the dm_file should use account name instead of/in addition to character name? It strikes me that if you are going to trust a player with dm access, you probably don't really care what character they are playing. Yes, makes sense. Looking at the code, something vaguely related here is character naming standards. Right now, character names are limited to letters and - or _, and the - or _ can not be the first letter. Spaces and numbers are not allowed. I can certainly understand spaces, as on unixlike systems, spaces in file names are a pain to deal with. But not sure why restrictions on numbers (like the - or _, I could perhaps see why we wouldn't want a character to start with number. But why shouldn't Mark99 be allowed? The other oddity (IMO) is that names are case sensitive. Thus, Mark and mark are 2 different characters. That to me isn't great. If I was adventuring with a person, I might remember their name, but probably wouldn't remember the details on its capitalization - it could be odd to find out the 'dave' I'm not adventuring with is not the same player as the 'Dave' I adventure with last week. So my suggestions on this: - Allow numbers in names - just the name can not start with a number. - Going forward, names should be unique in a case insensitive manner. The player can still choose variations on capitalization, you just can't have a 'mark' and 'Mark'. To handle that last one, simplest thing is to just store all character related files in a lower case version of the name (so Mark would be stored as mark/mark.pl for example). That's easy to do and solves the problem. The thing that is harder to solve is existing player files. Writing a script to rename them is straightforward. The hard part is dealing with any names that conflict (eg, server has existing Mark and mark). Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
