lua random map generation

Discussion of Lua and LuaWML support, development, and ideas.

Moderator: Forum Moderators

Post Reply
User avatar
iceiceice
Developer
Posts: 1056
Joined: August 23rd, 2013, 2:10 am

lua random map generation

Post by iceiceice »

Today I merged a feature to master which allows to write random map generators in lua. I hope that this will make it much easier to develop and distribute random map generators, since they won't need to be written in C++ or tied to the release cycle.

To use it, select either map_generation="lua" or scenario_generation="lua" in your scenario. You should then have a generator tag which includes attributes either create_map or create_scenario, which should be set equal to a lua script which will generate a map / scenario.

Here is some example code:

Code: Select all

#define LABEL X Y STRING
    [label]
        x = {X}
        y = {Y}
        text = {STRING}
    [/label]
#enddef
[multiplayer]
    id=lua_map_gen
    name= _ "Lua Map Gen Test Scenario"
    description= _ "test test test of lua map gen"
    map_generation="lua"
    [generator]
        id="test"
        config_name="Test Lua Map Generator"
        create_map = << local rng = Rng:create()

                        print(rng:draw())
                        print(rng:draw())
                        print(rng:draw())

                        local w = 50
                        local h = 40

                        map=""
                        for y=1,h do
                          local r = rng:draw() % 2
                          for x=1,w do
                            if x == 10 and y == 10 then
                              map = map .. " 1 "
                             end
                            if x == (w-10) and y == (h-10) then
                              map = map .. " 2 "
                             end
                            if ((x + y) % 2) == r then
                              map = map .. "Gg"
                            else
                              map = map .. "Md"
                            end
                            if x ~= w then
                              map = map .. ","
                            end
                          end
                          map = map .. "\n"
                        end
                        return map
                     >>
    [/generator]

    id = foo
    random_start_time=yes

    {DEFAULT_SCHEDULE}
    [event]
        name=prestart
        {LABEL 25 20 ("Lua map generator")}
    [/event]

    [side]
        [ai]
            villages_per_scout=8
        [/ai]
        id=RBY_Side1
        side=1
        save_id=RBY_Side1
        persistent=yes
        color=red
        team_name=Red
        user_team_name= _ "teamname^Red"
        controller=human
        canrecruit=yes
        shroud=no
        fog=no
        gold=1000000
    [/side]
    [side]
        [ai]
            villages_per_scout=8
        [/ai]
        id=RBY_Side2
        side=2
        save_id=RBY_Side2
        persistent=yes
        color=blue
        team_name=Blue
        user_team_name= _ "teamname^Blue"
        controller=human
        canrecruit=yes
        shroud=no
        fog=no
        gold=1000000
    [/side]
[/multiplayer]
For map generation, simply return a string containing the map data. For scenario generation, return the entire WML for the scenario as a lua table (see LuaWML).

It is not feature-complete at the moment, I intend to come back to it at a later date. I will likely add features depending on what kind of feedback I get. Here are some current features / non-features.

Note that:
  • You can instantiate wesnoth's high-quality random generator (mt19937, much better than the "rand" used by lua's math.random) by using the table Rng to create an rng object, with seed and draw methods. See example code above. This is for you pyrophorus :)
  • You can receive WML parameters to the generator, the entire [generator] tag gets saved to the arguments ... when any of the scripts are run.
  • You cannot use any of the usual "wesnoth." API, because you are not in a game at the time that this script is running. The script runs in an entirely separate lua environment from the one used in game, and from every other map generator script. This is fairly annoying because you cannot even use wesnoth.require or wesnoth.dofile, but because of the way the wesnoth lua API was designed, for now it is unavoidable, calling any of these functions would likely lead to segfaults. (You can still use WML syntax to include the source of some files though, or pass it in through the arguments.)

    I am considering to split the whole lua API into different pieces, some of which may be available when the game is not in session, but how this will work out exactly syntactically is not decided. (For instance should the wesnoth table always exist and only have some of its members at different points in time? or should it exist only during games, and a different table should be used for lua scripts running separately from a game.)
  • You cannot make a configuration dialog for map generators defined this way. Quite plausibly this could be supported, by allowing to define a lua script for the attribute user_config. It would not be a problem for this script to communicate global variables to the map generation script then. The script could then get info from the user by launching a dialog using the existing lua -> gui2 mechanism as described here: http://forums.wesnoth.org/viewtopic.php?f=58&t=31417

    Because of the previous issue though, wesnoth.show_dialog is not currently available so there's no way to do it right now.
