You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(19) |
Jun
(30) |
Jul
(22) |
Aug
(61) |
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(1) |
Feb
(8) |
Mar
(6) |
Apr
|
May
(5) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(1) |
2002 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(17) |
May
(29) |
Jun
(15) |
Jul
(8) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(13) |
2003 |
Jan
(36) |
Feb
(17) |
Mar
(1) |
Apr
(5) |
May
(8) |
Jun
(5) |
Jul
(8) |
Aug
(29) |
Sep
(21) |
Oct
(181) |
Nov
(28) |
Dec
(102) |
2004 |
Jan
(61) |
Feb
(10) |
Mar
(8) |
Apr
(14) |
May
(4) |
Jun
(2) |
Jul
(16) |
Aug
(11) |
Sep
(28) |
Oct
(43) |
Nov
(23) |
Dec
(18) |
2005 |
Jan
(22) |
Feb
(5) |
Mar
(41) |
Apr
(8) |
May
(6) |
Jun
(30) |
Jul
(12) |
Aug
(5) |
Sep
(1) |
Oct
(4) |
Nov
(16) |
Dec
(46) |
2006 |
Jan
(22) |
Feb
(27) |
Mar
(30) |
Apr
(89) |
May
(44) |
Jun
(19) |
Jul
(24) |
Aug
(25) |
Sep
(27) |
Oct
(55) |
Nov
(87) |
Dec
(79) |
2007 |
Jan
(50) |
Feb
(28) |
Mar
(38) |
Apr
(27) |
May
(27) |
Jun
(31) |
Jul
(50) |
Aug
(52) |
Sep
(36) |
Oct
(29) |
Nov
(33) |
Dec
(45) |
2008 |
Jan
(9) |
Feb
(2) |
Mar
(7) |
Apr
(5) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
(3) |
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(6) |
Nov
|
Dec
|
2011 |
Jan
(10) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(4) |
Aug
(1) |
Sep
(4) |
Oct
(6) |
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
(3) |
Mar
(2) |
Apr
(28) |
May
(5) |
Jun
(10) |
Jul
|
Aug
(14) |
Sep
(9) |
Oct
(1) |
Nov
(3) |
Dec
(5) |
2014 |
Jan
(1) |
Feb
(16) |
Mar
(9) |
Apr
(2) |
May
(1) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Roland C. <rc...@us...> - 2020-05-07 06:22:06
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Forwarding the mail to the list - -------- Forwarded Message -------- Subject: Re: patch voor pioneers Date: Wed, 6 May 2020 11:11:36 +0200 From: Roland Clobus <rc...@rc...> To: Hans Dingemans <han...@ta...> CC: pio...@li... <language is Dutch, partial translation below> Hallo Hans, On 05/05/2020 17:06, Hans Dingemans wrote: > Allereerst bedankt voor het mooie spel "Pioneers", waar jij en je > collega-ontwikkelaars enorm veel tijd in gestoken moeten hebben. In > deze tijden is zo'n online spel een uitkomst! > > Ik ben een hartstochtelijk ondersteuner van open source, en mede > daarom heb ik een kleine patch gemaakt, met twee features: 1) > autoroll: automatisch rollen van de dobbelsteen als je aan de > beurt bent; waarom de gebruiker op de knop laten drukken als de > computer het kan doen? Bedenk wel dat spelers met een ridder-kaart soms vóór het rollen hun kaart willen spelen, zodat ze niet last hebben van de struikrover. > 2) autoreject: automatisch verwerpen van handelsaanbiedingen waar > je niet aan kunt voldoen (omdat je de gevraagde resources niet > hebt). > > Mocht je geïnteresseerd zijn om 'm uit te testen en eventueel op > te nemen in de volgende release, laat me dan weten waar de patch > naar toe moet. Dank je wel voor de ideeën. Ik ben op het moment bezig met diverse kleine wijzigingen, en jouw wijzigingen kan ik meenemen voor de volgende release. Je kunt de patch sturen naar pio...@li... (je hoeft niet per se lid van de mailing list te zijn, maar dan krijg je eerst een waarschuwing. Ik kan dan jouw mail modereren en doorlaten). Of je maakt een ticket aan op https://sourceforge.net/p/pio/patches/ Met vriendelijke groeten, Roland Clobus - --- Partial translation: Hans Dingemans prepared a patch with two new features: * Autoroll: roll the dice without pressing the Roll button * Autoreject: reject trade when you cannot comply with the offer due to missing resources -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEUFVLM5Bdj7GSJEb+YsV8aqYUlb0FAl6zpfcACgkQYsV8aqYU lb1kjA/7Bd2ngM7SOIMrnSid9RWb8nDX5FFNh5+GEp3kxM648nJG1P87UTDv0OfU MrzKdzysQmwXu7gruGLplWbCwQ0mhNC5mYjyKXBPZ9rP2igpH5PTt/g/vE3TF3j7 9/5MsUA1PlS6GBcpqkCaA42bBb8etwNQhJ/QtBtg0z8OUkWzjUEXYI5y2xHSPP1/ ztaCH/vbNpYCdaC9Lg3TzLm7rqsveg/VbnZIdwFnLWYMRHjZnc3prFWIXeFo0p14 +uaHkh494y3WGCxgvlWslOwRCAQ1y1LoZPuj448TbkJ2iJhVYQwW2bCzIMZWJIZz XtDwhNjaojQYQ/tyM9xccODkXu3xPV7wXljUk3lOo2pz29InoiFPagWBJ9t9xfvz j5YIVpcdYINLRNPPwobL54Zuh9VgAHIfQ4Te9KdzA0NyqyaHLlQAuuYlwMqBzigw a4vBhE8YkYqt73LJvnXyBuHWC54CnC0S6WDeIfR4S0o/q+c5l8vYTQJg+R0S+Ent 73Y5DdsRRg6HD/FU0DMIL5tvwR4uqnIcxQ859DmoFZaRALEvTAE8lnMFvcMYZTa3 HilXKlw0a7RQ6WaszYPiU+YAmQvUmON0INB9OpvJFBaRG5OGAlZ8wIybLYh5jzZN nlJBtNLNZSc3djGZfWa1QlHg1NyRFZC0TgzqcIa5g8BtoKnWcLo= =zfd5 -----END PGP SIGNATURE----- |
From: Hans P. M. <hm...@gm...> - 2018-03-27 11:50:36
|
Hi, nice implementation. Is there an API so anyone can develop a computer player? thanks! brgds HPM |
From: Andreas S. <a.s...@gm...> - 2016-08-21 19:52:40
|
Hi all, I updated my patches to the metaserver to recent versions of pioneers (stretch and svn version). svn is not compilable due to GTK3 deprecation warnings on Jessie (had to manually disable via autoconf). Maybe Roland can take a look at them this time. On Sun, Sep 15, 2013 at 4:05 PM, Andreas Steinel <a.s...@gm...> wrote: > I implemented an addition to the meta-server which triggers a command (if > present) given on the command line of the server. The patch works for me > and could be integrated into mainline pioneers (my patch is against stable). > > I tried to stick to the code formatting as close as possible. > |
From: Roland C. <rc...@us...> - 2015-01-10 11:35:18
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello all, I've changed the settings of the mailing lists. Instead of rejecting mail for non-members, the mail is now placed in the moderation queue. In the past the mailing lists were hit by spambots, but lately I noticed that opening the list a little bit more (moderation for non-member) can keep the spam out of the list for all subscribers, but still allow the occasional poster to post about Pioneers. With kind regards, Roland Clobus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUsQtnAAoJEGLFfGqmFJW95e0P/2m5Lqb+JiV8TikfzcMesV8C 1Yal/u14Iw76Opk6QiY/vfNeGMa8d6NC/tynTZSq2S6slxrWSMuvQ0ZF4i2ay0nS n8XjE1hD6UVvp7gA5yvjObsWlqWldbk5edWsegCeNVwKq8AXGESfL/tnC6JWrils MIdynUplWvkvdQdsfa+FPhwSBD+oPCJmmEP/TwJ76PZfaKfMp6mxFVquauTCIUS0 1jBLd9eFPP1ZhclUrtOOvJccDRRDXowOYPA+ZCABhOMJhWBiPOXyZs6BO0XYzk23 ImQAYFa+vwxMYU/okh3UnBCUJ7nZT1MPj/+TvoBfvTkPZlJg3Xn7YQCm7pSdT3KU MlsJvCrHIhvUzubjbz/Sma2QGd74886MpOy6vVMz1U2/YgSqe4SVYQaQ0LQs69Uo jTCGaaz/tp64gzUJWtINZEoZT//9qBdynpTJewAdOexn+pA/6BWScU0oe7D7R/ET pgIgN+Vninsow2GfSpswrjbm5y5U+nvfR2/KJDJO4v5LQc8MW80Vu4xLiCqtqlO+ XFUn0IReuPortcBNQ+i0bvHWQUWtNKiWMo5YWsGGVKHkP9JPc/jCBVjtepw2xAd1 kg7g0BB4oRFQ3SqVKI0MY9cwsMFLronkgzVhUXkSy7HDiKkwq+z5iB+wJJ07riCu Ga3ZBE3vGkW6Q439+ypV =+Wyt -----END PGP SIGNATURE----- |
From: Andreas S. <a.s...@gm...> - 2014-08-27 19:33:42
|
Hi All, I am currently playing with the game and one thing could be a huge timesaver: Visual Display if someone is still the current player. I play in a group of people from different locations and often one forgets to click the 'finish' button and it take some minutes if the others 'ping' this player via chat. I think a green bar would be perfect to signalize that there is something missing. For the 'it's your turn' signalling, I patched the execution of a small Growl bash script in pioneers on mac. What do you guys thing about such a visual reminder? Best, Andreas |
From: Roland C. <rc...@us...> - 2014-06-03 06:39:04
|
Hello Rodrigo, On Sat, 2014-05-31 at 19:12 +0200, Rodrigo Espiga Gómez wrote: > Hi everyone! I have a question regarding the type of board used when > the game is launched from the console with, for example > pioneers-server-console --port 6000 --auto-quit --fixed-seating-order > --game-title "Default" --players 4 -x > I understand that this is the "Default" hexagonal board but I´m not > sure if the terrain tiles are randomized or they are always in the > same places. Use the command line you've mentioned twice (with different ports), and you'll see that the terrain tiles are shuffled, but that the numbers are in the same place (except where the desert tile shifts the numbers) If you want to have identical games, you can fix the random seed in random.c:random_init to a constant value. > I can see there is a --terrain option and it seems I have to pass > --terrain=1 to randomize the terrain, otherwise it is not. I am a bit > confused because the default option with the graphic interface seems > to be randomized terrain (the checkbox is ticked by default). > The Genetic Algorithm uses that command line and I´m not sure if it is > learning to play in an exact board cofiguration or not. > What board does it exactly use with that command line? If you notice that you get identical board layouts, could you send a screenshot, the command line and at least two lines that are written by pioneers-server-console, like these: <quote> - Preparing game #2328176452.G.588 </quote> With kind regards, Roland Clobus PS1: How was your report received? PS2: Can you send the scripts that you've used to train the AI? |
From: Rodrigo E. G. <rod...@ho...> - 2014-05-31 17:12:44
|
Hi everyone! I have a question regarding the type of board used when the game is launched from the console with, for example pioneers-server-console --port 6000 --auto-quit --fixed-seating-order --game-title "Default" --players 4 -x I understand that this is the "Default" hexagonal board but I´m not sure if the terrain tiles are randomized or they are always in the same places. I can see there is a --terrain option and it seems I have to pass --terrain=1 to randomize the terrain, otherwise it is not. I am a bit confused because the default option with the graphic interface seems to be randomized terrain (the checkbox is ticked by default). The Genetic Algorithm uses that command line and I´m not sure if it is learning to play in an exact board cofiguration or not. What board does it exactly use with that command line? Thanks! |
From: Rodrigo E. G. <rod...@ho...> - 2014-04-24 16:08:41
|
Thanks a lot Roland for all your comments. Right now I have to write down a report with the results of the experiments and I have a deadline on that, so I will make those changes as soon as I can. I will also unlock the internal trade, cause right now it does not initiate it to avoid giving it an edge over greedy during evolution. But once the chromosome is evolved, it uses the same logic behind bestStrategy to find out if the profit of the best strategy can be improved by an exchange. I think this can lead it to make intelligent tradings with other players, and also a more interesting AI to play against by humans. Saludos! |
From: Roland C. <rc...@us...> - 2014-04-18 14:36:23
|
Hallo Rodrigo and list, The genetic computer player is playing better than the greedy player. My test results so far in the default game, with 2 classic computer players and 2 genetic players: classic vs. genetic = 1 vs 4 won games. I've done a code review of the new code. Most are relatively minor issues, but will make maintenance easier. - Could you run 'make reindent' before committing to svn? That will minimize the amount of changes. (Your editor appears to use a tab size of 4, while the other source code assumes a tab size of 8). - I've already run 'make reindent' and committed the changes, so I suggest you run 'make reindent' before 'svn update', otherwise you'll get many nasty merge conflicts. - Try to keep the amount of changes small, run 'svn diff' to see if you are about to commit some unneeded white space changes. - Try to avoid magic numbers. In reevaluate_gameState_supply_matrix_and_resources I see '10' and '5'. You can use the GLib macro 'G_N_ELEMENTS', In outputChromosome you use the value of 9. Try to use either 9 or 10. - Use the datatypes in GLib, especially gboolean and TRUE/FALSE, that makes the code easier readable (see e.g. facingOK) - Avoid the pattern 'if (A) { return TRUE } else { return FALSE }', use 'return (A)' instead. - Use a typedef for your structs and enums, so you don't have to use the keyword 'struct' or 'enum' in every function call. - In facingOK: 'nodeTwo = hex->nodes[(hex->facing + 5) % 6]' does the same as the if-statement - Instead of keeping your template code around in '#if 0', remove it when you are done with it. - Instead of 'printf', use GLib's 'g_print' (or g_printf). This will remove the need to include stdlib.h and stdio.h - Instead of 'sleep' use 'ai_wait', or if you need only one millisecond, use 'g_usleep(1000u)' (I've replaced the call to sleep with 'ai_wait', because the sleep function broke the Windows build). - In checkRoadNow: It is not necessary to place a break after a return statement. - If you intend to keep the code in genetic_core.c separate from genetic.c (so you might use it with another main(), I suggest to create a regular 'genetic_core.h' file to contain the function prototypes. If you have trouble integrating it in the Makefiles, contact me. - genetic_game_over: You can use the argument points instead of 'player_get_score(my_player_num())' (and thus remove the G_GNUC_UNUSED for points) - Instead of commenting and de-commenting your debug messages, you can add '#define GENETIC_DEBUG' and '#ifdef GENETIC_DEBUG...#endif' I've prepared a patch [1], which should be applied to svn revision 2066, which removes all duplicated code related to the chat-behaviour of the computer player to the main code file (ai.c). I've noticed that this might break your code by introducing many merge conflicts, so I'll apply it only when you agree. With kind regards, Roland Clobus [1] https://sourceforge.net/p/pio/patches/677/ |
From: Roland C. <rc...@us...> - 2014-03-19 21:12:47
|
Hello Rodrigo, On Wed, 2014-03-19 at 19:38 +0100, Rodrigo Espiga Gómez wrote: > I ... have added > {"chromosome-file", 'f', 0, G_OPTION_ARG_STRING, &chromosomeFile, > N_("Chromosome File"), NULL} > to commandline_entries[], where chromosomeFile is defined as > static char *chromosomeFile = NULL; > Is that correct? (Sorry, I don't have experience using GOptionEntry). > Now my question is, where in the code can I access the file passed to > pioneersai through --chromosome-file=oneChromosome If you declare the variable chromosomeFile as static, it will only be accessible inside the file you declared it in, i.e. ai.c. So you'll need to declare the variable 'extern char *chromosomeFile;' in ai.h, then you can access the variable in any file that includes ai.h. You still need the definition in ai.c, but then without the static keyword. For the second argument in the commandline_entries[] I would suggest '\0' instead of 'f', to disable the short command line option (I would prefer that only the historical and most often used options have single letters) > > I have a question regarding providing a chromosome. > > When somehow the best chromosome was determined, could the genetic > > computer player always use that, or does it make sense for regular > players > > to provide chromosome files? > > My plan is to have a "default" chromosome harcoded inside genetic.c > that would be used when no one else is provided. That default > chromosome would basically be the result of the evolution when the > Default game is used with randomized terrain. But I want the user to > be able to provide their own chromosomes if they want. I am not gonna > evolve a chromosome for any game possible, but I want to be able to do > it in the future. > > > If a typical use case does not require the modification of the > chromosome, > > I would suggest you place the chromosome handling code in an #ifdef, > which > > is only activated during the training of the computer player. (I > assume > > that you will commit the training scripts as well) > > > > #ifdef GENETIC_EXTERNAL_CHROMOSOME > > ... code here ... > > #endif > > I'm not sure if I understand the question. The chromosome itself is > never modified. It just defines the way a given genetic player plays. > The evolution just involves playing hundreds of games with different > chromosomes until we find a good one. You have answered the question: It is a typical use case that a user provided his/her own chromosome, therefore there will be no need to disable the handling of the chromosome file in #ifdef statements. > It is the training script who generates different chromosomes and > launches the games. And by the way, I will commit it too, of course, > it's only that right now is a mess of spanish comments and bad quality > code ;) That is where subversion comes in handy: whenever you make a change you can trace back your steps. The initial version does not need to be perfect. The genetic algorithm functionality is pretty well isolated from the rest of the code, therefore I suggest to commit often. With kind regards, Roland Clobus |
From: Rodrigo E. G. <rod...@ho...> - 2014-03-19 18:38:08
|
> Date: Wed, 19 Mar 2014 11:30:33 -0500 > From: rc...@us... > To: pio...@li... > Subject: Re: [pio-develop] Modifications needed to pass chromosome to Genetic AI > > Hello Rodrigo, > > > As Bas proposed, I think the best option would be to add the file to the > > algorithm argument. The chromosome file would be like the file attached, > > just a plain text file with the values to be passed to thisChromosome > > variable inside genetic.c. > > I see another option: add '--chromosome-file' to the list of allowed > command line arguments in ai.c(commandline_entries). > This would not add a double meaning to the --algorithm argument. > If you want to provide the file name after the semicolon, you'll need to > modify ai.c as well (strcmp -> strncmp). I have taken that approach and I have added {"chromosome-file", 'f', 0, G_OPTION_ARG_STRING, &chromosomeFile, N_("Chromosome File"), NULL} to commandline_entries[], where chromosomeFile is defined as static char *chromosomeFile = NULL; Is that correct? (Sorry, I don't have experience using GOptionEntry). Now my question is, where in the code can I access the file passed to pioneersai through --chromosome-file=oneChromosome > I have a question regarding providing a chromosome. > When somehow the best chromosome was determined, could the genetic > computer player always use that, or does it make sense for regular players > to provide chromosome files? My plan is to have a "default" chromosome harcoded inside genetic.c that would be used when no one else is provided. That default chromosome would basically be the result of the evolution when the Default game is used with randomized terrain. But I want the user to be able to provide their own chromosomes if they want. I am not gonna evolve a chromosome for any game possible, but I want to be able to do it in the future. > If a typical use case does not require the modification of the chromosome, > I would suggest you place the chromosome handling code in an #ifdef, which > is only activated during the training of the computer player. (I assume > that you will commit the training scripts as well) > > #ifdef GENETIC_EXTERNAL_CHROMOSOME > ... code here ... > #endif I'm not sure if I understand the question. The chromosome itself is never modified. It just defines the way a given genetic player plays. The evolution just involves playing hundreds of games with different chromosomes until we find a good one. It is the training script who generates different chromosomes and launches the games. And by the way, I will commit it too, of course, it's only that right now is a mess of spanish comments and bad quality code ;) > > > Where is the best place to put the code that access to that file? Inside > > genetic_init? Or should I define the callback.init_game=&genetic.init_game > > and place the code there? > > And what do I have to modify to let genetic algorithm accept that file? I > > think it would be perfect to pass the file the way Bas said > > (--algorithm=genetic:/path/to/file.txt). Is it necessary to modify > > pioneersai in order to do that? > > So my proposal is that you modify ai.c to add an extra command line > argument in an #ifdef statement. > > With kind regards, > Roland Clobus > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Pio-develop mailing list > Pio...@li... > https://lists.sourceforge.net/lists/listinfo/pio-develop |
From: Roland C. <rc...@us...> - 2014-03-19 16:56:52
|
Hello Rodrigo, > As Bas proposed, I think the best option would be to add the file to the > algorithm argument. The chromosome file would be like the file attached, > just a plain text file with the values to be passed to thisChromosome > variable inside genetic.c. I see another option: add '--chromosome-file' to the list of allowed command line arguments in ai.c(commandline_entries). This would not add a double meaning to the --algorithm argument. If you want to provide the file name after the semicolon, you'll need to modify ai.c as well (strcmp -> strncmp). I have a question regarding providing a chromosome. When somehow the best chromosome was determined, could the genetic computer player always use that, or does it make sense for regular players to provide chromosome files? If a typical use case does not require the modification of the chromosome, I would suggest you place the chromosome handling code in an #ifdef, which is only activated during the training of the computer player. (I assume that you will commit the training scripts as well) #ifdef GENETIC_EXTERNAL_CHROMOSOME ... code here ... #endif > Where is the best place to put the code that access to that file? Inside > genetic_init? Or should I define the callback.init_game=&genetic.init_game > and place the code there? > And what do I have to modify to let genetic algorithm accept that file? I > think it would be perfect to pass the file the way Bas said > (--algorithm=genetic:/path/to/file.txt). Is it necessary to modify > pioneersai in order to do that? So my proposal is that you modify ai.c to add an extra command line argument in an #ifdef statement. With kind regards, Roland Clobus |
From: Rodrigo E. G. <rod...@ho...> - 2014-03-18 07:52:48
|
Ooops! I forgot to write down te mutation step, that's true. It will be done after step 6. I also think the extra argument approach is the best one. Date: Tue, 18 Mar 2014 00:31:36 +0100 From: wi...@de... To: pio...@li... Subject: Re: [pio-develop] Passing a particular chromosome to genetic AI On Mon, Mar 17, 2014 at 07:46:56PM +0100, Rodrigo Espiga Gómez wrote: > Hi Roland and others! Hi! > Genetic AI is working right now, Cool! > To give you an idea of the process from now on it would be like this I'm missing the "random mutation" step, which is normally required for proper evolution. Otherwise you only get degradation of the starting pool, and nothing new ever evolves (apart from combinations of existing things; I'd still expect a decent result, but not as good). > So I need genetic to use different chromosomes. > The best way would be having the chromosome information on an external > file that would be passed to pioneersai as an argument. It would be possible to add an extra argument to pioneersai for this purpose, or perhaps better, to add it to the algorithm argument: --algorithm=genetic:/path/to/file.txt Another option would be to use an environment variable which contains the filename (or the chromosome itself, if it's not too long). > Another approach to avoid any modification to pioneersai is having > all the chromosomes of one generation on a single file That doesn't sound very flexible; passing every invocation its own chromosome sounds much better. Thanks, Bas ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Pio-develop mailing list Pio...@li... https://lists.sourceforge.net/lists/listinfo/pio-develop |
From: Bas W. <wi...@de...> - 2014-03-18 00:04:22
|
On Mon, Mar 17, 2014 at 07:46:56PM +0100, Rodrigo Espiga Gómez wrote: > Hi Roland and others! Hi! > Genetic AI is working right now, Cool! > To give you an idea of the process from now on it would be like this I'm missing the "random mutation" step, which is normally required for proper evolution. Otherwise you only get degradation of the starting pool, and nothing new ever evolves (apart from combinations of existing things; I'd still expect a decent result, but not as good). > So I need genetic to use different chromosomes. > The best way would be having the chromosome information on an external > file that would be passed to pioneersai as an argument. It would be possible to add an extra argument to pioneersai for this purpose, or perhaps better, to add it to the algorithm argument: --algorithm=genetic:/path/to/file.txt Another option would be to use an environment variable which contains the filename (or the chromosome itself, if it's not too long). > Another approach to avoid any modification to pioneersai is having > all the chromosomes of one generation on a single file That doesn't sound very flexible; passing every invocation its own chromosome sounds much better. Thanks, Bas |
From: Rodrigo E. G. <rod...@ho...> - 2014-03-17 18:47:03
|
Hi Roland and others! Genetic AI is working right now, given the testing chromosome that is harcoded inside it. And now it's when fun part comes: evolution. But in order to evolve the algorithm I need to run hundreds of games, generation after generation, using different chromosomes, and I need genetic to use a given chromosome when is called. To give you an idea of the process from now on it would be like this (at least fundamentally, numbers may vary, and the exact methods have yet to be decided): 1- A set of 100 randomized chromosomes are generated. 2- 100 games (with one genetic and three greedy players) are launched, each genetic player using one of those chromosomes. 3- Outcome (victory points) of every genetic player is recorded along with its chromosome (and probably other information for statistical purposes). 4- Each player (chromosome) has a probability of being selected for the next generation that depends on its fitness (victory points) in the previous generation. 5- 100 selections of one chromosome are done, based on those probabilities (some chromosomes could be selected more than once, others none). 6- Selected chromosomes are crossed in pairs, crossbreeding their genetic information, and their offspring are inserted in a new generation (some chromosomes could passed to the next generation unmodified, that depends on the method used). 7- With this new generation of 100 chromosomes, we go back to step 2 a repeat the whole process. This sequence of steps is repeated until certain stop condition is met (usually depending on the concurrency of the chromosomes), or a maximum number of generations is run (about 500). This method will presumibly yield an optimal chromosome whose fitness has been proved after generations. This method can be reproduced for any given game configuration so it could learn for example that one resource is more important than other in certain type of game, or that ports are more valuable in other, etc. So I need genetic to use different chromosomes. The best way would be having the chromosome information on an external file that would be passed to pioneersai as an argument. That way I could evolve a "universal" chromosome that could be passed to any game, and specific chromosomes to be passed for specific games as well (like Ubuntuland, and the like. Genetic would then use the "generic" chromosome (hardcoded inside it) if no one else was given. Otherwise, it would use the values inside that file (that could be just a plain text file). However, this approach needs some modification to the way pioneersai works, so it accepts this chromosome file as part of the options when genetic is passed as the AI. Another approach to avoid any modification to pioneersai is having all the chromosomes of one generation on a single file (my plan is to have generations of 100 chromosomes/players). Genetic would then take the information from that file and would take the chromosome inside that file that corresponds to its name inside the generation (assuming its name can be associated with a given chromosome inside the chromosomes file, naming each player, e.g., Genetic1, Genetic2, and the like). After a whole generation is run, this file would be modified to hold the new chromosomes, and would be used by the next generation run. That way there is no need to specify a chromosome file cause all the chromosomes are in the same file. Once the evolution has concluded, I would eliminate any reference to that file and hardcode that winning chromosome inside genetic.c. The drawback of this method is that is very rigid, and lacks all the possibilities of passing different chromosomes for different games, or even giving the user the possibility of passing its own chromosomes, that the first method does have. Which one do you think is better? |
From: Roland C. <rc...@us...> - 2014-03-04 13:58:21
|
Hello Rodrigo, On Sun, 2014-03-02 at 18:47 +0100, Rodrigo Espiga Gómez wrote: > Sorry, but I have checked the code in editor.c and I still don´t get > it. I understand that facing indicates the direction where there is a > “normal” hex adjacent to a SEA_TERRAIN one, and that in that direction > is where the port is (in case the sea hex has one). But what does it > happen with (lines 748-758 in editor.c) In these lines, the editor determines whether the current tile has a port, and that at least one land tile surrounds it. > …when the sea hex is adjacent to more than one hex? Or is it not > possible? A sea hex can be adjacent to a maximum of six (6) hexes, when it is an inland lake. > Because the first valid adjacent hex sets facing and exits the loop, > and since hexes are checked counterclockwise it could set facing to > face the wrong hex if that is possible. But I don´t understand how > facing should be used anyway, cause inside greedy.c there is no > mention to it, so I don´t know if I need it. The computer player in greedy.c does not evaluate a hex/edge/node based on whether it contains a port. If that player (by accident) has a port, it will use it, but it will not try to build a road towards a port (with the exception for one (the first) 3:1 port). > In my code, in order to check whether a node has access to a generic > port, inside genetic.c I´ve tried to mimic the way it is used inside > score_node, but when I look at (lines 445-447 in greedy.c, in > score_node) The greedy algorithm does only evaluate the node based on the possible income (the numbers and terrain type). > … it seems that it checks the score of the three surrounding hexes, > and in order to value each of them, inside score_hex (lines 397-400 in > score_hex) Here it tries to get a 3:1 port, when it does not have a 3:1 port yet. The value ANY_RESOURCE can only happen on a sea tile with a 3:1 port. > … it only checks whether hex->resource is ANY_RESOURCE or not, but I > don´t see the facing logic anywhere. And I can have a node surrounded > by a SEA_TERRAIN with ANY_RESOURCE, without having access to that > port, and I don´t see where inside score_hex or score_node checks for > that not to happen. It seems to me that facing is irrelevant here in > order to value the score of a node. Hmm, you might have found a bug. The greedy player should use the facing value to be able to determine that is it building at a port and not some random tile near the coast. > I know I must be missing something, but I still don´t see it. Right > now I´m using the same conditional in my code to give a special value > to nodes with access to generic ports, but I don´t know if I am also > giving that special value to nodes that, actually, belong to a hex > adjacent to a sea hex with port but in fact don´t have access to that > port. See also editor.c, lines 150-162. facing=0 means 'east', nodes 0 and 5. So the nodes facing and facing-1 are active for a port. > I´ve looked also inside greedy.c to see how it values specific ports, > but it seems that it doesn´t take them specially into account. Could I > use an equivalent logic of that inside score_hex to check if a node > gives access to a specific port? Sure you can. It is just that the greedy player does not use it. > For example, for a Lumber port: > if (hex->terrain == SEA_TERRAIN)&&(hex->resource==LUMBER_RESOURCE){ > /*do something*/ Indeed, the code above is for detecting a lumber port, you only need to use the facing value to see which nodes have this port. > Help! All those port logic is what is left to have my player finished > and ready to evolve! Please commit early. I can help better when I see your code evolve... With kind regards, Roland Clobus |
From: Rodrigo E. G. <rod...@ho...> - 2014-03-02 17:47:30
|
Sorry, but I have checked the code in editor.c and I still don´t get it. I understand that facing indicates the direction where there is a “normal” hex adjacent to a SEA_TERRAIN one, and that in that direction is where the port is (in case the sea hex has one). But what does it happen with (lines 748-758 in editor.c)… for (i = 0; i < 6; i++) { const Hex *adjacent; adjacent = hex_in_direction(current_hex, i); if (adjacent != NULL && adjacent->terrain != LAST_TERRAIN && adjacent->terrain != SEA_TERRAIN) { current_hex->facing = i; break; } } …when the sea hex is adjacent to more than one hex? Or is it not possible? Because the first valid adjacent hex sets facing and exits the loop, and since hexes are checked counterclockwise it could set facing to face the wrong hex if that is possible. But I don´t understand how facing should be used anyway, cause inside greedy.c there is no mention to it, so I don´t know if I need it. In my code, in order to check whether a node has access to a generic port, inside genetic.c I´ve tried to mimic the way it is used inside score_node, but when I look at (lines 445-447 in greedy.c, in score_node)… for (i = 0; i < 3; i++) { score += score_hex(node->hexes[i], resval); } … it seems that it checks the score of the three surrounding hexes, and in order to value each of them, inside score_hex (lines 397-400 in score_hex) … if (!resval->info.any_resource) { if (hex->resource == ANY_RESOURCE) score += 0.5; } … it only checks whether hex->resource is ANY_RESOURCE or not, but I don´t see the facing logic anywhere. And I can have a node surrounded by a SEA_TERRAIN with ANY_RESOURCE, without having access to that port, and I don´t see where inside score_hex or score_node checks for that not to happen. It seems to me that facing is irrelevant here in order to value the score of a node. I know I must be missing something, but I still don´t see it. Right now I´m using the same conditional in my code to give a special value to nodes with access to generic ports, but I don´t know if I am also giving that special value to nodes that, actually, belong to a hex adjacent to a sea hex with port but in fact don´t have access to that port. I´ve looked also inside greedy.c to see how it values specific ports, but it seems that it doesn´t take them specially into account. Could I use an equivalent logic of that inside score_hex to check if a node gives access to a specific port? For example, for a Lumber port: if (hex->terrain == SEA_TERRAIN)&&(hex->resource==LUMBER_RESOURCE){ /*do something*/ Help! All those port logic is what is left to have my player finished and ready to evolve! Thank you!!! |
From: Andreas S. <a.s...@gm...> - 2014-02-25 15:12:11
|
Hi Roland, On Tue, Feb 25, 2014 at 12:05 PM, Roland Clobus < rc...@us...> wrote: > I know there is a GTK2 (native) port of Pioneers at [1]. > That is indeed interessting. I built myself a kind of Wrapper for Pioneers on MacOSX using homebrew. Let's see if [1] is a more intelligent approach or not. Thank you. Best, Andreas |
From: Roland C. <rc...@us...> - 2014-02-25 11:30:21
|
On di, 2014-02-25 at 09:26 +0100, Rodrigo Espiga Gómez wrote: > I need to know if a node gives me access to a port. As far as I can > tell by the way it is used inside score_hex (in greedy.c), if > hex.resource==ANY_RESOURCE that means that the hex has a generic > port, and if a node is adjacent to that Hex then it has access to that > port. So that means that the hex is a maritime one, isn’t it? And if > resource is a different one, does that mean that the hex has a > specific port? Take a look at the code in the editor. editor/gtk/editor.c lines 746-766 contains the logic to determine in which direction the port is pointing. So in the Hex structure, the terrain must be at sea, only then the resource indicates the type of the port. The value of facing shows which nodes it is pointing at. See also the diagram in common/map.c for an explanation of the coordinate system. > What confuses me a bit is that, although ports in the game are > conceptually associated with edges (or pairs of nodes), in the code > that information is contained within the Hex structure. And sometimes > two hexes are adjacent to the same maritime one, and some of their > nodes have access to the port and others don’t! In the board game, I've always associated the ports with the sea hex it is located on, and with the two nodes that actually can trade using this port. So I am not confused by having this information in the Hex structure :-) > So where do I have to look at to find out if a node gives me access to ports (generic and specific)? Answered above. With kind regards, Roland Clobus |
From: Roland C. <rc...@us...> - 2014-02-25 11:05:48
|
Hello Andreas, On Fri, 2014-02-21 at 22:10 +0100, Andreas Steinel wrote: > is there someone working on a GTK3 Mac App Bundle of Pioneers? I don't know if someone is currently working on the Mac version of Pioneers, so go ahead :-) I know there is a GTK2 (native) port of Pioneers at [1]. With kind regards, Roland Clobus [1] https://github.com/jquick/pioneers_app |
From: Rodrigo E. G. <rod...@ho...> - 2014-02-25 08:26:31
|
I need to know if a node gives me access to a port. As far as I can tell by the way it is used inside score_hex (in greedy.c), if hex.resource==ANY_RESOURCE that means that the hex has a generic port, and if a node is adjacent to that Hex then it has access to that port. So that means that the hex is a maritime one, isn’t it? And if resource is a different one, does that mean that the hex has a specific port? What confuses me a bit is that, although ports in the game are conceptually associated with edges (or pairs of nodes), in the code that information is contained within the Hex structure. And sometimes two hexes are adjacent to the same maritime one, and some of their nodes have access to the port and others don’t! So where do I have to look at to find out if a node gives me access to ports (generic and specific)? Thanks! |
From: Andreas S. <a.s...@gm...> - 2014-02-21 21:10:21
|
Hi all, is there someone working on a GTK3 Mac App Bundle of Pioneers? Best, Andreas |
From: Roland C. <rc...@us...> - 2014-02-21 07:24:38
|
Hello Randall, On Mon, 2014-02-17 at 12:38 +0200, Randall Mason wrote: > I just wanted to let you know that I had to do a couple of things to > get it to build. I first tried to run the dpkg-buildpackage command > as I'm on ubuntu. This wanted me to install a whole list of things. > I installed everything except: libgnome2-dev libgtk2.0-dev. Indeed, in the GTK3 patch I did not update the Debian/Ubuntu source dependencies yet. > I then tried to run it with forced deps, but that still didn't work. > So I ran the autogen.sh command and a make. This too failed because > of a few things not being in GTK3 that were in GTK2. I looked for the > error online and found that many people solved this by removing > "-DG_DISABLE_DEPRECATED". I went in and took it out of the makefile > for both glib and gtk: > -GLIB_DEPRECATION = -DG_DISABLE_DEPRECATED -DG_DISABLE_SINGLE_INCLUDES > +GLIB_DEPRECATION = -DG_DISABLE_SINGLE_INCLUDES > > and > > -GTK_DEPRECATION = -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED > -DGNOME_DISABLE_DEPRECATED -DGDK_DISABLE_SINGLE_INCLUDES > -DGTK_DISABLE_SINGLE_INCLUDES -DGSEAL_ENABLE > +GTK_DEPRECATION = -DGNOME_DISABLE_DEPRECATED > -DGDK_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES > -DGSEAL_ENABLE That's an intended feature... When I run 'autogen.sh', I'm enabling the maintainer mode, which contains many more checks than a regular build. You could run './autogen.sh --disable-deprecation-checks' or run the './configure' without arguments (after it has been created by autogen.sh). > The next make resulted in a build and I was able to run that on a > broadway backend with this command: > GDK_BACKEND=broadway UBUNTU_MENUPROXY= LIBOVERLAY_SCROLLBAR=0 > pioneers-server-gtk > and > GDK_BACKEND=broadway UBUNTU_MENUPROXY= LIBOVERLAY_SCROLLBAR=0 pioneers > > > resulting in a great little pio server and client in my browser! Great, I'll try it soon too. I'm running Debian, so I have not tried the broadway backend yet. > This is so exciting! I think there are still a few things to iron out > because it keeps saying that I'm disconnected from the broadwayd gtk3 > backend in my browser, but I'm guessing that it's my problem. We'll > see.. > > > Also, for those on Ubuntu, you will need to upgrade gtk3 from > ppa:malizor/gtk-broadway and install broadwayd to get the above > commands to work. With kind regards, Roland Clobus |
From: Roland C. <rc...@us...> - 2014-02-21 07:18:24
|
Hello Rodrigo, On Tue, 2014-02-18 at 21:58 +0100, Rodrigo Espiga Gómez wrote: > After comitting the code of genetic_core.c and genetic.c I have > realized that, although it compiled in my local version, if I download > it now from the repository it gives compiling errors because I erased > your '#ifndef INTEGRATE_GENETIC_ALGORITHM' from genetic_core.c after > removing the whole main function inside genetic_core.c. That file was > meant to be an auxiliary file with some of the functions that would > later be used by genetic.c, which is actually the file with the AI. In > fact, those funtions could be inside genetic.c itself instead, and > genetic_core.c be removed completely. > I was compiling the code in my computer with the Makefile of the R1885 > with no problem, but that Makefile was modified afterwards in R2044. > I prefer not to alter the contents of the Makefile of the repository, > so I will wait for you to do whatever changes you may consider > necessary, if you don't mind. > Thank you very much! In r2048 I've fixed the Makefile.am. This means that genetic_core.c will not be given to the C compiler, because you already #include it in genetic.c. With kind regards, Roland PS: I prefer that all mail regarding Pioneers is sent to the mailing list. |
From: Roland C. <rc...@us...> - 2014-02-17 07:39:26
|
Hello Rodgrigo, On Fri, 2014-02-14 at 10:57 +0100, Rodrigo Espiga Gómez wrote: > No, I do not call random_init() from anywhere in the code (in greedy.c > is not called either). It seems to me that the error has something to > do with the randomized chat messages, but that is something I have > copied/pasted from greedy.c, I have not changed anything. Hints? Could you show the code? (Commit early, commit often) Then I can take a look at the code. The variable 'rand' is not used in greedy.c, so I guess you changed something during your copy/paste. With kind regards, Roland |