Proposal for a YAMG integration in Wesnoth

[pyrophorus]

Hi !

This topic is to discuss the technical issues of a possible integration of the YAMG in Wesnoth, not its opportunity (project manager job and decision). The development thread contains the full history of the project, and I think it is the good place to discuss features and results. If you have few ideas about what this generator does, I suggest you reading the illustrated user manual to make an idea (here). The version I'm referring to is the last one on github (sources).

An attempt to include the program as an addition to Wesnoth wasn't a success, and I think it would be better to go another way: to include it as a compiled library (like the lua engine). It would be simpler and beneficial in many ways. The main obstacle in the integration process was the attempt to refactor the code to make it conform to Wesnoth programming rules. As anyone could expect, this created errors and even bugs, and the result was not satisfactory to both sides. This because the special kind of the program which is mainly number computing and filling algorithms on a fixed size objects array. No need here to use advanced features or special libraries.

For now, the map creation process is straightforward:
1- create a settings container and fill it with desired values (one in the object family YAMG_Params)
2- call its getGenerator() method to get a MapGen object.
3- run the MapGen method CreateMap()
4- get the final map text block from the MapGen object as a standard C string. (can be done more than once, optionally flipping/rotating the map).

The standalone program folllows this process as a quick look into the main.cpp shows easily. It uses a child class of YAMG_Params because it loads the parameters settings from a companion file, which would be obviously useless in Wesnoth. And a Wesnoth integration has no use of this main program. The integration could be done creating one or more children classes of the YAMG_Params.

For now, this object contains:

• a set of member values holding the parameters for the MapGen engine. The engine only reads them. No modifications are done during execution (and it will remain so). All those have default values created in the constructor, ensuring an error free execution of the engine, even if no further changes are made.
• a method allowing to select and instanciate the correct flavor of the MapGen engine (this is parameter dependant).
• two virtual methods to get char buffers holding the parameter text block and the template map. These are overloaded in the YAMG_ParamsSA to get them from files.
• a parser to read the parameter text block (whose syntax is already WML conform), and a parameters names list.
• a separate validation method (not complete yet) to verify parameters validity.

The three last items can be used or not in a Wesnoth implementation. They even can be moved into the YAMG_ParamsSA object. The interface to the engine relies only on the member variables and the getGenerator() method. A Wesnoth implementation needs only a way to fill these parameters, from a WML block, directly from a GUI, or in any other way. It matters not.

Evolution and maintenance:
I think it should not be a problem to keep both development separate as long as we don't modify unilaterately the YAMG_Params object. Adding new members and new features there shouldn't even be a problem (the Wesnoth implementation will just ignore them) since no modifications to existing members (name and type) are done. Next, the MapGen family and the getGenerator() method should be some kind of black box to Wesnoth programmers. Of course, there's no secret, but no need to dig in and make changes there. I often refactor my class organization and melting in this would certainly create problems.

This black box shouldn't cause problems because it don't have any dependencies except to the standard C library. As a result, it compiles and runs anywhere without change. I don't plan to add more dependencies, because my ordinary practice is to avoid them when possible (and in this kind of program, I can't see why I would need anything else).

As the generator don't rely on Wesnoth code, it don't rely on particular terrain codes values. Those are stored in static arrays and used only in final map production. All these codes sets are in the file YAMG_Terrain-10.h and they can be changed at will, to make use of new terrain codes particularly.

Another advantage of keeping separate development is testing. One can find a test unit in the YAMG_ParamsSA. Far from complete, but it allows for now to test conveniently many runs of the generator engine on various settings which is not so convenient in a larger program. The unique way in calling the generator warrants those tests are significative. I will improve them, but anyone can do the same to qualify a new version before integration. The sources are and will remain on github.

Friendly,

[fabi]

This topic is to discuss the technical issues of a possible integration of the YAMG in Wesnoth, not its opportunity (project manager job and decision).

There is no project manager or lead developer anymore since Dave/Sirp retired ages ago.