To some extent progress on this will have to wait until I make progress merging at least some of the code mentioned in this thread: http://forums.wesnoth.org/viewtopic.php ... 87#p575060

Anyways feedback is welcome.

Note that I did not make any official documentation yet until the whole thing is more set-in-stone.
User avatar
pyrophorus
Posts: 513
Joined: December 1st, 2010, 12:54 pm

Re: lua random map generation

Post by pyrophorus »

iceiceice wrote:You can instantiate wesnoth's high-quality random generator (mt19937, much better than the "rand" used by lua's math.random) by using the table Rng to create an rng object, with seed and draw methods. See example code above. This is for you pyrophorus :)
No, thanks... I have already one in my generator, probably of the highest quality because it is one of the three included in C++11 specifications (or C++14, I don't remember) (and probably the one you quote: if mt19937 stands for Mersenne Twister). That said, I don't know if some people store configuration files creating maps they want to retrieve later, but changing the PRNG would break ascending compatibility and ruin their work (remind me... I think I read someone complaining about a RNG change which broke his addon...)

And no, thanks, I will not rewrite my map generator in lua or any other language. I'm perfectly happy with C++, and I don't care about a possible Wesnoth integration. It was Boucman's idea, not mine, and probably not anyone else, because it would already be done yet for a long time.

Now, I'm not sure your proposal will have any success. IMHO, very few (if any) people want to write map generators, in lua or any other language. Some years ago, someone had the project to write one in php but he gave up very quickly. Some guys (like Tekelli) use the builtin generator(s), they do some post-production on the created maps, in lua maybe, but I doubt they would like to write a full featured generator. You should ask them what their real needs are.

Friendly,
Campaign Return to Noelren *** HowTos: WML filtering, WML variables
Please help to to update the Guide to UMC Campaigns
User avatar
iceiceice
Developer
Posts: 1056
Joined: August 23rd, 2013, 2:10 am

Re: lua random map generation

Post by iceiceice »

Pyrophorus:

Sorry, I was just kidding when I wrote 'this is for you', I only meant that I added the ability to get mt19937 in lua in part because I remembered that you added it for your generator, presumably because you found "rand" inadequate for your needs (I think that's quite reasonable). It is exactly the same PRNG that you are using, and that wesnoth will use generally in 1.13 and forward.
pyrophorus wrote: Now, I'm not sure your proposal will have any success. IMHO, very few (if any) people want to write map generators, in lua or any other language.
Well some people have already expressed interest, and even if no one else writes one, likely I will. IMO there are several reasons why it's very attractive to have a generator written in lua and integrated.
User avatar
tekelili
Posts: 1038
Joined: August 19th, 2009, 9:28 pm

Re: lua random map generation

Post by tekelili »

iceiceice wrote:Well some people have already expressed interest, and even if no one else writes one, likely I will. IMO there are several reasons why it's very attractive to have a generator written in lua and integrated.
I am curious about those reasons, can not imagine them. Anyway, in case you someday decide write a new generator, I am using very often some post-generation rutines that could be integrated in a generator, making it more powerfull for user (in case you interested in feedback about features desired).
Be aware English is not my first language and I could have explained bad myself using wrong or just invented words.
World Conquest II
User avatar
iceiceice
Developer
Posts: 1056
Joined: August 23rd, 2013, 2:10 am

Re: lua random map generation

Post by iceiceice »

tekelili: well here's a few reasons why its good to be in lua

!1. You can change the code on the fly without having to recompile the game -- a lot easier to test and debug it.
!2. You can distribute the code with your add-on and it doesn't need to be distributed with the wesnoth executable, so you don't have to be tied to wesnoth's release cycle
3. If there is a bug in the generator code you can simply fix it and ask people to update instead of worrying about compatibility / workarounds for the code you released earlier
4. You don't have to submit patches to wesnoth to change it, or adhere to wesnoth's coding standards for C++ if this is a sticking point for you
!5. Lua is *much* more newbie friendly than C / C++ -- for one thing you don't have to worry about memory management issues that are frankly totally unnecessary to think about for a random map generator.
6. You can make custom tweaks to someone else's generator and use it in your add-on -- if there's a simple feature that the original creator just didn't think of, but that you want, you can just add it *right now* and try, without having to message them and wait around...

Here's a few reasons why its good to be integrated:
!1. If the generator is integrated, then you can use it in campaigns, and in the "random scenario" creation screen
2. If the generator is integrated, you can provide a configuration dialog
3. If the generator is integrated, then you can access things like the stats of the units that have been loaded, and customize the map you generate based on that if you want
4. If the generator is integrated, then you can use wesnoth's existing API to help you do things. For instance if you want to output a WML for an entire scenario, it's convenient to use lua for this, because it has very good support to make WML tables. If you have some stand-alone program (which doesn't include any wesnoth code) you have to reinvent the wheel quite a bit. It's not hard, it's just tedious and unnecessary. Another example is the lua "location_set" definitions which we have.
SigurdFireDragon
Developer
Posts: 501
Joined: January 12th, 2011, 2:18 am
Location: Pennsylvania, USA

Re: lua random map generation

Post by SigurdFireDragon »

I've had some plans for a new map generator for a while, as there are styles of random maps that just can't be done easily with the default generator. Was intending to do it in C++, but I'll be using the lua generator if/when I get to it. Thanks! :)
Maintainer of Wings of Valor
My Add-ons: Random Campaign, Custom Campaign, Ultimate Random Maps, Era of Legends, Gui Debug Tools
Erfworld: The comic that lead me to find Wesnoth.
User avatar
pyrophorus
Posts: 513
Joined: December 1st, 2010, 12:54 pm

Re: lua random map generation

Post by pyrophorus »

iceiceice wrote:Pyrophorus:

Sorry, I was just kidding when I wrote 'this is for you', I only meant that I added the ability to get mt19937 in lua in part because I remembered that you added it for your generator, presumably because you found "rand" inadequate for your needs (I think that's quite reasonable). It is exactly the same PRNG that you are using, and that wesnoth will use generally in 1.13 and forward.
Standard rand gives different results on different platforms. Since I wanted to warrant the same result everywhere, I had to insert a random generator in my program. It's only a few lines of code, and it introduces no external dependency to a lib always subject to changes.
iceiceice wrote:
pyrophorus wrote: Now, I'm not sure your proposal will have any success. IMHO, very few (if any) people want to write map generators, in lua or any other language.
Well some people have already expressed interest, and even if no one else writes one, likely I will. IMO there are several reasons why it's very attractive to have a generator written in lua and integrated.
OK, that's fine...
iceiceice wrote:tekelili: well here's a few reasons why its good to be in lua...
These are very good reasons, but it provides only link to WML and scenarios execution. The buitlin generators are used in the map editor too, and some progress could be made here. It would be convenient to give access to the seed used by these generators: for now, if you change some settings, you will not get the previous map with some changes, but a completely different map. It wouldn't be very difficult to offer the possibility to rerun the generator with new settings and the same seed.

Other things could be done: on modern computers it should be possible to tune generated maps interactively. Suppose you have a slider tuning the forest ratio, you could see the forests shrinking and expanding in real time just as you can change in real time the color of a selection in a graphic editor. Revamping maps could be done too. In other words, produce an enhanced map from a crude draft created in another window.
SigurdFireDragon wrote:I've had some plans for a new map generator for a while, as there are styles of random maps that just can't be done easily with the default generator. Was intending to do it in C++, but I'll be using the lua generator if/when I get to it. Thanks! :)
Feel free to contact me if your are interested in talking on methods and algorithms !

Friendly,
Campaign Return to Noelren *** HowTos: WML filtering, WML variables
Please help to to update the Guide to UMC Campaigns
gfgtdf
General Code Maintainer
Posts: 1344
Joined: February 10th, 2013, 2:25 pm

Re: lua random map generation

Post by gfgtdf »

pyrophorus wrote: Standard rand gives different results on different platforms. Since I wanted to warrant the same result everywhere, I had to insert a random generator in my program. It's only a few lines of code, and it introduces no external dependency to a lib always subject to changes.
There is no reason to beleive the boost::mt19937 would ever be changed to return different results.
pyrophorus wrote: These are very good reasons, but it provides only link to WML and scenarios execution. The buitlin generators are used in the map editor too, and some progress could be made here.
Not only the buildin generators, also custorm map generators (especialy lua map generators) show up in the editor if you want them to.
pyrophorus wrote:It would be convenient to give access to the seed used by these generators: for now, if you change some settings, you will not get the previous map with some changes, but a completely different map. It wouldn't be very difficult to offer the possibility to rerun the generator with new settings and the same seed.
I argeee that having a random map generator result determinitic on the initial parameters + seed is a nice (and normal) thing to have (for the default map generator that currently not the case). But even if that's the case it doesnt nessearily mean that if you change one parameter slightly you'll get a similar map with the same seed, For example if you change one parameter it migth happen that the rng gets called a diffrent number of times in a early step of the map generation so that every rng calls after that is completely different.
pyrophorus wrote: And no, thanks, I will not rewrite my map generator in lua or any other language. I'm perfectly happy with C++, and I don't care about a possible Wesnoth integration. It was Boucman's idea, not mine, and probably not anyone else, because it would already be done yet for a long time.
There might be people in the dev team that would try to integrate it into the core but the yamg is written in a style that is very alien to the rest of the wesnoth code. Especialy the yamg always uses pointer types instead of std:: containers like string or vector.
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.
User avatar
tekelili
Posts: 1038
Joined: August 19th, 2009, 9:28 pm

Re: lua random map generation

Post by tekelili »

gfgtdf wrote:
pyrophorus wrote:It would be convenient to give access to the seed used by these generators: for now, if you change some settings, you will not get the previous map with some changes, but a completely different map. It wouldn't be very difficult to offer the possibility to rerun the generator with new settings and the same seed.
I argeee that having a random map generator result determinitic on the initial parameters + seed is a nice (and normal) thing to have (for the default map generator that currently not the case). But even if that's the case it doesnt nessearily mean that if you change one parameter slightly you'll get a similar map with the same seed, For example if you change one parameter it migth happen that the rng gets called a diffrent number of times in a early step of the map generation so that every rng calls after that is completely different.
It would be also helpfull (as "debugging tool") if [generator] could label hexes in map generated with heights and temperatures iterated for each hex.
Be aware English is not my first language and I could have explained bad myself using wrong or just invented words.
World Conquest II
gfgtdf
General Code Maintainer
Posts: 1344
Joined: February 10th, 2013, 2:25 pm

Re: lua random map generation

Post by gfgtdf »

tekelili wrote: It would be also helpfull (as "debugging tool") if [generator] could label hexes in map generated with heights and temperatures iterated for each hex.
sry but i don't know the implementation details of the default map generator, so i can't help you with "heights" and "temperatures". The statement you quoted was about map generators in general but especialy in the expectation that there will will be more generators with the lua map generators fucntionality.

Currently the map labels are not part of the map format, thats why they will only work on scenario_generation and not with map_generation (note that they were sometimes somfusing in 1.12 (bug #22484) im assuming 1.13 syntax here), but i think it could make sensee to make them part of it.
Scenario with Robots SP scenario (1.11/1.12), allows you to build your units with components, PYR No preperation turn 1.12 mp-mod that allows you to select your units immideately after the game begins.
User avatar
pyrophorus
Posts: 513
Joined: December 1st, 2010, 12:54 pm

Re: lua random map generation

Post by pyrophorus »

gfgtdf wrote:
pyrophorus wrote: Standard rand gives different results on different platforms. Since I wanted to warrant the same result everywhere, I had to insert a random generator in my program. It's only a few lines of code, and it introduces no external dependency to a lib always subject to changes.
There is no reason to beleive the boost::mt19937 would ever be changed to return different results.
It will change when boost dev team will decide to. If you include directly the code, it will change when you decide to.
gfgtdf wrote:
pyrophorus wrote: These are very good reasons, but it provides only link to WML and scenarios execution. The buitlin generators are used in the map editor too, and some progress could be made here.
Not only the buildin generators, also custorm map generators (especialy lua map generators) show up in the editor if you want them to.
pyrophorus wrote:It would be convenient to give access to the seed used by these generators: for now, if you change some settings, you will not get the previous map with some changes, but a completely different map. It wouldn't be very difficult to offer the possibility to rerun the generator with new settings and the same seed.
I argeee that having a random map generator result determinitic on the initial parameters + seed is a nice (and normal) thing to have (for the default map generator that currently not the case). But even if that's the case it doesnt nessearily mean that if you change one parameter slightly you'll get a similar map with the same seed, For example if you change one parameter it migth happen that the rng gets called a diffrent number of times in a early step of the map generation so that every rng calls after that is completely different.
Not so different, because altitudes are created at the beginning of the process in the standard generator. (And in mine, provisions have been to ensure strict repeatability). At least, it would be better than restart each time from scratch.
gfgtdf wrote:
pyrophorus wrote: And no, thanks, I will not rewrite my map generator in lua or any other language. I'm perfectly happy with C++, and I don't care about a possible Wesnoth integration. It was Boucman's idea, not mine, and probably not anyone else, because it would already be done yet for a long time.
There might be people in the dev team that would try to integrate it into the core but the yamg is written in a style that is very alien to the rest of the wesnoth code. Especialy the yamg always uses pointer types instead of std:: containers like string or vector.
I don't know of whom you speak, please give names.

That said I don't see the problem. When planning to use a library, do you go to the developers to say their coding style is very alien to Wesnoth and they should change it ? Then, everyone knows here I'm a professional IT, creating programs for thirty years. And I feel rather offending someone could imagine I could do such unprofessional things as to enforce my own code style in other people work (which most commonly ruin the work without any benefit). If I were maintaining or modifying something in Wesnoth, of course I would conform its rules. Now are you all so shrink minded you can't imagine other people can have other rules just as good as yours and can create good reliable software with them ?

If I don't use std:: containers in my code, it's not out of ignorance. It's only they give no benefit in this particular case, only drawbacks. I work only on fixed size data and move only pointers which is much more efficient and secure than moving and allocating blocks each ten lines of code. As a result, my program takes about 5 micro seconds to compute a 64x64 map. Try it with your standard containers and you'll see the result.

My program is a library who has no dependency on Wesnoth code, so there's no reason it should create problems, and integrating it at WML level is probably less than an hour work (check the YAMG_MapGenerator.cpp). It's only a matter of parameter block adaptation, and you can modify this class as you wish, and even create your own child class of YAMG_Params if you don't like the parser here and want to fill the parameter object in another way. This interface will be maintained in my further developments because the standalone version uses the same.

Now, I'm getting tired of this, because it last for more than two years, and I thougth it was over after asking Shadowm to pull the code out of Wesnoth. Please stop bugging me saying "maybe we could if only it was more Wesnothian, and more C++ ..." (sic). The software is on github and is GPL. You can get it and do what you want with it, even translate it to lua (good luck !), but you'll never make me rewrite it in your style.

Friendly,
Campaign Return to Noelren *** HowTos: WML filtering, WML variables
Please help to to update the Guide to UMC Campaigns
User avatar
iceiceice
Developer
Posts: 1056
Joined: August 23rd, 2013, 2:10 am

Re: lua random map generation

Post by iceiceice »

pyrophorus wrote:
Standard rand gives different results on different platforms. Since I wanted to warrant the same result everywhere, I had to insert a random generator in my program. It's only a few lines of code, and it introduces no external dependency to a lib always subject to changes.
rand indeed gives different results on different platforms, because it is utter crap from 1980. At the beginning Wesnoth also imported the source code of rand into our codebase, I guess because we didn't have any good options. (And it's 3 lines so it actually will be portable pretty much.) However boost::mt19937 (and std::mt19937 in C++11) is guaranteed to be portable -- not only the algorithm but even the implementation is mandated by the standard, they even suggest that everyone add a validating unit test which checks that the 10,000th draw for some particular seed is some particular 32 bit integer: http://www.boost.org/doc/libs/1_38_0/li ... m_test.cpp

That test will pass for any boost library you encounter in the wild, or it means that someone has a *broken* library and it is a problem for the implementer to solve, not you.

On the other hand, if you just take the original reference implementation produced by the creators (two Japanese professors) as you seem to have in the YAMG source, (and as you suggested that we do before on the email list): https://github.com/wesnoth/wesnoth/blob ... .cpp#L2020

there's no one who is actually giving you a cross-platform guarantee there. It's simply the reference implementation, meant to show that it works and written for clarity. To actually have confidence that it works with all major compilers in combination with all major operating systems, you need experts like the people at boost to think about all the possible things that can go wrong, possibly pepper it with preprocessor checks, etc. etc. (Or you might be such an expert yourself... I'm certainly not an expert on such things.)

It's true that boost random may change of course, but if it did it would be to add new features or to fix bugs that broke this thing, i.e. if for some platform/compiler combination it didn't work, or went extremely slowly, or some other bug.

For instance, here's the boost version: http://www.boost.org/doc/libs/1_56_0/bo ... wister.hpp
Apparently they totally rewrote it with templates etc. Note also this line: "The seeding from an integer was changed in April 2005 to address a <a href="http://www.math.sci.hiroshima-u.ac.jp/~ ... eakness</a>."

You *want* those changes from upstream, otherwise finding such bugs and fixing them in your program becomes *your problem*. And it is notoriously difficult for users spot a bug in an RNG... it might look totally normal to you for years, then you decide to write a new feature and now all the new output looks ****ed and you cannot figure out for the life of you why. So it's a very good idea to link dynamically with a lib like this for RNG, and not import the source in tree, in my opinion. If you're imaginging that boost will just randomly decide to change the output of the generator, i.e. to change the specs and start failing this test everywhere that they told everyone to put in their code... it would be very irrational, quite possibly many people would stop using the boost RNG after that, after all the promises they made.
pyrophorus wrote: If I were maintaining or modifying something in Wesnoth, of course I would conform its rules. Now are you all so shrink minded you can't imagine other people can have other rules just as good as yours and can create good reliable software with them ?
I don't think anyone thinks you can't make good reliable software in C, it's just that wesnoth is written in standard C++ using the standard libraries and idioms. In most places in the code we need to use C++ containers for exception safety -- it's considered that the difference in speed between C++ vectors and C arrays / C linked lists is a premature optimization from the point of view of the wesnoth project at large. Now you aren't using any exceptions of course, but it actually makes quite a bit of sense for us to insist that people use C++ containers generally, because the majority of contributors are students and not self-described IT professionals of 30 years, and the people who will have to maintain it are also not IT professionals of 30 years.

Regardless, it was never my intention to stir up this hornets' nest by suggesting that you might want to use lua... please do things however you like.
User avatar
pyrophorus
Posts: 513
Joined: December 1st, 2010, 12:54 pm

Re: lua random map generation

Post by pyrophorus »

iceiceice wrote: It's true that boost random may change of course, but if it did it would be to add new features or to fix bugs that broke this thing, i.e. if for some platform/compiler combination it didn't work, or went extremely slowly, or some other bug.

For instance, here's the boost version: http://www.boost.org/doc/libs/1_56_0/bo ... wister.hpp
Apparently they totally rewrote it with templates etc. Note also this line: "The seeding from an integer was changed in April 2005 to address a <a href="http://www.math.sci.hiroshima-u.ac.jp/~ ... eakness</a>."

You *want* those changes from upstream, otherwise finding such bugs and fixing them in your program becomes *your problem*. And it is notoriously difficult for users spot a bug in an RNG... it might look totally normal to you for years, then you decide to write a new feature and now all the new output looks ****ed and you cannot figure out for the life of you why. So it's a very good idea to link dynamically with a lib like this for RNG, and not import the source in tree, in my opinion. If you're imaginging that boost will just randomly decide to change the output of the generator, i.e. to change the specs and start failing this test everywhere that they told everyone to put in their code... it would be very irrational, quite possibly many people would stop using the boost RNG after that, after all the promises they made.
And all this is exactly the reasons why I wouldn't use it. Wesnoth is not a Monte Carlo simulator for use in nuclear physics and needs not this "weakness addressing". And if your program uses the Mersenne Twister as a repeatable huge list of uncorrelated integers (which is not the main purpose of the thing and probably a very marginal use), this change will ruin all the work created with it. Now, if you look at the original code of the Mersenne Twister, you'll find it uses only arithmetic operations on integers. You may think some combination of processor/compiler/system could give different behaviors, but it would be like asserting on some computers the result of 2 + 2 could be 3. Now, if you rewrite it using templates or I don't know what, yes, you can introduce dependencies to the compiler.

Now, the real question is: do we need it ? (I'm not speaking in general of standard C++ PRNG users and boost developers). Since any library introduces a new maintenance point and at least one potential failure point (it's a fact, we can't help it), the question is "is it worth to be done ?". Of course, if it was a file management library or a protable graphic library, the reply would be yes. But for myself (meaning my use), I reply definitely no. I can't reply in the name of future map generator developers, but I guess most of them will be more aware of repeatability than any probabilistic property. Wesnoth uses a PRNG to compute battles too, and the needs are not the same. Here, you may want to use the boost library, even if I doubt it would improve anything (but certainly introduce potential problems, see the Penta thread about compiling Wesnoth for details).
iceiceice wrote:I don't think anyone thinks you can't make good reliable software in C,
Please, stop saying such inaccurate things which obfuscate the debate. My program wouldn't compile on a C compiler, because it uses inheritance and polymorphism. And by the way, C is still a part of standard C++. C++ is not only using the std::things, but mainly an object oriented programming language (and historically speaking, much earlier than any std containers apparition).
iceiceice wrote: it's just that wesnoth is written in standard C++ using the standard libraries and idioms. In most places in the code we need to use C++ containers for exception safety -- it's considered that the difference in speed between C++ vectors and C arrays / C linked lists is a premature optimization from the point of view of the wesnoth project at large. Now you aren't using any exceptions of course, but it actually makes quite a bit of sense for us to insist that people use C++ containers generally, because the majority of contributors are students and not self-described IT professionals of 30 years, and the people who will have to maintain it are also not IT professionals of 30 years.
But what's the purpose of all this ? Did I ever say somewhere I would like to enforce others rules in Wesnoth development ? Did I ever say I had something against std:::containers use in general ? I only said I will not rewrite my program using Wesnoth rules and suggest you could use it as a library or a separate tool if really you want it. If not, it can live its own life, and I never asked more.

Why are you dragging here your particular concerns ? I'm not interested in debates around programming techniques as you are. 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 rationalize the unit modification system (which is for now splitted in various different tags), or map editor enhancements, not in useless optimizations as you suspect I would. Even in this thread, I suggested some features ideas, and your reply is only justifications about your programming practices, and suggesting I'm telling lies about my experience. It's just ridiculous and boring.
iceiceice wrote: Regardless, it was never my intention to stir up this hornets' nest by suggesting that you might want to use lua... please do things however you like.
Then name me not and stop trying to teach me on things I know better than you.
Campaign Return to Noelren *** HowTos: WML filtering, WML variables
Please help to to update the Guide to UMC Campaigns
User avatar
iceiceice
Developer
Posts: 1056
Joined: August 23rd, 2013, 2:10 am

Re: lua random map generation

Post by iceiceice »

pyrophorus:

I have absolutely *zero* knowledge or interest in the history of YAMG, why it is or isn't in which of our trees etc. ... please keep in mind that I have only been around for 1 year. YAMG is currently in master, and was removed in 1.12. You can be sure that I did look at the code, for this reason, and it is occasionally discussed on irc, for this reason. If you would like it to be completely deleted from the project and put the whole thing to rest, let me know and I will delete it from master as well.

The purpose of this thread was to announce and give place to discussion of a new feature which I created. The subject of YAMG was broached purely accidentally. I am *reiterating* this, so that you can disabuse yourself of the notion that I was somehow passive aggressively criticizing it or trying to bump the topic of integrating it. Really I never had any idea that it was some other dev's idea and not yours to integrate it... I did not read it anywhere but here.

I seriously apologize for provoking you in this way. I also apologize for even tangentially bringing up the topic of RNG implementations which has often seemed angry and totally unproductive. I won't apologize for this accusation "suggesting I'm telling lies about my experience", because I think it was obviously not my intention and it is unfair to me to try to interpret my remarks this way. For any other way that I have incidentally disturbed you, I do apologize.

In return, please stop criticizing the RNG methods that we have chosen for the game, our policies regarding code, and our other practices, even if you feel it's misguided or that you know better. At least not in this thread. You are welcome to criticize things we do but please do it in a different thread.

Anyways I think it would be very good if we would both stop bristling at perceptions of the other telling us how we should do things, when it seems neither intended this.
User avatar
Iris
Site Administrator
Posts: 6745
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Re: lua random map generation

Post by Iris »

Before people get the wrong idea:
pyrophorus wrote:[...] I thougth it was over after asking Shadowm to pull the code out of Wesnoth.
To my recollection, I have never been asked to do any such thing. I merely saw a comment last month suggesting that this might be desirable because of the code being considered “dead” for some reason. I then informed you that the same developer who originally committed the code had done this for the 1.12 branch in particular, and decidedly not master (1.13.x). The integration or removal of this code (and the crux of the issue is that we might have wrongly assumed it was intended to become an integral part of Wesnoth and not linked as an external/bundled library) is not and has never been my responsibility. You are, of course, free to PM me if I actually forgot or missed something and I shall rectify this post accordingly.

[/tangent]
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm (now available for Wesnoth 1.14.x and 1.15.4+).
Post Reply