On 23.06.2012 16:04, Michael T. Pope wrote: > On Sat, 23 Jun 2012 02:05:39 PM Michael Vehrs wrote: > >> I have committed a patch that adds initial goods price ranges to the >> game options. This causes the ServerPlayerTest to fail intermittently. >> However, I think this is due to wrong or simplified assumptions made by >> the test cases. >> > If you are referring to the "English price for silver should have recovered" > one, that has been intermittent for quite a while. Hopefully you have made it > more reliably broken:-). >
Unfortunately not. Sometimes it passes, sometimes it fails. If it's known to be buggy, I'll have a look at it. > Meanwhile I have temporarily broken testAmerica by regenerating that map with > a version of FreeCol that assigns a `contiguity' number to each tile, where > the number is unique to each connected landmass or body of water. The > necessary patch will go in tomorrow if it survives an overnight test run. > Yes, I noticed the contiguity attribute, but validation problems are neither serious, nor difficult to fix (usually). > The contiguity trick is intended to allow the map searching routines to > quickly return failure when asked for impossible paths (e.g. land-unit- > without-carrier trying to go to a different continent, or naval-unit trying to > go from the sea to a lake). It would be good if the former could return > `Fail-but-would-succeed-if-there-was-a-carrier', distinct from the latter > which should just fail utterly. > That would be an improvement, certainly. Of course, the ship should check whether there are any carriers that it could board able to traverse land tiles. Smallish ships have been known to be dragged or otherwise transported over short distances, after all. > Indeed I am trying to do a lot of things with the search routines. This is > all driven by trying to beat sense into the AI. Here are some more things > underway in various stages of completion: > > - Improve the return value: currently we get null for failure, and null for > `already there, so no path'. Returning a trivial PathNode in the latter case > is the obvious improvement. > > - We currently handle the case where a carrier is specified, but there is a > hard assumption that the passenger unit starts on board the carrier, and > disembarks somewhere. This can be generalized to include the opposite case, > where the passenger walks to the carrier and embarks, and further generalized > to both embarking and disembarking (but not disembarking and re-embarking, > that explodes the search space). > > - Disembarking and embarking are hard to really get right. We currently > assume it is best to maximize the use of the carrier, which is usually right. > However it is not for mounted units where there is a good road system. > Similarly, with the contiguity trick, we can tell if a path could be found > without needing a carrier, which might be preferred if they are busy. > And they generally should be busy. At least until the player starts building custom houses. > - Generalize the endpoints. Currently we have distinct routines for searching > for paths to Tiles and to Europe. Unified routines that find paths between > Locations are better. > Yes, and that will be even more important when we add other locations that can only be reached via the high seas, or similar means. > - `Rendezvous paths' --- currently the CashInTreasureTrainMission moves the > train to the nearest coastal colony, and then decides if it is worth going to > Europe. What is really needed is a way to find a joint path where a carrier > moves from its current location towards the train, the train moves towards the > carrier, they rendezvous somewhere, and then move to a cash-in location. > And I think the same should apply to units far from the next colony, e.g. survivors of a lost colony somewhere in the boondocks. > Once that lot works the tools will be in place to fix the problems I hit in > TransportMission. It will still lack common sense (paths that avoid danger > are the next major can of worms), but a few classes of stupid will be gone. > > Cheers, > Mike Pope In theory, it should be easy to add "danger", i.e. the proximity of enemy units, to the cost function, shouldn't it? 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. Another path finding issue is the notorious "great river problem", where two ships block each other's progress. 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