I have already agreed to include YAMG into the map/scenario editor. There is not a single voice with the opinion that the YAMG wouldn't be a nice thing to have. Thus integration into the mp create screen and scenario WML shouldn't be a problem as well, at least from a "opportunity" point of view.

I hope this is settled, once and for all.

An attempt to include the program as an addition to Wesnoth wasn't a success, and I think it would be better to go another way: to include it as a compiled library (like the lua engine).

The Wesnoth source tree contains a copy of the lua library's sources because we had to adjust some stuff in there.
Thus I don't understand what

include it as a compiled library

means.

It would be simpler and beneficial in many ways.

Okay, I assume that you like to offer a libYAMG and Wesnoth should link against, like it does with libSDL or the boost libraries.
This means you need to provide a binary for each platform Wesnoth supports (countless linux distributions, bsd, solaris, windows (32, 64), macosx, the pandora handheld and more) and our packagers need to check if the library is available for their target platform.

If YAMG would support all kind of hex field based maps for all kind of games then making it a library would actually make sense.
But currently Yet Another Map Generator is more a Yet Another Wesnoth Map Generator.

I can't find a single point which supports the claim for more simpleness or other benefits.

The main obstacle in the integration process was the attempt to refactor the code to make it conform to Wesnoth programming rules.

Please note, this is not (only ?) a question of different tastes and styles.

Some of our developers use automatic tools which check for common c++ code problems and those really don't like YAMG.

There were even some memory holes in there.
I am sure that Wesnoth linking against a memory hole is a no go and won't happen.
So no relief on the memory front no matter if made a library or not.

When asked about the hole, Pyro answered me that nowadays with Gigabytes of RAM he does not consider this an issue.

Another advantage of keeping separate development is testing. One can find a test unit in the YAMG_ParamsSA. Far from complete, but it allows for now to test conveniently many runs of the generator engine on various settings which is not so convenient in a larger program. The unique way in calling the generator warrants those tests are significative. I will improve them, but anyone can do the same to qualify a new version before integration.

We have a c++ unit test facility which is perfectly fine for such testing issues.
Again, I can't see any advantages here.

[pyrophorus]

Please note, this is not (only ?) a question of different tastes and styles.

Some of our developers use automatic tools which check for common c++ code problems and those really don't like YAMG.

There were even some memory holes in there.
I am sure that Wesnoth linking against a memory hole is a no go and won't happen.
So no relief on the memory front no matter if made a library or not.

When asked about the hole, Pyro answered me that nowadays with Gigabytes of RAM he does not consider this an issue.

I don't know what you means with "memory holes". You asked me about exceptions and I replied the std C library was throwing none. If you're speaking about "out of memory" problem, yes, I replied this was not much of an issue (Wesnoth itself can crash in this way). If you mean memory leaks, I wonder where you found one.

Again, I can't see any advantages here.

Then I have nothing more to say...

Friendly,

[pyrophorus]

I have already agreed to include YAMG into the map/scenario editor. There is not a single voice with the opinion that the YAMG wouldn't be a nice thing to have. Thus integration into the mp create screen and scenario WML shouldn't be a problem as well, at least from a "opportunity" point of view.

I hope this is settled, once and for all.

It's time to put an end to this farce. IMO, it's clear now this integration will never happen. The best is to forget definitely it could happen and turn to other things.

That's what I'll do now.

Bye....

[fabi]

It's time to put an end to this farce.

Don't be silly.

IMO, it's clear now this integration will never happen.

I don't think so.
The first issue I want to put the qt toolkit support into use is a gui dialog for controlling YAMG.

This effort is reusable.
Meaning you can use it for controlling the standalone version as well with only little effort.

From there the integration into the multiplayer setup and map/scenario editor is only one step away.
The WML support needs some thinking about a good syntax but that is not black magic either.

There are some issues with the code itself but they are not unsolvable.
Our code conventions are not very strict. Really.

The best is to forget definitely it could happen and turn to other things.

