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] 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] 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] 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] 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
