On 4/16/07, Cyrille Dunant <[EMAIL PROTECTED]> wrote:
Maps are long to make.
True, this is one barrior keeping me.
Good maps are rare, and we already have few. It is completely silly to eliminate backward compatibility for the sake of it.
The good maps can be remade fairly easily. Its the idea, theme, and relative sizes of the maps that count.
It destroys hours of work of many people that did the maps. It forces us to get a new set of maps It serves no purpose as basically you can perfectly have a new and old map format: you only need a filter.
Not really true. The new structure has data where the original didn't and vice versa. It requires completely loading the old structure, which means retaining all of the old code, and converting it to the new structure. This is not only dirty, but its gonna be a hell hole of bugs.
It introduces new bugs where there weren't (make no mistake, all code is buggy, and there is no reason a rewrite will be less buggy than the original)
Not true! There are ways to design code that make it non buggy. And I have introduced this and argued this. Glob2 lacks code foundation. It doesn't have small functions that are garunteed to work. Algorithms are long, and hacks and fixes are injected everywhere. The Map code is the only exception, where most of the functions are simple and based upon an "idea". The documented and easily understood idea gives stablility when working with the Map class, I very rarely see bugs in Map code. The lack of documented behaviour, and the injection of hacks and bugfixes everywhere else makes Glob 2's code much more buggy, as bugs are easily introduced when semantics aren't understood.
So unless there is a compelling reason to redo any subsystem at all (this is especially true for the maps), I think it is a bad idea in general: if it ain't broke, don't fix it!
Its not that things are broke. Its like using a *really* old car. The old car works. But it sucks gas, the engine is loud, the oil has to be changed frequently, the brakes have slow responce time. And the mechanics can't understand how the damn thing works. It works. But not very well, and its not easy to change.
Now there _are_ problems, for instance, network play needs to be flawless, and if that takes a rewrite, so be it! But it serves absolutely no purpose whatsoever to break backward compatibility for no purposes other than to essentially destroy valuable work.
That is completely untrue. We are not breaking backwards compatibility on purpose. Backwards compatibility is merely a by-product of changing the internal structure of Glob2 to be more maintainable, flexible, and less buggy.
Because make no mistake: having good maps (or having maps at all) is _way_ more important than saving five minutes by not implementing a filter.
Your not the one working on this so I suppose I can't expect you to understand the difficulty. Implementing a filter would defeat the purpose of the system in the first place because it would require all old code to remain in place, and new code built on top of it, which would make a mess of the code.
-- CFD PS, in general, rewriting for the sake of it is not a good idea, unless you found some basic architectural flaw.
And there are basic architectural flaws. Glob2's map header system has badly defined semantics, and the placing of variables is often difficult and requires hacking in to get it to work.
PPS and from a development perspective, rewrites of subsystem should be done in separate branches and merged when well-tested and feature-complete.
Also Glob2 is technically in Alpha, and somewhere in our website the definition of Alpha means that things may change rapildy and backwards compatibility is not garunteed. -- Really. I'm not lieing. Bradley Arsenault. _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