That's what I'll do now.

Bye....

I hope you will at least continue to develop the standalone YAMG.

Let me try to define an alternative approach for the integration, assuming you don't want to drop the standalone version with the integration.
I guess one might want to write a script around YAMG thus the standalone application is still quite useful.

1. Qt dialog for controlling YAMG
2. Splitting YAMG into the application and the library like suggested
3. The dialog moves into the library, being used by both applications (Wesnoth and YAMG_Standalone)
4. YAMG_Standalone uses the dialog (optional, current invocation stays the default?)
5. Cloning of the Wesnoth qt branch on github. Let's call it Wesnoth-YAMG for now. (But keep in mind, it is a clone of the qt branch)
6. Adding both, the library and the YAMG application into /src/generators/yamg (an outdated version of YAMG already lives there, added by me)
7. Adding a YAMG_Standalone target to the scons build system
8. Wire the extra generator in the pool of the existing ones
9. Merge request against the Wesnoth-qt branch
10. We sort out all issues with the merge including code conventions or stuff like memory and exception issues
11. Support for yamg being called by scenario wml
12. Maybe add some unit tests
13. If the qt branch gets merged into Wesnoth's master branch, fine. If not merge the YAMG with master and replace the qt with a gui2 dialog.

It means you only need to deal with Iceiceice and me. The communication can be done with the github merge request messaging thing.
This procedure works for us quite well, since the project switched to github a bunch of merge requests took place.

The benefit is that YAMG_Standalone ships then with Wesnoth and is also part of every Linux distribution.

Code: Select all

sudo apt-get/yumm install wesnoth-yamg

will install it without any extra work for you by reusing the excellent infrastructure of the project.

[pyrophorus]

It's time to put an end to this farce.

Don't be silly.

IMO, it's clear now this integration will never happen.

I don't think so.
The first issue I want to put the qt toolkit support into use is a gui dialog for controlling YAMG.

Which is exactly why it will never happen. The story is more than two years old now, and you're always adding new prerequisites and new tasks. Why should this come to an end ? Each time some progress could be made, you start throwing BS at my work like in your first reply, and the each time it's getting worse. You'll probably say next time your compiler gurgles in disgust when fed with my program, or advocate the spectre of hard disk wreckages, but then people will really begin to ask themselves why you seem so willing to include such a heap of craps in Wesnoth. Be consistent and say you don't want it. I made this proposal essentially to obtain a clear and definite reply, and once again, you're sending it to an undetermined future.

Now, I also made my best to make the integration easier, as I promised to Turuk last summer, and particularly, I made provisions to deal with the "out of memory" error, even if I don't think it's really likely to happen (Curiously enough, I had this message only once in ten years, and it popped when using some silly WML macros ) . But you probably didn't look at the new version and keep complaining at those "memory holes".

This effort is reusable.
Meaning you can use it for controlling the standalone version as well with only little effort.

You're assuming here a GUI would be a good thing for my program. But things are not so simple. I already gave a try (with Qt) one year ago, and finally decided the configuration file was simpler to use. The problem is the same with the Wesnoth generator: the GUI expose only a little subset of the parameters available in WML, probably because adding more would make the screen too complex and disturbing for the user. A configuration file don't exhibit the problem, because only needed parameters are there, so the user is not overhelmed with features (s)he don't need.

From there the integration into the multiplayer setup and map/scenario editor is only one step away.
The WML support needs some thinking about a good syntax but that is not black magic either.

Again, you're imagining some work would be needed here. There's nothing to do, the syntax of the yamg configuration file is already WML conformant. Of course, you may want to use the Wesnoth WML parsing functions instead of mine (which would be a good thing of course), but there's nothing to do with the syntax.

There are some issues with the code itself but they are not unsolvable.
Our code conventions are not very strict. Really.

I don't know exactly what you mean here. The coding rules one can find in the wiki, or the kind of changes you made last year when inserting the yamg in Wesnoth ?

The best is to forget definitely it could happen and turn to other things.

