Re: [crossfire] TODO list
them. But maybe this just goes back to me playing a troll character at one time, and having to deal with carrying large amounts of food (due to the trolls bonus is HP regeneration, food usage goes up). Fireborn have the same thing, they also need lots of food. So these two races need serious tweaking if food is removed as a stat (and I think wraiths as well, since they have the advantage of not requiring any food). I have had times where my fireborn was in trouble killing the monsters faster than food stat went down, so I would say that food is not too abuntant at all! Also, dragons' ability gains by food must be tweaked if food is reduced in any significant amount. and eat it like nothing has happened. Just adding some form of rotting would probably reduce available food by a bit. Indeed, this is nice. Of course, lembas etc might not rot at all and hearts and livers rot faster than apples or cooked meat... After one gets create food spells, food becomes moot anyway in any case (except the special food and dragons). -- --- | Juha Jäykkä, ju...@iki.fi | | http://www.maths.leeds.ac.uk/~juhaj | --- 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
That might be simpler. But a general evaluation of the skills, what they do, and if they can/should be adjusted/made more useful could be in order. Things like woodsmen doesn't have any skill levels IIRC, because there is no proper way to gain exp. As such, you gain it, and that is it. But one could see it having levels, so that as you gain levels, the amount forest slows you down decreases, where at some point you might not have any penalty. Woodsman has skill levels, as it does alchemy-like transformation and item identification, too. But I agree with the need to evaluate all skills and sort/clean stuff. Any volunteer? :) If not already in place, woodsmen would also be the natural skill for harvesting wood. Probably. Right now you could implement woodcutting through the harvesting stuff already. 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
Mark Wedel wrote: Alex Schultz wrote: Expand cooking to allow players to salt the meats and such? Perhaps make weight-reduction-enchanted containers have some kind of partial preservative magic? That would help trolls :) That could work. It may just be that for even normal characters, food consumption can be fairly high - reducing it by half across the board may not be a bad thing. I was just earlier today thinking that the woodsman skill is in addition to the fast moving in wooded terrain ability (does anyone actually use this?) an identification skill -- what if it also included the ability to cure and preserve meats so they don't spoil as fast? What about a skill to butcher corpses down into more stable food items, or is that just too gory? Or do we want to make all this a part of cooking? -- /* * * Otto J. Makela o...@iki.fi * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */ /* * * Computers Rule 0100 01001011 * * * * * * * * * * * * */ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] TODO list
Otto J. Makela wrote: Mark Wedel wrote: Alex Schultz wrote: Expand cooking to allow players to salt the meats and such? Perhaps make weight-reduction-enchanted containers have some kind of partial preservative magic? That would help trolls :) That could work. It may just be that for even normal characters, food consumption can be fairly high - reducing it by half across the board may not be a bad thing. I was just earlier today thinking that the woodsman skill is in addition to the fast moving in wooded terrain ability (does anyone actually use this?) an identification skill -- what if it also included the ability to cure and preserve meats so they don't spoil as fast? What about a skill to butcher corpses down into more stable food items, or is that just too gory? Mountaineering and woodsmen (movement bonus skills) get applied automatically, just like bargaining should. A player shouldn't need to explicitly use them. I could see several levels of cooking - woodsmen may allow basic preserving of flesh items (salt/smoke it for example) - this basically gets you a normal food item that won't rot. Cooking might be needed to make special food items (those that give some form of bonus). Or do we want to make all this a part of cooking? That might be simpler. But a general evaluation of the skills, what they do, and if they can/should be adjusted/made more useful could be in order. Things like woodsmen doesn't have any skill levels IIRC, because there is no proper way to gain exp. As such, you gain it, and that is it. But one could see it having levels, so that as you gain levels, the amount forest slows you down decreases, where at some point you might not have any penalty. If not already in place, woodsmen would also be the natural skill for harvesting wood. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] TODO list
I don't know a lot about Qt, but it looks like the big bonus is better cross platform stuff. POSIX doesn't define everything we use, as evidenced by a fair number of #idef platform type Forgot but you also gain multilinguage support through a nice mechanism - tr(Your text with %1).args(parameter), making it easy to see texts instead of obscure constants. I agree that should be primary focus - we can always toss lots of stuff in code, but unless it makes the game better to play, doesn't get us a lot. Yep, that's why C++ is in my various list. The problem is some maps are very food scarce, because of the monsters on them. But maybe this just goes back to me playing a troll character at one time, and having to deal with carrying large amounts of food (due to the trolls bonus is HP regeneration, food usage goes up). Priests at least have the odd case where they can create food. But I guess nethack had food. I think one change, relative to food, is for all flesh type things (which can be eaten as food) should have some time limit where they start to decompose/rot. I shouldn't be able to carry around an ogre leg for a week and eat it like nothing has happened. Just adding some form of rotting would probably reduce available food by a bit. Rotting could be fun, but depending on implementation you'd have multiple food parts similar but not merging because dropped-tick isn't the same... As for trolls, that's one disadvantage they have - need MUCH food. On the opposite, Devourer adepts almost don't use food... 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
On Mon, 18 Jan 2010 18:33:44 +0100 Nicolas Weeger nicolas.wee...@laposte.net wrote: I think one change, relative to food, is for all flesh type things (which can be eaten as food) should have some time limit where they start to decompose/rot. I shouldn't be able to carry around an ogre leg for a week and eat it like nothing has happened. Just adding some form of rotting would probably reduce available food by a bit. Rotting could be fun, but depending on implementation you'd have multiple food parts similar but not merging because dropped-tick isn't the same... We could always implement multiple timeouts for objects that would in this case specify how many were dropped on a given tick... not sure it's worth the bother, but just noting that that isn't an insurmountable issue. As for trolls, that's one disadvantage they have - need MUCH food. On the opposite, Devourer adepts almost don't use food... Expand cooking to allow players to salt the meats and such? Perhaps make weight-reduction-enchanted containers have some kind of partial preservative magic? That would help trolls :) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] TODO list
Alex Schultz wrote: On Mon, 18 Jan 2010 18:33:44 +0100 Nicolas Weeger nicolas.wee...@laposte.net wrote: I think one change, relative to food, is for all flesh type things (which can be eaten as food) should have some time limit where they start to decompose/rot. I shouldn't be able to carry around an ogre leg for a week and eat it like nothing has happened. Just adding some form of rotting would probably reduce available food by a bit. Rotting could be fun, but depending on implementation you'd have multiple food parts similar but not merging because dropped-tick isn't the same... We could always implement multiple timeouts for objects that would in this case specify how many were dropped on a given tick... not sure it's worth the bother, but just noting that that isn't an insurmountable issue. Another possibility is that each flesh has several different states - fresh, smelly, molding, rotting, and then gone. The scale may be 1-100, but each of those corresponds to a range (81-100 is fresh, 61-80 is smelly, etc) When you pick up a food item or otherwise cause a case where it would merge, you find something in the same state (moldy lets say) and average the results. For example, player has 2 moldy items with value of 44 - close to rotting. Picks up 1 item of moldy, but its value is 58 - just went into molding. So we take (44*2 + 58)/3 = 49 value for the 3 items Unless a player is really tracking time, they are unlikely to notice those adjustments. But one problem is that if a player has a big stack of smelly flesh that goes into moldy, it would make that moldy items fresher and they wouldn't go into rotting, like they should. Another thought, which probably works better, is that globally all food active in the game drops one category at once. EG, all flesh in the world goes from fresh to smelly at the same time, goes from smelly to moldy at same time, etc. In that way, they are all synced up in status - not realistic. A middle approach of all food decomposes in units of 5 may work better - you could still get the case of some food becoming fresher, but this may be less likely to happen. OTOH, one could just say that if the food is being merged together, it is effectively being stored in the same place, so that their state sort of does average (if you have 6 eggs that are month old and 6 eggs that are fresh and store them together, how fresh is that dozen eggs?) As for trolls, that's one disadvantage they have - need MUCH food. On the opposite, Devourer adepts almost don't use food... Expand cooking to allow players to salt the meats and such? Perhaps make weight-reduction-enchanted containers have some kind of partial preservative magic? That would help trolls :) That could work. It may just be that for even normal characters, food consumption can be fairly high - reducing it by half across the board may not be a bad thing. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] TODO list
Nicolas Weeger wrote: Hello. Considering the low feedback/participation on the list, I'm totally changing how I work :) Seems like a reasonable idea. I've made a list of stuff I plan to work on - I put it at: http://wiki.metalforge.net/doku.php/user:mwedel:todo Plus side is there doesn't seem to be much overlap between our lists. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] TODO list
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. Around one year ago I and another did an experiment converting to C++ and introducing Qt. It was never completed, mind you (but as a by-product there is the CRE tool in utils/), but it wasn't *too* bad to do. Making it build C++ mode was like 2h work. Introducing classes did take more time, though, but was doable too. I could probably dig the source code if needed, even if it is obsolete by now. Oh, and it did have dynamic archetype loading ;) (ie change an archetype in the tree, it'd pick up the change a few seconds later - worked for faces at least) But maybe yes rethinking the whole game architecture could be done taking the opportunity. Of course, not a 2 days project. And we would need to know the focus - modular design? robuste? performant? (and see next reply :)) 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. Correct. Various is more 'in some years', or 'never'. C++/Qt would be a real time-saver in the long run - don't have to redefine shared strings, many many free stuff - threads, sockets, and such. And using a tested library. But the first topic for me is gameplay / content. As long as no one is seriously working on that, I'll not do much on code, I think. Unless I get seriously bored with reinventing the wheel and just introduce Qt to have basic functions - and not change the current non class mode. But I wouldn't do that without having a consensus on the list - worse case I'd make my own branch and work still on content :) 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. IMO it adds some fun. And you could still eat some raw meat from monsters, when they give some. And you could introduce some fun diseases related to food - hum, that cow steak was good... err, why are you feeling crazy, suddenly? Or it could just be used to regenerate sp. But right now it's useless. 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
What would be redone with Qt ? anything GUI-related ? so the client(s) [which ones? cfclient ?] the map editors [which ones? cfeditor? or the java one or the gtk one?]? would you need/want to add some sort of server admin console? On Fri, Jan 15, 2010 at 1:16 PM, Nicolas Weeger nicolas.wee...@laposte.net wrote: 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. Around one year ago I and another did an experiment converting to C++ and introducing Qt. It was never completed, mind you (but as a by-product there is the CRE tool in utils/), but it wasn't *too* bad to do. Making it build C++ mode was like 2h work. Introducing classes did take more time, though, but was doable too. I could probably dig the source code if needed, even if it is obsolete by now. Oh, and it did have dynamic archetype loading ;) (ie change an archetype in the tree, it'd pick up the change a few seconds later - worked for faces at least) But maybe yes rethinking the whole game architecture could be done taking the opportunity. Of course, not a 2 days project. And we would need to know the focus - modular design? robuste? performant? (and see next reply :)) 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. Correct. Various is more 'in some years', or 'never'. C++/Qt would be a real time-saver in the long run - don't have to redefine shared strings, many many free stuff - threads, sockets, and such. And using a tested library. But the first topic for me is gameplay / content. As long as no one is seriously working on that, I'll not do much on code, I think. Unless I get seriously bored with reinventing the wheel and just introduce Qt to have basic functions - and not change the current non class mode. But I wouldn't do that without having a consensus on the list - worse case I'd make my own branch and work still on content :) 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. IMO it adds some fun. And you could still eat some raw meat from monsters, when they give some. And you could introduce some fun diseases related to food - hum, that cow steak was good... err, why are you feeling crazy, suddenly? Or it could just be used to regenerate sp. But right now it's useless. 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
No, not client or GUI-related. Nicolas means to use it as a utility library for C++, along the lines of the Boost libraries (which I personally thing are better suited) On Fri, 2010-01-15 at 13:52 -0500, Dany Talbot wrote: What would be redone with Qt ? anything GUI-related ? so the client(s) [which ones? cfclient ?] the map editors [which ones? cfeditor? or the java one or the gtk one?]? would you need/want to add some sort of server admin console? On Fri, Jan 15, 2010 at 1:16 PM, Nicolas Weeger nicolas.wee...@laposte.net wrote: 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. Around one year ago I and another did an experiment converting to C++ and introducing Qt. It was never completed, mind you (but as a by-product there is the CRE tool in utils/), but it wasn't *too* bad to do. Making it build C++ mode was like 2h work. Introducing classes did take more time, though, but was doable too. I could probably dig the source code if needed, even if it is obsolete by now. Oh, and it did have dynamic archetype loading ;) (ie change an archetype in the tree, it'd pick up the change a few seconds later - worked for faces at least) But maybe yes rethinking the whole game architecture could be done taking the opportunity. Of course, not a 2 days project. And we would need to know the focus - modular design? robuste? performant? (and see next reply :)) 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. Correct. Various is more 'in some years', or 'never'. C++/Qt would be a real time-saver in the long run - don't have to redefine shared strings, many many free stuff - threads, sockets, and such. And using a tested library. But the first topic for me is gameplay / content. As long as no one is seriously working on that, I'll not do much on code, I think. Unless I get seriously bored with reinventing the wheel and just introduce Qt to have basic functions - and not change the current non class mode. But I wouldn't do that without having a consensus on the list - worse case I'd make my own branch and work still on content :) 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. IMO it adds some fun. And you could still eat some raw meat from monsters, when they give some. And you could introduce some fun diseases related to food - hum, that cow steak was good... err, why are you feeling crazy, suddenly? Or it could just be used to regenerate sp. But right now it's useless. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] ___ 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
Re: [crossfire] TODO list
No, not client or GUI-related. Nicolas means to use it as a utility library for C++, along the lines of the Boost libraries (which I personally thing are better suited) Indeed, I meant server-side. Client-side is JXClient IMO :) Nicolas On Fri, 2010-01-15 at 13:52 -0500, Dany Talbot wrote: What would be redone with Qt ? anything GUI-related ? so the client(s) [which ones? cfclient ?] the map editors [which ones? cfeditor? or the java one or the gtk one?]? would you need/want to add some sort of server admin console? On Fri, Jan 15, 2010 at 1:16 PM, Nicolas Weeger nicolas.wee...@laposte.net wrote: 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. Around one year ago I and another did an experiment converting to C++ and introducing Qt. It was never completed, mind you (but as a by-product there is the CRE tool in utils/), but it wasn't *too* bad to do. Making it build C++ mode was like 2h work. Introducing classes did take more time, though, but was doable too. I could probably dig the source code if needed, even if it is obsolete by now. Oh, and it did have dynamic archetype loading ;) (ie change an archetype in the tree, it'd pick up the change a few seconds later - worked for faces at least) But maybe yes rethinking the whole game architecture could be done taking the opportunity. Of course, not a 2 days project. And we would need to know the focus - modular design? robuste? performant? (and see next reply :)) 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. Correct. Various is more 'in some years', or 'never'. C++/Qt would be a real time-saver in the long run - don't have to redefine shared strings, many many free stuff - threads, sockets, and such. And using a tested library. But the first topic for me is gameplay / content. As long as no one is seriously working on that, I'll not do much on code, I think. Unless I get seriously bored with reinventing the wheel and just introduce Qt to have basic functions - and not change the current non class mode. But I wouldn't do that without having a consensus on the list - worse case I'd make my own branch and work still on content :) 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. IMO it adds some fun. And you could still eat some raw meat from monsters, when they give some. And you could introduce some fun diseases related to food - hum, that cow steak was good... err, why are you feeling crazy, suddenly? Or it could just be used to regenerate sp. But right now it's useless. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] ___ 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 -- 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
Nicolas Weeger wrote: 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. Around one year ago I and another did an experiment converting to C++ and introducing Qt. It was never completed, mind you (but as a by-product there is the CRE tool in utils/), but it wasn't *too* bad to do. Making it build C++ mode was like 2h work. Introducing classes did take more time, though, but was doable too. I could see that - C code in general should compile under C++, but there may be a few areas where it doesn't. But just making it compile under C++ doesn't get a lot. To be really valuable, conversion to classes, etc, is likely needed, and that is a much bigger project. And the question then is whether it is worth it to try to convert the existing code base (structure by structure) or start with something new, with perhaps lots of copy/pasting, but also proper/better design in how the classes and like interact. 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. Correct. Various is more 'in some years', or 'never'. C++/Qt would be a real time-saver in the long run - don't have to redefine shared strings, many many free stuff - threads, sockets, and such. And using a tested library. I don't know a lot about Qt, but it looks like the big bonus is better cross platform stuff. POSIX doesn't define everything we use, as evidenced by a fair number of #idef platform type But the first topic for me is gameplay / content. As long as no one is seriously working on that, I'll not do much on code, I think. I agree that should be primary focus - we can always toss lots of stuff in code, but unless it makes the game better to play, doesn't get us a lot. 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. IMO it adds some fun. And you could still eat some raw meat from monsters, when they give some. And you could introduce some fun diseases related to food - hum, that cow steak was good... err, why are you feeling crazy, suddenly? Or it could just be used to regenerate sp. But right now it's useless. The problem is some maps are very food scarce, because of the monsters on them. But maybe this just goes back to me playing a troll character at one time, and having to deal with carrying large amounts of food (due to the trolls bonus is HP regeneration, food usage goes up). Priests at least have the odd case where they can create food. But I guess nethack had food. I think one change, relative to food, is for all flesh type things (which can be eaten as food) should have some time limit where they start to decompose/rot. I shouldn't be able to carry around an ogre leg for a week and eat it like nothing has happened. Just adding some form of rotting would probably reduce available food by a bit. ___ 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
[crossfire] New crossfire todo list
I've taken a bit of time to go through and make a new todo list of most things that need to be done: http://wiki.metalforge.net/doku.php/dev_todo_new There is still more stuff to add. It's unclear at what complexity level something should be there, vs a bug on the tracker or just go and do it, but I'll think more about that later. I also see that as becoming the definitive TODO list, replacing the one in the server directory which is always out of date, and doesn't really provide much in the way of tracking. I've added comments to a fair number of the items there. In no way does that mean that is the definitive, or even correct, way of doing it. I was mostly just trying to gather the useful bits from past mails, etc, and put it there vs sitting in my mailbox. I'd also suggest that it is generally better to actually pull out the useful bits of the conversation and put them in the wiki vs referring to the mailing list - too often, it may be a thread of 50 messages, with most not providing much useful info - its a bit more handy to just be able to see the main points. A few notes/questions. In looking through the TODO list in the server, some questions about these points: If a shop is placed in a random map (special map), the objects below the shop wall stick around - normally not much a problem, unless it is placed in a glory hole (treasure level), in which case coins are now beneath the wall. (I seem to recall seeing a recent commit that may have fixed this?) Change code so that if a player kills another player, he gets no exp (I recall seeing discussions about this, but don't see anything in the settings to suggest that this has been done?) Allow possibility of one players magic not harming another player (isn't this what the friendly fire option does, so this should be removed?) Ability for stores to set different prices for goods (The shopitems code only affects how much you can sell stuff for, not buy stuff, correct? If so, this is still valid) - Change inscription - instead of looking at range field of the player, have the spell to be inscribed part of the inscription command, eg 'inscribe scroll of identify' (is this still something that needs to be done?) - Generalize the code better - split between 'rules' and 'engine' (see TODO for more info - wonder if we really want to go that route - the code re-orgs as suggested is different from this, so maybe it just goes away as something TODO?) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] New crossfire todo list
Mark Wedel wrote: - Change inscription - instead of looking at range field of the player, have the spell to be inscribed part of the inscription command, eg 'inscribe scroll of identify' (is this still something that needs to be done?) Yes. When inscribing spell scrolls, one needs to do something along the lines of mark scroll-to-inscribe-over; cast meteor swarm; use_skill inscription. The change suggested there would make it so one would use something like mark scroll-to-inscribe-over; use_skill inscription meteor swarm instead. - Generalize the code better - split between 'rules' and 'engine' (see TODO for more info - wonder if we really want to go that route - the code re-orgs as suggested is different from this, so maybe it just goes away as something TODO?) Personally I don't think we want to go that route, however the suggested code re-orgs such as what I proposed a while back in the mailing list, would as a side affect make splitting the 'rules' and 'engine' easier, if at any point we decided we wanted to. IMHO we should do the code re-orgs and decide if we want to split the 'rules' and 'engine' after. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] New crossfire todo list
Alex Schultz wrote: Mark Wedel wrote: - Change inscription - instead of looking at range field of the player, have the spell to be inscribed part of the inscription command, eg 'inscribe scroll of identify' (is this still something that needs to be done?) Yes. When inscribing spell scrolls, one needs to do something along the lines of mark scroll-to-inscribe-over; cast meteor swarm; use_skill inscription. The change suggested there would make it so one would use something like mark scroll-to-inscribe-over; use_skill inscription meteor swarm instead. This should probably be taken to the next step, with the client providing some nicer dialogue for this, eg, a menu item like 'inscribe scroll'. The client would then present list of possible items (based on client type attribute) and list of spells, and player chooses. Of course, the client still has to send the actual request to the server, and the server would still have to validate if it works. Thinking about this, the logic for this on the server side could actually do most of the work with very little changes. Eg, client does something like: C-S: inscribe scroll tag spell name/identifier The server side command for that could find the object of scroll tag, save away current marked object, mark the scroll object, store away current ready spell, ready new spell, call inscribe code, and then put back the marked object and ready spell. OTOH, would probably be better for the inscribe code to take the inscribe to object and spell object and just go from that, as that would be cleaner. I am really thinking, however, that having the client handle most of the presentation of this is the better way to go. - Generalize the code better - split between 'rules' and 'engine' (see TODO for more info - wonder if we really want to go that route - the code re-orgs as suggested is different from this, so maybe it just goes away as something TODO?) Personally I don't think we want to go that route, however the suggested code re-orgs such as what I proposed a while back in the mailing list, would as a side affect make splitting the 'rules' and 'engine' easier, if at any point we decided we wanted to. IMHO we should do the code re-orgs and decide if we want to split the 'rules' and 'engine' after. And I'm not sure how much reason there is to split the rules and engine in any case. But if it is easy to do that, that could help in the testing actions perhaps. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] New crossfire todo list
Mark Wedel wrote: This should probably be taken to the next step, with the client providing some nicer dialogue for this, eg, a menu item like 'inscribe scroll'. The client would then present list of possible items (based on client type attribute) and list of spells, and player chooses. Of course, the client still has to send the actual request to the server, and the server would still have to validate if it works. Thinking about this, the logic for this on the server side could actually do most of the work with very little changes. Eg, client does something like: C-S: inscribe scroll tag spell name/identifier The server side command for that could find the object of scroll tag, save away current marked object, mark the scroll object, store away current ready spell, ready new spell, call inscribe code, and then put back the marked object and ready spell. OTOH, would probably be better for the inscribe code to take the inscribe to object and spell object and just go from that, as that would be cleaner. I am really thinking, however, that having the client handle most of the presentation of this is the better way to go. Actually, I'd be inclined to do something such as a more general skill-usage protocol. Something like: C-S: client_use_skill skill name/identifier [ob1:object tag] [ob2:object tag] [spell:spell name/identifier] [message:text lengthtext] Which could be used to make clientside menus for other skills and such things. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] TODO list items.
With crossfire release methodology slowly moving forward (I think one way or another we'll have figured out what we're doing in terms of a SCCS system by weeks end), I thought it was time to look at some of the TODO lists. Most of these are from the wiki or one in the server directory I want to try to keep this somewhat shorter, so basically a list of things to do and when to do them. The list below is just a quick first pass I did - almost certainly not complete, and just basic gut feelings on target version and priority. I'm putting this out for the purpose of discussion. change: briefly, what the change is. target release: 1.x (minor release), 2.0 (next major release), 3.0 (major release after next). Anything with 1.x is presumed it will be completed before 2.0 and thus 2.0 will include it, if it is a high priority feature. Some determination on target release is how big a change I think it is - if I think the change may be small enough to go in a minor release, I have a 1.x target. priority: How important a change is. If another change depends on the first one, that will also result in the first one having a higher priority. Priority is from 1 to 3, one being the highest. Basically: 1 - Something that must be done, or prerequisite for something else 2 - Should really be done, but not critical to game play. 3 - nice to have feature, but if not done, not critical. Many of these may really be a 3.0 targets. Enhancements vs fixing known problems are most likely to be in this category. The different items should in general also be done in the priorities listed - P1 before P2, P2 before P3. Change Target Release Priority Fix/Revamp sound2.0 2 Ambient music 2.0 3 Fix Weather 1.x?2 Improve lighting2.0 2 Changes to the clients (better ui) ? 1 (more details on what is meant by this is needed) New character creation method 2.0 1 Game Balance2.0 1 Land Plots 1.x 3 Code Cleanup2.0 1 Better NPC logic1.x?1 Add Kandora maps1.x 3 Map Cleanup (more details?) 1.x?3? Big worldify pupland1.x?2 Auction house map? 1.x?3? archetype cleanup (remove old params so no 1.x?1 legacy loader code needed) Buildable shops 2.0 3? Newspaper (script based)1.x?3? Player clothing (image change based on clothing) 3.03? Time of day based events2.0 2 Player economy 3.0?2 Quest management system 2.0 1 Improved player communications 3.0 2 Performance improvements (lots of spells on 1.x 1 map causes performance hit) Thread the server 3.0 2 Make slaying more consistent2.0 2 Change speed of players (high levels players2.0 2 move way too fast) Improve NPC communication (tag keywords so 2.0 3 are more obvious to players) discrete attack damage (dam_fire, dam_cold.)2.0 3 ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] TODO list items.
I won't comment on the priority, just other things :) Better NPC logic 1.x?1 Can be scripted. I'm no mapmaker, but if someone gives me the flow of the dialog I can write the script. I could look at adding utility functions to help write such dialogs, too. (Daimonin does that, I think) Newspaper (script based) 1.x?3? Can already be done, but no one actually did it... (may require scripts to access timeofday stuff, but not that hard) Player clothing (image change based on clothing) 3.0 3? Would require many graphics artists, though, and already many things to redo first :) Time of day based events 2.0 2 See newspaper :) Make slaying more consistent 2.0 2 What do you mean by that? discrete attack damage (dam_fire, dam_cold.) 2.0 3 Hu? Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] TODO list items.
Nicolas Weeger (Laposte) wrote: I won't comment on the priority, just other things :) Better NPC logic 1.x?1 Can be scripted. I'm no mapmaker, but if someone gives me the flow of the dialog I can write the script. I could look at adding utility functions to help write such dialogs, too. (Daimonin does that, I think) I think for NPC logic, it should be termed monster logic really. I think that is what it is talking about. So what I'd see if monsters being smarter on what attacks they choose, finding a path to the player (right now, I think they just pretty much do a straight path logic, so easy to duck around a wall and never have them get to you), sensibly use healing spells, etc. OTOH, some of these depends on other issues - as long as monsters have 10x the number of HP as players, most healing spells will be pretty pointless for them. Newspaper (script based) 1.x?3? Can already be done, but no one actually did it... (may require scripts to access timeofday stuff, but not that hard) Probably also needs more detail in terms of what information it will actually present. As it is now, it is relatively vague in terms of what it would do. Player clothing (image change based on clothing) 3.0 3? Would require many graphics artists, though, and already many things to redo first :) Which is why I put it as 3.0. And at some level, given the relatively small image sizes, might be really hard to distinguish (most if the images for actual equipment uses the full 32x32 pixels, and thus just can't be overlayed on top of the image for the characters. A perhaps easier thing would be using different color channels (or whatever) so that the color of clothing could be changed - eg, you get a new color key to use. So you don't need seperate images for a red mage vs a blue mage, just a different color key. The problem is that has to get communicated down to the client, which means revising the protocol. And, unlike animations and smoothing, which are basically image/archetype attributes and only need to be sent once, color keys (or clothing changes) is an object attribute - could have bunch of different mages currently in the game with different colored garb. Time of day based events 2.0 2 See newspaper :) Depends on the level and commonality of the events. The most basic use of this I would see would be exits (shops) closing at night and opening during the day. Could be certain places (taverns) that only open at night. Scripts could be used for that, but sort of back to some previous things, if we are looking to use that a lot, may make sense to have an easier hook (or need common scripts, so that you don't need need to write a custom one for each shop). Secondarily would be NPCs saying different things. I think scripts may be needed for that. Also, having the different connected values based on time. It would make sense that the scorn gate is open during daylight hours, but closing during the night. But like a lot of these, exactly how it is done isn't as important. If these can be easily done with scripts, thats great, but those scripts still need to be written, tested, etc. Saying it can be done with scripts isn't that much different than saying 'it can be written in C code' - that code still needs to be written :) Make slaying more consistent 2.0 2 What do you mean by that? From the TODO list: Slaying is sloppy in that it uses strstr. This, an item that has 'slaying giant' (like holyword of mostrai) will kill ants. strstr matching was most likely added to support comma seperated slaying lists (slaying demon,undead). However, the code should really insist on exact matching, and if necessary break apart the comma seperated list. Probably best to make something like a 'does_slay()' function which can be used all over the place (consistent behaviour is a good thing). If performance for this becomes an issue, making a slaying a set of pointers could be done (char **slaying), and it gets filled in at load time, and at save time, gets filled in the opposite direction. However, from a simple basis, a check in does_slay() can be done to see if slaying does contain a comma, and if not, just do simple strcmp, and only if it does does extra work need to be done. MSW 2003-03-28 discrete attack damage (dam_fire, dam_cold.) 2.0 3 Hu? Right now, if you have a weapon that has attacktype physical fire, and dam 40, it will do dam 40 of whatever attack works best against the creature. It is fairly common in most games that extra attacktypes do some extra damage. Eg, this weapon does 20 physical damage and 10 fire damage. There isn't any way to do that right now (ok, maybe with scripts :), but that isn't really the point here). The effect
