MWedel just talked about a complete redesign in his
latest post. Things that are redesigned tend to be
broken for 1 or 2 years. I could be dead in 1 or 2
years, so could any of us. I'd rather not wait around.
--- Yann Chachkoff <[EMAIL PROTECTED]>
wrote:
> > I don't think it would be wise to rem
Yann Chachkoff wrote:
>> (and maybe include some metaserver filter to stop servers older than this
>> being included too).
>
> If protocol compatibility is to get broken, it is probably better to change
> the metaserver URL, so that versions 1.x and 2.x don't overlap.
When there was the metase
Brendan Lally wrote:
> the map command and map1 commands (map1a could be used exclusively)
> the item1 command (the C clients have long since used item2)
> spell conversion from the old spell system
> support for the old skill system.
> support for oldsocket mode (pippijn recently made a textmode
Yann Chachkoff wrote:
>>If someone want's to create a RPG engine crossfire, in my opinion, is not
>>the place to do it.
>>
>>
>It is the exact place where to discuss about what we want to do with
>Crossfire, being maintaining it in its current state, expanding it or making
>it more generi
> I'd be inclined to say that the quickest way to do that would be to have a
> deliberate compatibility break, not completely, but at least back to what is
> actually used.
>
I do agree with that. I think that fixing all the current bugs should be the
first priority, so that a solid 1.9 release
On 1/28/06, Yann Chachkoff <[EMAIL PROTECTED]> wrote:
> I'm not speaking about "theoretical developers" - I'm speaking about those
> who (hopefully) will still play with crossfire and its code long after we
> don't. I'm thinking about all the ideas that could get implemented much more
> easily o
> I don't think it would be wise to remove the hacks, the hacks make things
> work as they should.
Hacks are what the name imply: "dirty fixes". By "removing hacks", it simply
means "replacing them by something cleaner that does the same job". Which
benefits from code clarity, ease of debugging
I don't think it would be wise to remove the hacks,
the hacks make things work as they should.
If someone want's to create a RPG engine crossfire,
in my opinion, is not the place to do it. Crossfire is
a game in it's own right, we should be concerned with
our game, not some theoretical developer
Yann Chachkoff wrote:
>
> Of course, you may object that "this is pure conjecture, that would get only
> results on the long-term, if they ever get any". Sure - this is an important
> change. I think that it all comes down to asking the question: do we want to
> polish the current infrastructure, k
> In this I do not disagree with Tchize and Gros, however I am still
> unconvinced by the case for a complex API to enforce such separation,
I never suggested to make a complex API to enforce such separation. Quite the
contrary, I think that the API should be kept simple, organized and rather
s
> In this I do not disagree with Tchize and Gros, however I am still
> unconvinced by the case for a complex API to enforce such separation,
I never suggested to make a complex API to enforce such separation. Quite the
contrary, I think that the API should be kept simple, organized and rather
s
Le Jeudi 26 Janvier 2006 00:17, Miguel Ghobangieno a écrit :
> Yes, "spagetti code", if that's what you wish to call
> it. Some CF programmers, such as Cave, would like to
> beable to reuse their code without having to recopy
> and paste what they have allready done (which would
> create bloated co
On 1/25/06, Miguel Ghobangieno <[EMAIL PROTECTED]> wrote:
> Some CF programmers, such as Cave, would like to
> beable to reuse their code without having to recopy
> and paste what they have allready done (which would
> create bloated code if it was required).
The idea of separating the code into f
Yes, "spagetti code", if that's what you wish to call
it. Some CF programmers, such as Cave, would like to
beable to reuse their code without having to recopy
and paste what they have allready done (which would
create bloated code if it was required). Modules would
disallow this (bad) as they are n
Le Mercredi 25 Janvier 2006 13:16, Miguel Ghobangieno a écrit :
> We want to cross module boundries and there is no
aka spaghetti code
> reason for us to
> want 3rd party "module" additions (unless one is
> pro-proprietary).
>
no comment.
___
crossf
We want to cross module boundries and there is no
reason for us to
want 3rd party "module" additions (unless one is
pro-proprietary).
Modules would do 2 things: disallow use of code across
module boundries (as they aren't loaded yet), let
proproprietary addons be created and work over more
then 1
tchize wrote:
I agree that removing/disabling code is a valuable feature. I'm just not sure
that any of the methods either of us have talked about is really a good method.
From my point of view, making it really easy/convenient for developers to
disable code is less important than a method
Le Mardi 24 Janvier 2006 07:38, Mark Wedel a écrit :
>
> True, but a plugin for object actions would be a pretty critical piece of
> code
> - you just can't disable the players from applying all items (or not compile
> that bit) and have a working system.
>
'Using object' is a core feature
tchize wrote:
>> And for everyone out there currently using grep - download cscope and use
> that
>> - it is a vastly superior solution (even going to plugins or whatever else,
>> cscope is a very handy tool - just run 'cscope -R' in the top level
> directory.
>
> Am not sure it's a good id
Le Lundi 23 Janvier 2006 07:18, Mark Wedel a écrit :
>
> Well, one could change that behavior without resulting to plugins - to
give
> meaningful names to object types just requires an array that has the names.
I was just showing with plugins it would be easier then currently. Of course
the
David Delbecq wrote:
This gets especially messy if say 10 object types are complex enough that
they
really should be in their own module. So now you have those 10 separate
modules
+ common module for other 90 types. This then starts to get away from
making
things easy to find (is it in
Le Jeudi 19 Janvier 2006 07:44, Mark Wedel a écrit :
> For example, there are probably about 100 different object types out
there.
> So if we take the module example, you either get 100 different modules for
all
> those objects, or a fairly big/complex module that handles those 100
different
tchize wrote:
Le Mercredi 18 Janvier 2006 07:30, Mark Wedel a écrit :
However, I think if you start grouping all that stuff together, you start
loosing some of the advantages.
Depends once again on the size of things you regroup and how much they have in
common. if you start making 80 modu
Well enjoy raping the server.
I'm retiring from CF untill a certain unnamed feature
I was promised 1/2 a year ago (no not plots) is in.
See you soon or never.
--- Yann Chachkoff <[EMAIL PROTECTED]>
wrote:
> > Except that you are not working on one section of
> the
> code, you are restructuring th
> Except that you are not working on one section of the
code, you are restructuring the whole server into
diffrent modules. This means that if you develop in
cvs there will be breakage with any and everyone else
as you sweeping edits touch every facet of the glory
that is crossfire.
Well, the requ
Le Mardi 17 Janvier 2006 17:54, Miguel Ghobangieno a écrit :
>. How about
>adding things? It's fun, people don't get angry at you
>as you aren't breaking or throwing out what they've
>made aswell.
>
lot's of 'things' added did break things (weather code made the server simply
uncompilable in the
On 1/18/06, tchize <[EMAIL PROTECTED]> wrote:
> Having to grep throught to code to guess where you have to add your new
> features is a symptom of upcoming code management problems.
I agree on this point, however I suspect that much of this could be
avoided by simply shifting a few functions and #
Le Mardi 17 Janvier 2006 17:46, Miguel Ghobangieno a écrit :
>Did you not read my post. If you are screwing around
>with the code structure of the server then other
>programmers do have to wait untill you are done as
>they do not want their code to suddenly break when it
>intersects with your massi
Le Mardi 17 Janvier 2006 22:40, Yann Chachkoff a écrit :
>> Current idea? I must have missed something, I didn't know you decided,
>> above all the objections, to go
>
>ahead and rip apart the server anyway.
>
>Idea != Decision.
Thanks to specify Yann :)
>
>Besides that, I don't think anybody req
Le Mercredi 18 Janvier 2006 01:04, Miguel Ghobangieno a écrit :
>Try mucking in the linux kernel without grep, tell me
>how that goes.
>
I did, for school. And at that time the block device part of kernel was
considered a mess by most developpers. However i used grep far less then i
had to do wi
Le Mercredi 18 Janvier 2006 15:42, Miguel Ghobangieno a écrit :
>Except that you are not working on one section of the
>code, you are restructuring the whole server into
>diffrent modules. This means that if you develop in
>cvs there will be breakage with any and everyone else
>as you sweeping edit
Le Mercredi 18 Janvier 2006 07:30, Mark Wedel a écrit :
>
> However, I think if you start grouping all that stuff together, you start
>loosing some of the advantages.
>
Depends once again on the size of things you regroup and how much they have in
common. if you start making 80 modules for what
Except that you are not working on one section of the
code, you are restructuring the whole server into
diffrent modules. This means that if you develop in
cvs there will be breakage with any and everyone else
as you sweeping edits touch every facet of the glory
that is crossfire.
The C in CVS may
> Indeed. Just because the server can be modularized thus blocking any other
> new development whilst that
takes place doesn't mean it's a good idea.
There is no reason to block any other development. I suppose you know that the
"C" in "CVS" means "Concurrent" ?
> I for one frown on the idea o
> Oh if that's the case let me just commit all the mlab maps in their current
> uni-directory form over the objections of everyone else that prefers
> multi-directory. Know why I don't do that; because everyone else prefers
> multi-directory.
Did you need the permission of anybody to write thos
Gros wrote:
It actually depends on the level of control you want to grant to the plugins.
The most extreme case would be to export all the functions currently in the
code - to do that, you'll have to provide a wrapper for each function you
want to export. That's a lot of functions, but let's no
Oh if that's the case let me just commit all the mlab
maps in their current uni-directory form over the
objections of everyone else that prefers
multi-directory. Know why I don't do that; because
everyone else prefers multi-directory.
Try mucking in the linux kernel without grep, tell me
how that
Indeed. Just because the server can be modularized
thus blocking any other new development whilst that
takes place doesn't mean it's a good idea. I for one
frown on the idea of making the server slower and
blocking other development.
--- Yann Chachkoff <[EMAIL PROTECTED]>
wrote:
> > If this range
> Current idea? I must have missed something, I didn't know you decided, above
> all the objections, to go
ahead and rip apart the server anyway.
Idea != Decision.
Besides that, I don't think anybody requires your permission to code.
> Why should all work have to stop because YOU want to restr
> If this range of languages is increased, there is a danger that it would
> include languages outside the range of competence of the existing developers,
> or outside the range of languages which are well supported on some of
> crossfire's target platforms.
>
That is true - I'm not myself in fa
Current idea? I must have missed something, I didn't
know you decided, above all the objections, to go
ahead and rip apart the server anyway. I will be
waiting for my 3 thousand dollar cheque in the mail
(along with everyone else who would like to add new
stuff to CF but will have to wait untill yo
Why oh why do you want to do this useless crap? We
have a real game, we don't have to make an "engine".
How about adding some new features rather then ripping
the things apart. This is why I hate CF devel, rather
then improving the game most suggestions are "oh let's
fuck shit up or delete this or
Did you not read my post. If you are screwing around
with the code structure of the server then other
programmers do have to wait untill you are done as
they do not want their code to suddenly break when it
intersects with your massive changes. You must not be
at all experianced in these matters (a
How about not modularizing and thus not having to make
a trade off.
How about not screwing up the server for months just
because you are itchting for busy work.
--- Yann Chachkoff <[EMAIL PROTECTED]>
wrote:
> Nothing currently prevents a plugin to modify the
> data it has access to
> directly -
You haven't worked on many complex projects then. The
upset this will cause in crossfire development (and
devs will wait untill it's done before committing
again because they don't want their new code to be
broken) will be very large. I would like to see plots
etc in crossfire in my lifetime, your
Le Mardi 17 Janvier 2006 18:15, Brendan Lally a écrit :
>On 1/17/06, Mark Wedel <[EMAIL PROTECTED]> wrote:
>> True. I imagine dependencies to be fairly standard C dependencies. But
>> I could imagine someone writing a plugin in C++ with appropriate wrappers.
>
>
Things written in other language
On 1/17/06, Mark Wedel <[EMAIL PROTECTED]> wrote:
> True. I imagine dependencies to be fairly standard C dependencies. But I
> could imagine someone writing a plugin in C++ with appropriate wrappers.
This point (more than any other) is potentially alarming. Currently
crossfire is written in C
Le Mardi 17 Janvier 2006 02:51, Miguel Ghobangieno a écrit :
> I suggest you not implement a huge worthless code
> change that is nothing but busy work. I reject your
> assertion that cave's analogy is flawed as it is not.
> If you want to code code something new useful rather
> then breaking the s
Le Mardi 17 Janvier 2006 08:00, Mark Wedel a écrit :
> Yann Chachkoff wrote:
>
> >
> > Well, it really depends on what the C code requires as dependencies - the
> > Python plugin has one with the python libs for example. But stuff that was
> > initially in the server code would have no such exter
Le Mardi 17 Janvier 2006 06:03, Alex Schultz a écrit :
> Frankly, I have to agree with mikee to some degree on this point. I
> generally have little trouble finding something after a combination of
> getting a feel for the code, which I have gotten pretty good for a while
> now, as well as skill
Le Mardi 17 Janvier 2006 06:12, Alex Schultz a écrit :
> Indeed. On this example, IMHO random maps are not optional, as they are
> essential to some quests, and also soon would be used by land plots
> (though land plots would in my opinion be a relatively good thing to
> implement as an optiona
Le Mardi 17 Janvier 2006 02:56, Miguel Ghobangieno a écrit :
> It is not half broken as far as I can tell. Yes it's
> not running on MF, that doesn't mean it's broken.
>
So having trees growing on sea squares isn't broken ?
> It gives few problems on Cat2. This whole thing is about
> slowly dumpi
Le Mardi 17 Janvier 2006 06:03, Alex Schultz a écrit :
> Frankly, I have to agree with mikee to some degree on this point. I
> generally have little trouble finding something after a combination of
> getting a feel for the code, which I have gotten pretty good for a while
> now, as well as skilled
Yann Chachkoff wrote:
Well, it really depends on what the C code requires as dependencies - the
Python plugin has one with the python libs for example. But stuff that was
initially in the server code would have no such external dependencies indeed.
True. I imagine dependencies to be fairly
Mark Wedel wrote:
That said, trying to figure out what is optional or not is
difficult. I'd venture to say a lot of people would say the random
maps really are not optional (or if those are optional, what else is
optional, like shops, monsters, etc)
Indeed. On this example, IMHO random ma
Frankly, I have to agree with mikee to some degree on this point. I
generally have little trouble finding something after a combination of
getting a feel for the code, which I have gotten pretty good for a while
now, as well as skilled grepping.
However aside from some things like this, I do f
I suggest you not implement a huge worthless code
change that is nothing but busy work. I reject your
assertion that cave's analogy is flawed as it is not.
If you want to code code something new useful rather
then breaking the server as is what will happen if you
go forward with this plan. You also
It is not half broken as far as I can tell. Yes it's
not running on MF, that doesn't mean it's broken. It
gives few problems on Cat2. This whole thing is about
slowly dumping whatever MF doesn't use. Open your
eyes, the 2nd biggest server runs weather code at it's
most extreme, in terms of players
I suggest you not implement a huge worthless code
change that is nothing but busy work. I reject your
assertion that cave's analogy is flawed as it is not.
If you want to code then code something new useful
rather then breaking the server as is what will happen
if you go forward with this plan. You
> Sorry, in the initial post I presumed it would be python, but a C plugin
> seems like a reasonable idea.
Yep, I easily understand the confusion, given that for the most part, the
Python plugin was the only one widely used (Actually, it is the
Crossfire-Python "bridge" itself that is the plugi
> I personally don't see much reason to rewrite existing code that is
> working fine as a plugin. There are just enough things that could
> be/should be done than rewriting working code doesn't make sense.
As Yann said, i was not really mentioning rewriting stuff - apologies
for the confusion.
W
Sorry, in the initial post I presumed it would be python, but a C plugin seems
like a reasonable idea. For one thing, I can't imagine a C plugin ever not
being able to be installed (unlike python where people could be lacking the
libraries)
That said, trying to figure out what is optional
> Try not to dismiss things solely because they disagree with your opinion.
I dismissed a flawed analogy, based on wrong technical assumptions. It is not
an opinion point, but rather the rebuttal of an out-of-topic flambait.
> Modularizing the server would create a ton of
>problems,
Tons ? Nam
Try not to dismiss things solely because they disagree
with your opinion.
Modularizing the server would create a ton of
problems, breakage, and solve nothing and add even
less: it is busy work. If you must be busy be busy on
some new feature rather then scrapping the last 10
years of work (and that
Le Lundi 16 Janvier 2006 18:47, Miguel Ghobangieno a écrit :
> That is what the hurd project thought at the begining,
> the reality is diffrent.
>
The Hurd project thought a microkernel architecture was interesting for
reasons other than maintainability. It is also a stalling project for reasons
That is what the hurd project thought at the begining,
the reality is diffrent.
--- tchize <[EMAIL PROTECTED]> wrote:
>
> > You forgot the other important point, modularity
> reduces speed of
> > development, sometimes catastroptically, you only
> need to look at GNU
> > Hurd for an example of t
I have to do the same thing when I am adding things to
my perl rpg (which is not smaller in lines of code
then crossfire). It's not a big hassle, and how else
will the code know what's going on? Use grep.
--- tchize <[EMAIL PROTECTED]> wrote:
> Le Lundi 16 Janvier 2006 13:07, Anton Oussik a écrit
> You forgot the other important point, modularity reduces speed of
> development, sometimes catastroptically, you only need to look at GNU
> Hurd for an example of that.
i see the exact opposite of behaviour at work. Project initiated in a modular
way, or migrated to a modular approach are easi
Le Lundi 16 Janvier 2006 13:07, Anton Oussik a écrit :
> Throwing in my two pennies:
>
> In general modularisiation of the code will improve maintainability,
That's also my opinion.
> On the other hand modularising the code will result in many changes,
> may introduce new bugs into the code, and
On 1/16/06, Anton Oussik <[EMAIL PROTECTED]> wrote:
> On the other hand modularising the code will result in many changes,
> may introduce new bugs into the code, and is in general a lot of work
> whilst the benefits are questionable (this will only be useful if core
> is really small and most thin
Throwing in my two pennies:
In general modularisiation of the code will improve maintainability,
as the core will be smaller, and tidier. Modules can then be compiled
in or left out as the person running the server wishes. This would
make debugging easier if anything, as then as long as the core i
> The harder part is to define what are the core/basic rules and what are
> options.
Definitely. But I'm not sure such a definition is really needed. I think that
if a functionality is clearly "optional" or isn't strongly tied with the rest
of the code (as it appears to be the case for random m
> Wouldn't what would happen is that the 'plugin' stuff is ignored and gets
> broken and only things that are used on MF worked on? That sounds like what
> this is for, to slowly jettison that which MF does not use.
That's ridiculous. The distinction between what is part of the core and what is
Nicolas Weeger wrote:
Hello.
I'm wondering about moving some parts of the code to plugins.
IMO things like weather system (excluding darkness-related things) could
be moved to a plugin, and just hook to server core.
Random maps generation too could imo be moved.
(particularly weather, as it's re
Wouldn't what would happen is that the 'plugin' stuff
is ignored and gets broken and only things that are
used on MF worked on? That sounds like what this is
for, to slowly jettison that which MF does not use.
--- Yann Chachkoff <[EMAIL PROTECTED]>
wrote:
> >Hello.
>
> Hi :)
>
> > I'm wondering
>Hello.
Hi :)
> I'm wondering about moving some parts of the code to plugins.
> IMO things like weather system (excluding darkness-related things) could be
> moved to a plugin, and just hook to server core.
> Random maps generation too could imo be moved. (particularly weather, as it's
> really
Why? That's just extra useless busy work. You could
code in drunkenness (see previous post) if you're
itching for something to do.
--- Nicolas Weeger <[EMAIL PROTECTED]> wrote:
> Hello.
>
> I'm wondering about moving some parts of the code to
> plugins.
> IMO things like weather system (excludi
77 matches
Mail list logo
