On 24.06.2012 03:47, Michael T. Pope wrote: > On Sat, 23 Jun 2012 06:04:02 PM Michael Vehrs wrote: > >> Unfortunately not. Sometimes it passes, sometimes it fails. If it's >> known to be buggy, I'll have a look at it. >> > IIRC what is happening is that the check that prices recover with time depends > on the regular goods removal removing enough goods. For the purposes of the > test we simulate this by calling the yearly-goods-removal routine N times, for > sufficiently large N. > > What has probably happened is that I rebalanced the amount of goods removed > too low, making this test marginal (again IIRC there is a random component to > the goods removal which will boost the variance). The failure will probably > go away if that was just nudged up a bit. However what really needs to be > done is to get some numbers on how fast the Col1 market recovered and try to > simulate that. I hope that explains why I left it failing for a while:-S. > > So by all means look at it:-). Or indeed at BR#3537373 that just arrived, as > the reporter is on Debian and has a crash deep in the option processing. >
At the moment, I can't get the test to fail anymore, which makes debugging rather difficult. With regard to BR#3537373, I can't really see how the option value gets to be null. Maybe the bug reporter can provide some more information. > >> In theory, it should be easy to add "danger", i.e. the proximity of >> enemy units, to the cost function, shouldn't it? >> > Yes. I did a brief experiment there a while back, and concluded that you > could really blow out the search time if you implemented this in a simple > minded manner but if you built up a cache map of<Tile, Danger> tuples as you > went it ought to work. I decided though not to push on there until the lower > level map search fixes were in, and until the AIs had some concept of how much > danger they were willing to tolerate in order to get a shorter path. > I image the danger value to be so important to the AI that it might be added to the PlayerExploredTile itself. > >> The path finding >> algorithm of the original game is also particularly stupid in this >> regard. It does not hesitate to move a fully loaded ship next to an >> enemy privateer, or a warship next to a fort or fortress. >> > Nice to know that the bar is low. > Very low. I think we are doing much better than the original game already. It often fails to find a short path to Europe and moves ships halfway across the map instead. > > >> Another path finding issue is the notorious "great river problem", where >> two ships block each other's progress. >> > There are lots of places in the AI where it just constantly tries to do `the > next thing', without any sort of backoff after failure. > > Cheers, > Mike Pope > True. Do you know any generic search libraries that might be helpful? A quick search turned up the following, which I have not evaluated, however: https://sourceforge.net/projects/jsl/ http://code.google.com/p/a-star-path-finding-library/ https://github.com/jayenashar/Java-Search-library Regards Michael ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Freecol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freecol-developers
