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] Conventions for exits in town
I think as much as anything else, the meaning of the exit (based on appearance) should be consistent. Yes, indeed. For example, stairs no matter where they are, should require an explicit apply to use them Oak doors could always be auto apply, etc. Buildings are always explicit apply, and so on. I'd say explicit apply for all things you'd expect to use/apply in real life: doors, stairs, ladders, boats, ... On the other hands, things like teleporters, shop mats, whirlwind exits aren't expected to need to be applied, IMO. So as a player, if I see an oakdoor, I know what it will (or won't do) no matter where I am. Beyond that, having more consistency based on location sounds good. It may just mean updating all the maps to have the appropriate exit for their location. Yes, some massive update :) 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] TODO list
move to Qt/C++, to not reinvent the wheel all the time; and massively
clean the code
such as this:
(naive draft)
(the object superstructure need to be separated into a base 'object'
class - and then you'd have God : Object inheriting from it and adding
stuff specific to God that are in the former object superstructure in
the C code. Also I didn't check the code to rework the function
parameters - that is why it is called a naive draft).
#include iostream
#include global
#include living
#include object
#include spells
#include sounds
// TODO: other includes
/* TODO:
move
* Compares 2 strings.
* @param s1
* @param s2
* strings to compare.
* @return
* 1 if s1 and s2 are the same - either both NULL, or strcmp( ) == 0.
static int same_string(const char *s1, const char *s2) {
if (s1 == NULL)
return s2 == NULL;
else
return s2 != NULL strcmp(s1, s2) == 0;
}
to an utility function/class
*/
class God : Object
{
public:
// default constructor
Gods();
// default destructor
~Gods();
// operator overload '=='
// operator overload '='
// accesors
// modifiers
Archetype *determine_holy_arch(const Object *god, std::string type);
const God *find_god(std::string name);
const std::string determine_god(Object *op);
int become_follower(Object *op, const Object *new_god);
int tailor_god_spell(Object *spellop, Object *caster);
void pray_at_altar(Object *pl, Object *altar, Object *skill);
private:
const std::string get_god_for_race(std::string race);
int _follower_has_similar_item(Object *op, Object *item);
int _follower_level_to_enchantments(int level, int difficulty);
int _god_enchants_weapon(Object *op, const Object *god, Object
*tr, Object *skill);
int _god_examines_item(const Object *god, Object *item);
int _god_examines_priest(Object *op, const Object *god);
int _god_gives_present(Object *op, const Object *god, Treasure *tr);
int _god_removes_curse(Object *op, int remove_damnation);
int _improve_weapon_magic(Object *op, Object *tr, Object *weapon,
Object *skill);
int _lookup_god_by_name(std::string name);
int _worship_forbids_use(Object *op, Object *exp_obj, uint32 flag,
const std::string string);
void _follower_remove_given_items(Object *pl, Object *op, const
Object *god);
void _god_intervention(Object *op, const Object *god, Object *skill);
void _remove_special_prayers(Object *op, const Object *god);
void _stop_using_item(Object *op, int type, int number);
void _update_priest_flag(const Object *god, Object *exp_ob, uint32 flag);
};
On Thu, Jan 14, 2010 at 5:26 PM, Nicolas Weeger
nicolas.wee...@laposte.net wrote:
Hello.
Considering the low feedback/participation on the list, I'm totally changing
how I work :)
I've put my plans for the future at
http://wiki.metalforge.net/doku.php/user:ryo:todo and I intend to do them,
except maybe the Various ones.
If you have questions, feel free to ask me (this list or privately), but else
I'll just implement as I see fit and discuss after if needed :)
Nicolas
--
http://nicolas.weeger.org [Mon p'tit coin du web]
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
--
Dany Talbot, Quebec, Canada [ crystal...@gmail.com ]
Per aspera ad astra
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] TODO list
Dany Talbot wrote: move to Qt/C++, to not reinvent the wheel all the time; and massively clean the code I know someone sort of looked into doing crossfire in C++ several years back. Their opinion was it was probably easier to start writing the code from scratch vs trying to convert the existing code. I haven't looked at it enough to say for sure, but I could certainly see it may be easier to start from scratch but keep in archetype/map/player/protocol compatible. On the same basis, one could use that to clean up lots of bits of code that are their for compatibility reasons or because that is the way things should work - one could actually define how those things should work. But I suspect the stuff under Various is low priority - for the most part it cleans things up for developers, but doesn't really change the experience for players. As for other points - pretty much agree with them all. One question/comment however about: reduce food supply, like divide by 10 the current values?, to give more interest to food - right now it’s useless Most RPG's don't really concern themselves with the player needing to feed themselves. And in fact food as a rapidly decrease attribute is I'm sure something that dates back to early versions of crossfire, which were much more gauntlet based than an RPG. I wonder if part of reducing that food supply, of the food attribute should just be removed, and the sole purpose of food is to give various benefits, like some of the special foods do right now (give some healing, resistances, etc, for some time). Most normal food could be removed, except for dungeon dressing and perhaps some quests. Dying as starvation because you can't find food has to be one of the suckiest ways to die. And having to carry around huge quantities of food because you are going into a deep dungeon is also somewhat annoying (more annoying is realizing you are about out of food, have to abandon the dungeon, go back, get some more, etc). I guess my question would be whether food as a core stat really adds much to the game or is as much a headache as anything else. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Conventions for exits in town
Nicolas Weeger wrote: For example, stairs no matter where they are, should require an explicit apply to use them Oak doors could always be auto apply, etc. Buildings are always explicit apply, and so on. I'd say explicit apply for all things you'd expect to use/apply in real life: doors, stairs, ladders, boats, ... On the other hands, things like teleporters, shop mats, whirlwind exits aren't expected to need to be applied, IMO. And some things may be explicit just based on what they are. Things like pits you don't have much choice of - if there is a pit under you, you are falling. A question might be whether are exits, whether auto apply or not, should in general be visible. If you need to apply it, that is clearly the case, but for auto apply, it is more a question - on some maps, (front gate to scorn being one example) the exits are invisible and applied automatically. There are also some houses same way - you can't see the exits - you just happen to step on the right space and are back home. I'm sort of the opinion that all exits (unless meant to be hidden, like pit traps) should be visible. The reason for this is that exits are a game mechanism - its nice to know what will cause you to move from one place to the next. In real life (I know, always a bad example), when I leave my house and walk to the curb, I don't suddenly warp from one map to another as I get to the curb - it is a continuous flow. But in crossfire, you do suddenly get popped from one map to another, and that can be somewhat jarring. So as a player, if I see an oakdoor, I know what it will (or won't do) no matter where I am. Beyond that, having more consistency based on location sounds good. It may just mean updating all the maps to have the appropriate exit for their location. Yes, some massive update :) First step would be to make the archetypes consistent, which may now mean there are some duplicate archetypes. And writing scripts to find exits on maps which are changing the move_on would be easy enough. The hard part would be examining all of those to see if changing them to default (based on that exit) is reasonable - there could be some cases on why it was done some way, and changing it another way sort of break things. The other time consuming part is the standardization of exits (making all town exits oak doors). But I imagine something like 'sed s/invisible exit/oakdoor/' would take care of that pretty easily. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
