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