That's what I'll do now.

Bye....

I hope you will at least continue to develop the standalone YAMG.

I certainly will keep developing the yamg as a separate program, and share it with those who are interested in (very few people I think). I think you understand not clearly something here. We are all here for fun, to help if possible and if asked. Right ? My pleasure is to develop programs and algorithms like the yamg. Building gas plants around them using frameworks, advanced tools and libraries on the contrary, is tedious to me. Somebody recently pointed me to this, saying "finally, you're this kind of programmer." That's right, even if I wouldn't compare me to Linus Torvalds. I share his views, except his very bad opinion on C++ programmers.

This to make clear I'm not some kind of uneducated guy who should learn and work hard to reach the high Wesnoth standards. My opinion on them is exactly what you think of my programming style: they are mostly useless and encourage bad programming practices. There's no reason to start a conflict or a debate here, just be conscious we are really different, and good software can be created in both way (unless you think Git or Blender are actually pieces of craps). And accept the fact I will never apply Wesnoth rules in the yamg. It's not I'm unable to do it, it's I don't want to do it. If I were to modify Wesnoth code, it would be completely different, of course. For myself, I think both can coexist peacefully, but if you think otherwise, or I'm using the yamg as a Trojan Horse to get access to Wesnoth code and ruin it with awkard modifications, it's time to say no. Or be prepared to modifiy the code on your way (it's GPL and sources are public), and do it again each time you want to update.

Last, remember I'm not trying to sell you my program, and I never asked it to be in Wesnoth. It was Boucman's idea and now yours. I wouldn't be angry or disappointed if you went to change your mind.

I perfectly understand some people can find very exciting to try and use the very last version of everything, pile tools and libraries, and since we are all here for fun, there's nothing to say against it. Except this has some drawbacks: all the time spent upgrading and refactoring the code is not spent in creating new things. See why I said you'll never include the yamg ? It's only because you will always prioritize other things like turning to Qt or refactor Wesnoth code to make it C14++ compliant.

Let me try to define an alternative approach for the integration, assuming you don't want to drop the standalone version with the integration.

You need not to worry about the standalone version and a GUI for it. Forget it. And the deployment thing using packages or installers as well. "Extract and run" is good enough, unless you want to ship it in Wesnoth. But then, no need for a separate installation IMO: adding it to the "tools" folder would be fine.

<snip>

Do what you want. We are all here for fun... But you don't really need me here.

It means you only need to deal with Iceiceice and me.

I have nothing against anyone, you know. I just wonder what ice3 could do around the yamg. We have *totally* opposite pov on programming.

The communication can be done with the github merge request messaging thing.
This procedure works for us quite well, since the project switched to github a bunch of merge requests took place.

Forget it. I will not fork Wesnoth on github once more. It's a pain in the ass to work with such a gateway, and useless in this situation.

Have a merry Christmas !

[iceiceice]

Since you and fabi bring me into this I think I will contribute my 2 cents.

1. There are already some WML bindings of some quality for yamg, which seemed to be basically working on master, although it's probably not ideal and I didn't look too closely at it.
2. I don't see a connection between qt and yamg. There is no particular need to have a gui with yamg, it's just something nice.
   
   Pyrophorus is basically right, it saves a lot of time to just use a configuration file. The user that wants different settings can just copy / tweak this file: https://github.com/wesnoth/wesnoth/blob ... enario.cfg
3. Regarding "memory holes", I had dim memories that coverity made some report of this, but I can't find it. All I found in the coverity log just now is some complains that member variable terrains_ is not initialized by the constructors of ya_mapgen.
4. Regarding "the high Wesnoth standards"

   My opinion on them is exactly what you think of my programming style: they are mostly useless and encourage bad programming practices.

   No, I think you misunderstand, I don't think anyone thinks your programming style is "mostly useless or [bad]". The wesnoth coding standards are not about saying "we are geniuses, this is the good way to program, other projects are bad and other people are stupid...". It's rather, "we are the maintainers of this project, this is the kind of code that we have agreed to maintain."
   
   The fact is, whatever goes in our tree, we are stuck with it. Based on the contributor history, it looks like for 90% of people, they contribute commits for 2-3 years tops, then they are gone, and we are left with whatever they leave behind.
   
   We are left to make sure that it will compile on all future versions of gcc, clang, microsoft visual studio, for windows mac linux, and any cell phone / console that we decide to try to support. That is quite a commitment, and quite frankly the coding standards do only a minimal amount to make it easier.
   
   Instead the focus is making it as easy as we can to read it and debug it, trying to avoid the kinds of patterns that easily lead to problems, especially silly mistakes with pointers.
   
   A good programmer knows that the programming techniques employed for any given task need to reflect the experience and skill level of who will be the maintainer(s).
5. Pyrophorus, I think no one was quite sure what you meant when you said you wanted yamg to be a "compiled library". There's two possibilities -- in-tree or out-of-tree?
   
   If you want to go out-of-tree, then as fabi points out you will basically have to set up your own distribution, that is, you will become responsible to compile it for all the platforms.
   
   If you want to go in-tree though, then of course, *we* become responsible for this. Ergo, the coding standards must apply.
   
   You seem to be writing about how the previous attempt didn't work and something different must be tried, which suggests you want out-of-tree this time. But everything else in your post suggests you really just want to have in-tree, but we promise not to touch your code... That just isn't going to happen, we are of course going to have to touch it when there are compilation problems, and we also aren't going to do things like merge the source of an old version of a library that we actually link with dynamically... (mersenne twister rng)
6. There are a lot of devs, but most of the time if you want something done you need to do it yourself. As you have pointed out yourself, wml bindings for yamg shouldn't take more than an hour. But two years later all we have is a lot of talk. (And whatever bindings I referred to that magically appeared in the tree...)
   
   It's not very likely that someone else is going to have the interest and attention span to become the "yamg integration maintainer". IMO if you demonstrated a willingness to submit patches to address problems having to do with yamg, not just in yamg but in the core wesnoth project itself, it would go a long way towards people taking this project proposal seriously.
   
   You could have just taken an hour, written whatever bindings / support you think is necessary to have in wesnoth, and made a pull request. Then this whole conversation would have played out in github comments and possibly been merged within a few hours. When instead of a patch we have "proposal for integration forum thread" and no action, it seems more like "request for someone to do work for me". IMO.
   
   I don't think anyone doubts that you are a good programmer, but that doesn't mean that we are just falling over ourselves at the opportunity to end up maintaining your code in a few years.
   
   There is no gilded path... everyone who contributes to wesnoth's source starts by making a few patches / pull requests and getting them committed.
7. Regarding
   

   Except this has some drawbacks: all the time spent upgrading and refactoring the code is not spent in creating new things.

   This feels like a common theme in your posts, you said stuff also in the lua map gen thread about how you would spend time to contribute new features (!), although this is the first time I read about how we make such a mistake with upgrades and refactoring.
   

   I'm interested in features, so to speak, what programs does and not the way they're written. I don't plan to rewrite Wesnoth as you do in any particular idiom or technique because, from a user point of view, it would only mean more bugs and no feature. And it's symptomatic all discussions I have or had about my map generator or any other contribution always derails on the subject of programming rules as if Wesnoth was only an experimental field for programmers. The way I wish to contribute to Wesnoth is adding new features intended to users, not to impress fellows programmers. If I were in the dev team, I would work on things like ...

   The fact is that for the vast majority of the project, it's been gang-busters feature factory, at the expense of the overall design. We do it again every year when students propose new features to google, and google pays to have them developed in a very short amount of time. Now I would argue that what we have is a bunch of features with varying levels of bugs and a lot of duplicated effort between them. Because of some poor design decisions, also dating to the origins of the project, there are additional features that would be really nice that we would like to have, that we just can't hope to make right now.
   
   It's not like we have exhausted the set of features that we could comfortably add, but there are many high value features that are off limits. And there is now a very large pile of broken features. So bug fix, refactor, and maintenance are more important than ever to the long term health of the project.
   
   But enough about what I think is important, what you keep saying is that there are so many nice features that you would like to add, that you would add, if only... what I'm not sure.
   
   If only we would waive the coding standards for you? If only we would just give you commit access here and now and let you do what you want?
   
   Again, there is no gilded path.
   
   If you want us to merge your features into wesnoth then you have to negotiate to make it acceptable. That's a pretty low bar, when there's a feature we really want I've seen us accept some pretty strange looking code. The coding standards are pretty benign... "write exception safe code" "use the standard library" "use const correctness" "avoid implicit conversions" "don't throw exceptions from the destructor". Is that not all the highlights? (I guess we have some guidelines regarding git as well, but it's still quite lax.)
   
   If you aren't interested in responding to code review, frankly it suggests that you aren't interested in maintaining the code in case of a bug either. It's better if a patch comes from someone who has an active interest in seeing it in wesnoth -- if it turns out it's broken, such a person might fix it since they know that broken patches might get reverted rather than fixed the way they want. If you just think that you are much smarter than all of us, and that none of us could possibly have anything intelligent to say about your code... well it just doesn't bode well for working with you.
   
   Why don't you take all these feature ideas you have, make some patches and submit them on github like everyone else, and then instead of arguing about this stuff in theory it can be very practical and the "coding standards" issues can be very concrete. At least then there will be some substance behind all of these features you keep talking about. And if these features are so great, then even if it doesn't work out at first, perhaps some later dev might adopt some of the patches and see them to completion.
   
   It's better than these vague suggestions of great features, and hazy hypotheticals "if I were already a developer... if someone promised me that special exceptions will be made for me, and every line of code I write will definitely be merged..."

[pyrophorus]

Since you and fabi bring me into this I think I will contribute my 2 cents.

Fabi maybe, but I never did that. I only said you and I have opposite views on programming. It's strange you read here an invitation to join the discussion.


My proposal is only a suggestion to make easier integration and maintenance of the yamg. You see in it an attempt to enter the dev team without respecting Wesnoth rules and enforce here my own development practices. Strange, really. You should buy another spectacles pair.

Of course, the result is a tl_dr thing totally missing the point.

This leads you to write things like this: "It's better if a patch comes from someone who has an active interest in seeing it in wesnoth". True, but I have no active interest in seeing it in Wesnoth. Isn't this clear enough ? Didn't you read anywhere it was Boucman and Fabi idea, and not mine ? Usually, people asking me some code (here and on other places) say "thanks", and if they need some more help to use it, ask for it politely. It's very unlikely they start growling, nitpicking the coding style, giving me lectures on what good programming is, and take me to a protocol for my gift to be accepted. Customers can do that sometimes and the reply is of course: "How much will you pay for it ?". Other people will get: if finally you don't want it, don't get it.

Now, my program was never intended to be included in Wesnoth or meet any user need. It's kind of piece of artwork I made for my pleasure. I shared it thinking some people could have some fun playing with it. Next, I perfectly know how to join the dev team. If I don't do it, this is because I don't want to join. Not only because the coding rules, but because the lack of project management too. I will not add anything or enter a debate here. There are competent people in the dev team, and I'm sure they don't ignore the pros and cons of this choice. It would be offending to teach them on this topic.

Your technical survey could be interesting if only you were looking at the last version of the yamg. By the way, it proves the WML integration already works. So where is the additional work I'm supposed to put on you ? It's your choice to do more, refactoring the program, not mine.

I resist not to reply to this:

No, I think you misunderstand, I don't think anyone thinks your programming style is "mostly useless or [bad]". The wesnoth coding standards are not about saying "we are geniuses, this is the good way to program, other projects are bad and other people are stupid...".

No, it's only what you think and don't dare to say. And explain why you're always teaching everyone on everything and talking proudly as if you were the project manager here.

<snip>
We are left to make sure that it will compile on all future versions of gcc, clang, microsoft visual studio, for windows mac linux, and any cell phone / console that we decide to try to support. That is quite a commitment, and quite frankly the coding standards do only a minimal amount to make it easier.

The problem is you seem unable to understand some code will compile anywhere without any change as long as C/C++ compilers will exist. The Mersenne Twister is a good example, and I tried to show you the reason why, but you kept stomping the ground saying "I want to use the boost lib !". So I will not try to explain why the yamg is this kind of code. You will not listen.

Instead the focus is making it as easy as we can to read it and debug it, trying to avoid the kinds of patterns that easily lead to problems, especially silly mistakes with pointers.

And introducing others. C++ is doing many things behind the scene when using "advanced features" which are not always what you want it to do.

A good programmer knows that the programming techniques employed for any given task need to reflect the experience and skill level of who will be the maintainer(s).

This is a pleasant invention of yours to strengthen your weak argumentation. The trick is well known: its just to make a general truth from what is only a personal opinion (or here only an opportunity statement you will forget tomorrow). Programmers have of course to deal with maintenance, but not with maintainers skill level. If so, they would have to avoid systematically the best algorithms because they're difficult to understand. Come on...

Don't modify what you understand not. This is the rule I use myself. The Mersenne Twister is once again a very good example: you need a huge mathematical background to modify it, even if it looks very simple. If not, you will only mess the thing. And here is a large part of the problem: you seem to think adding some const or lambda functions will automatically make everything clear to those poor stupid maintainers. Of course it is not. The difficulty is not only in syntax or code style, but in algorithms as well. If your main concern is with maintainers skill level, then you should evaluate the yamg intrinsic complexity too. To me, of course, there's nothing mysterious because I wrote it. To others, I don't know, but I'm sure of one thing: if you apply style modifications superficially, without understanding how the program works, you will most probably ruin it.

Now the maintenance problem is usually managed in another way: limiting the maintenance points, anticipating which changes will be done, and providing documentation (not only in the code, such a documentation exists on github and can be improved).

I don't think anyone doubts that you are a good programmer...

Yes, you do. You were not teaching me each time you get an opportunity to do so, and you would take more seriously my technical arguments if not. Of course, you're planning to replace the embedded Mersenne Twister with your favorite boost lib. No need to ask me if it is a good idea of course. Even if I wrote the program, your opinion is certainly better than mine.

Now, I don't know exactly why you quoted me saying this.

I'm interested in features, so to speak, what programs does and not the way they're written. I don't plan to rewrite Wesnoth as you do in any particular idiom or technique because, from a user point of view, it would only mean more bugs and no feature. And it's symptomatic all discussions I have or had about my map generator or any other contribution always derails on the subject of programming rules as if Wesnoth was only an experimental field for programmers. The way I wish to contribute to Wesnoth is adding new features intended to users, not to impress fellows programmers. If I were in the dev team, I would work on things like ...

but your whole post is proving once again this to be true. You focus on a little part of development process and wrote not a word about users concerns. To me, the most important thing is the features the yamg could bring in Wesnoth. Would they make the editor more powerful and attractive ? Would they enhance WML capabilities ? I'm not sure the yamg can meet real user needs. If it's only a programmer fancy to put it in Wesnoth, why doing this ? and then, why debating about code style or maintenance considerations ? It's a pure waste of time.

Now, to me, there is no real user interest. If not, I would probably have done all the integration job by myself. Here, I have no reason to do so, but if Fabi wants to, no problem.

Friendly,

[iceiceice]

Now, to me, there is no real user interest. If not, I would probably have done all the integration job by myself. Here, I have no reason to do so, but if Fabi wants to, no problem.

Well it's good that you've made that clear, given that you yourself took the initiative to make this long post with a detailed integration plan. Forgive me for coming away with the impression that you had some personal interest in whether it happens, or in helping with problems related to it.

That's all I have to say in this thread...