* Standard game problems in windows (20031214) version @ 2003-12-16 14:28 Martin Fehlhaber 2003-12-16 16:42 ` Hans Ronne 2003-12-16 17:18 ` Eric McDonald 0 siblings, 2 replies; 11+ messages in thread From: Martin Fehlhaber @ 2003-12-16 14:28 UTC (permalink / raw) To: xconq7 Yesterday evening I played the standard game - by the way: which game would you suggest as being moderately more advanced? - and had trouble unloading my transports. I could only disembark directly into cities. I was able to build a transport in a city connected to the sea by a river (one hex), but was unable than to slip into the sea. The computer players did poorly, but I missed one transport of the last player. So he retained score 1. I handed over to the AI to let it finish, but couldn't bear to watch it crash my planes in hordes. Besides: Units keep sharing fuel without my consent. This is especially irritating with planes. After having entered a flight path, planes keep halting after having spent half of their fuel, despite the fact that there is a city waiting for them. Have I mentioned yet, that I would love to see patrols implemented? Still a fun game to play... Regards, Martin __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Standard game problems in windows (20031214) version 2003-12-16 14:28 Standard game problems in windows (20031214) version Martin Fehlhaber @ 2003-12-16 16:42 ` Hans Ronne 2003-12-16 17:18 ` Eric McDonald 1 sibling, 0 replies; 11+ messages in thread From: Hans Ronne @ 2003-12-16 16:42 UTC (permalink / raw) To: Martin Fehlhaber; +Cc: xconq7 >Yesterday evening I played the standard game - by the way: which game >would you >suggest as being moderately more advanced? - and had trouble unloading my >transports. I could only disembark directly into cities. I was able to build a >transport in a city connected to the sea by a river (one hex), but was unable >than to slip into the sea. > >The computer players did poorly, but I missed one transport of the last >player. >So he retained score 1. I handed over to the AI to let it finish, but couldn't >bear to watch it crash my planes in hordes. > >Besides: Units keep sharing fuel without my consent. This is especially >irritating with planes. > >After having entered a flight path, planes keep halting after having spent >half >of their fuel, despite the fact that there is a city waiting for them. > >Have I mentioned yet, that I would love to see patrols implemented? > >Still a fun game to play... Thanks. The problems with loading/unloading transports are probably related to the path-finding problems that Lincoln Peters and others have reported. Same goes for the resupply problem. As you may know, we incorporated Peter Garrone's new path-finding code recently. It is a major improvement, but there are still three problems with it that need to be fixed: 1. Desynch of network games. The path cahce has been disabled as a temporary fix, but this in turn slows down the AI a lot, something that people also have complained about. 2. Transport-related problems. 3. Resupply-related problems. Peter has been working on fixes for all three problems. I would rather wait a few week for these fixes than back out of the path-finding code since I think the latter adds a lot to the game. Meanwhile, please have patience with these bugs. There are also some other bugs that we are working on. Some games (such as flattops) now crash in the Windows and Mac tcltk interfaces. And there are some problems with running network games from saved files on Windows. These problems may be related to the recent changes in the game loading and network code. As for a more advanced game, I would recommend either Eric McDonald's Bellum or my own Advances game. Hans ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Standard game problems in windows (20031214) version 2003-12-16 14:28 Standard game problems in windows (20031214) version Martin Fehlhaber 2003-12-16 16:42 ` Hans Ronne @ 2003-12-16 17:18 ` Eric McDonald 2003-12-16 19:14 ` Bruno Boettcher 1 sibling, 1 reply; 11+ messages in thread From: Eric McDonald @ 2003-12-16 17:18 UTC (permalink / raw) To: Martin Fehlhaber; +Cc: xconq7 Hi Martin, others, On Tue, 16 Dec 2003, Martin Fehlhaber wrote: > The computer players did poorly, but I missed one transport of the last player. > So he retained score 1. I handed over to the AI to let it finish, but couldn't > bear to watch it crash my planes in hordes. The poor handling of aircraft is something that I think has appeared in the past 1.5 months. I am tempted to address it with a temporary fix, but I am currently waiting for Peter, since he is probably in a better position to produce a more proper fix. > After having entered a flight path, planes keep halting after >having spent half > of their fuel, despite the fact that there is a city waiting for them. This behavior was present in Xconq prior to the new path code. I agree that it is annoying. If you move any unit past its SupplyLow threshold, you will see this behavior. Again, I am going to wait for Peter to make his move first before trying to do anything about it. There is at least one complication here: Suppose that a unit's path becomes blocked or its destination is captured while it is en route. If we blindly follow the path, ignoring the SupplyLow indicators, then we risk losing or paralyzing the unit due to overconsumption of supplies. I suppose that one could recheck the path for blockage after each move, but this might be costly in terms of CPU (it would still be cheaper than recomputing the path after each move, I think). > Have I mentioned yet, that I would love to see patrols implemented? I think we all would. This is one of the things I intend to look into once we have 7.5 released. > Still a fun game to play... Thanks. I think so too. Regards, Eric ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Standard game problems in windows (20031214) version 2003-12-16 17:18 ` Eric McDonald @ 2003-12-16 19:14 ` Bruno Boettcher 2003-12-16 22:55 ` Eric McDonald 2003-12-17 10:42 ` Peter Garrone 0 siblings, 2 replies; 11+ messages in thread From: Bruno Boettcher @ 2003-12-16 19:14 UTC (permalink / raw) To: xconq7 On Tue, Dec 16, 2003 at 11:42:51AM -0500, Eric McDonald wrote: Hello! > This behavior was present in Xconq prior to the new path yep! i address it with standing orders :D > code. I agree that it is annoying. If you move any unit past its true! > SupplyLow threshold, you will see this behavior. Again, I am going > to wait for Peter to make his move first before trying to do > anything about it. that would be really nice! > There is at least one complication here: > Suppose that a unit's path becomes blocked or its destination > is captured while it is en route. If we blindly follow the path, > ignoring the SupplyLow indicators, then we risk losing or > paralyzing the unit due to overconsumption of supplies. I suppose > that one could recheck the path for blockage after each move, but > this might be costly in terms of CPU (it would still be cheaper > than recomputing the path after each move, I think). what about recomputing the path to the nearest resupply source when we hit the low supply case (and eventually compare it to the destination)? > > Have I mentioned yet, that I would love to see patrols implemented? > > I think we all would. This is one of the things I intend to look > into once we have 7.5 released. wheres the problem? they are allready implemented??? i use regularly patrols since years now??? ..... the solution are standing orders.... the only problem i have is that i seem unable to clear standing orders, i can only redirect them, since the 'none' task has a real bad behaviour on fighters :D > Thanks. I think so too. yup definitely :D -- ciao bboett ============================================================== bboett@adlp.org http://inforezo.u-strasbg.fr/~bboett =============================================================== ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Standard game problems in windows (20031214) version 2003-12-16 19:14 ` Bruno Boettcher @ 2003-12-16 22:55 ` Eric McDonald 2003-12-16 23:09 ` Bruno Boettcher 2003-12-17 15:37 ` Peter Garrone 2003-12-17 10:42 ` Peter Garrone 1 sibling, 2 replies; 11+ messages in thread From: Eric McDonald @ 2003-12-16 22:55 UTC (permalink / raw) To: bboett; +Cc: xconq7 Hi Bruno ("Mr. Standing Orders"), On Tue, 16 Dec 2003, Bruno Boettcher wrote: > > paralyzing the unit due to overconsumption of supplies. I suppose > > that one could recheck the path for blockage after each move, but > > this might be costly in terms of CPU (it would still be cheaper > > than recomputing the path after each move, I think). > what about recomputing the path to the nearest resupply source when we > hit the low supply case (and eventually compare it to the destination)? I don't think we should automatically move in any direction other than that specified by the user. Second-guessing the player is generally not a good idea. > wheres the problem? they are allready implemented??? > i use regularly patrols since years now??? ..... > the solution are standing orders.... If you feel like creating 3 or 4 for various coordinates, __in a graphical interface. Look, I am a keyboard's best friend, but there are times when a few clicks are better at getting the job done (except in the curses interface :-). This is how patrols are set up in Strategic Conquest and Empire Master, and I think it is more efficient to do things this way. Also, it just might give some better competition to people who use standing orders heavily.... :-) Regards, Eric ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Standard game problems in windows (20031214) version 2003-12-16 22:55 ` Eric McDonald @ 2003-12-16 23:09 ` Bruno Boettcher 2003-12-17 10:27 ` Jim Kingdon 2003-12-17 15:37 ` Peter Garrone 1 sibling, 1 reply; 11+ messages in thread From: Bruno Boettcher @ 2003-12-16 23:09 UTC (permalink / raw) To: xconq7 On Tue, Dec 16, 2003 at 02:22:55PM -0500, Eric McDonald wrote: > Hi Bruno ("Mr. Standing Orders"), :D > > what about recomputing the path to the nearest resupply source when we > > hit the low supply case (and eventually compare it to the destination)? > > I don't think we should automatically move in any direction other > than that specified by the user. Second-guessing the player is > generally not a good idea. true, but claiming low supply with resupply possibilies nearby isn't very optimal either... besides the engine knows where the unit should go, isn't it? if the path seems clear, there shouldn't be IMHO a questioning about low supply, that was all i was suggesting :D > If you feel like creating 3 or 4 for various coordinates, __in a > graphical interface. Look, I am a keyboard's best friend, but heh if you remember i am whining for years now for a better support of standing orders in the GUI's :D > there are times when a few clicks are better at getting the job > done (except in the curses interface :-). This is how patrols are > set up in Strategic Conquest and Empire Master, and I think it is > more efficient to do things this way. Also, it just might give i would allready be happy if clicking in a cell whilst editing a stnading order the cell-coordinates would be inserted into the command line... > some better competition to people who use standing orders > heavily.... :-) :D :D BTW i made just this lunchtime break a tutoring game with my friends here (means we played with all 3 visuals on one machine) and i showed them (finally ;) the standing order mechanism, and there appeared that as i thought, that mechanism moves the units way more efficently than you can do by hand, due to the order in which the units are presented! so indeed and as ever: standing order rules! :D -- ciao bboett ============================================================== bboett@adlp.org http://inforezo.u-strasbg.fr/~bboett =============================================================== ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Standard game problems in windows (20031214) version 2003-12-16 23:09 ` Bruno Boettcher @ 2003-12-17 10:27 ` Jim Kingdon 2003-12-17 10:28 ` Peter Garrone 0 siblings, 1 reply; 11+ messages in thread From: Jim Kingdon @ 2003-12-17 10:27 UTC (permalink / raw) To: xconq7 > true, but claiming low supply with resupply possibilies nearby isn't > very optimal either... besides the engine knows where the unit should > go, isn't it? if the path seems clear, there shouldn't be IMHO a > questioning about low supply, that was all i was suggesting :D In the case where the player has given a destination which would resupply the unit, this seems fair. Otherwise, seems like the player should need to explicitly hit the "r" (resupply) key if that is what they want. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Standard game problems in windows (20031214) version 2003-12-17 10:27 ` Jim Kingdon @ 2003-12-17 10:28 ` Peter Garrone 0 siblings, 0 replies; 11+ messages in thread From: Peter Garrone @ 2003-12-17 10:28 UTC (permalink / raw) To: xconq7 On Tue, Dec 16, 2003 at 06:09:46PM -0500, Jim Kingdon wrote: > > true, but claiming low supply with resupply possibilies nearby isn't > > very optimal either... besides the engine knows where the unit should > > go, isn't it? if the path seems clear, there shouldn't be IMHO a > > questioning about low supply, that was all i was suggesting :D > > In the case where the player has given a destination which would > resupply the unit, this seems fair. > > Otherwise, seems like the player should need to explicitly hit the "r" > (resupply) key if that is what they want. As I have indicated previously, I am thinking of implementing it so that aircraft will fly from A to B via a refuel point C automatically. Otherwise it all gets a bit too tedious. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Standard game problems in windows (20031214) version 2003-12-16 22:55 ` Eric McDonald 2003-12-16 23:09 ` Bruno Boettcher @ 2003-12-17 15:37 ` Peter Garrone 2003-12-17 16:54 ` Eric McDonald 1 sibling, 1 reply; 11+ messages in thread From: Peter Garrone @ 2003-12-17 15:37 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 On Tue, Dec 16, 2003 at 02:22:55PM -0500, Eric McDonald wrote: > Hi Bruno ("Mr. Standing Orders"), > > On Tue, 16 Dec 2003, Bruno Boettcher wrote: > > > > paralyzing the unit due to overconsumption of supplies. I suppose > > > that one could recheck the path for blockage after each move, but > > > this might be costly in terms of CPU (it would still be cheaper > > > than recomputing the path after each move, I think). > > what about recomputing the path to the nearest resupply source when we > > hit the low supply case (and eventually compare it to the destination)? > > I don't think we should automatically move in any direction other > than that specified by the user. Second-guessing the player is > generally not a good idea. I disagree. The path-finding implies that a move is possibly different. An aircraft, directed to go from A to B, might fly to C to get some fuel. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Standard game problems in windows (20031214) version 2003-12-17 15:37 ` Peter Garrone @ 2003-12-17 16:54 ` Eric McDonald 0 siblings, 0 replies; 11+ messages in thread From: Eric McDonald @ 2003-12-17 16:54 UTC (permalink / raw) To: Peter Garrone; +Cc: xconq7 Hi Peter, others, On Wed, 17 Dec 2003, Peter Garrone wrote: > > I don't think we should automatically move in any direction other > > than that specified by the user. Second-guessing the player is > > generally not a good idea. > > I disagree. The path-finding implies that a move is possibly different. > An aircraft, directed to go from A to B, might fly to C to get some > fuel. I don't entirely disagree when one is precomputing a path, though I still think that one must think about how tight do you want to keep the fuel budget when determining a path. If you say that a unit should refuel once it has traversed enough path to use 50% of its fuel, then you are quite possibly producing a very inefficient path, even if it is the only one that is essentially guaranteed to be safe. The case I was looking at was: what happens if we get a certain distance along a path and find that our primary refueling opportunity might have vanished? And my answer is the same as Jim's: the user needs to decide. Obviously if the refueling point is on the path and can be reached/utilized, then you let the automatic movement continue without user intervention; I certainly was not disputing that.... Regards, Eric ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Standard game problems in windows (20031214) version 2003-12-16 19:14 ` Bruno Boettcher 2003-12-16 22:55 ` Eric McDonald @ 2003-12-17 10:42 ` Peter Garrone 1 sibling, 0 replies; 11+ messages in thread From: Peter Garrone @ 2003-12-17 10:42 UTC (permalink / raw) To: xconq7 On Tue, Dec 16, 2003 at 06:18:55PM +0100, Bruno Boettcher wrote: > On Tue, Dec 16, 2003 at 11:42:51AM -0500, Eric McDonald wrote: > Hello! > > > This behavior was present in Xconq prior to the new path > yep! > i address it with standing orders :D > > > code. I agree that it is annoying. If you move any unit past its > true! > > > SupplyLow threshold, you will see this behavior. Again, I am going > > to wait for Peter to make his move first before trying to do > > anything about it. > that would be really nice! I better reply in some detail about how I intend to address this. The path-finding node state will include not only the geometric position but also the amount of material in each category. As the unit passes a refueling point, the supply will be repleneshed. Two nodes will have equivalent state if their material supply and geometric position are equivalent, also their transportation state. I am currently modifying path.c and task.c, but certainly cant yet compile the code, its still in a design phase really. I still havent quite worked out how to ensure the unit gets to point B with enough fuel to fly back to a resupply point. Possibly a pseudo target of getting to a resupply point after reaching the destination would work here, so that a destination is re-fuelable, for the AI anyway. The statenode, when it reaches its x,y target, gets a flag set, so that the final target is a refueling point, and the unit has enough fuel to return across whatever terrain is there. > > > There is at least one complication here: > > Suppose that a unit's path becomes blocked or its destination > > is captured while it is en route. If we blindly follow the path, > > ignoring the SupplyLow indicators, then we risk losing or > > paralyzing the unit due to overconsumption of supplies. I suppose > > that one could recheck the path for blockage after each move, but > > this might be costly in terms of CPU (it would still be cheaper > > than recomputing the path after each move, I think). > what about recomputing the path to the nearest resupply source when we > hit the low supply case (and eventually compare it to the destination)? The attention post 7.5 is to move the path-finding above the networking, so the cpu problem isnt so bad. It should also be possible to inspect the cached path to ensure that all nodes are outside zoc and also that all refueling points are available, and if waiting for a ferry if the ferry is not sunk. Also a path recalculation every N hexes or perhaps every move probably is reasonable, if a ferry isnt scheduled to pick the unit up. Unfortunately the AI seems to generate distant targets in some games. Peter ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2003-12-17 16:32 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-12-16 14:28 Standard game problems in windows (20031214) version Martin Fehlhaber 2003-12-16 16:42 ` Hans Ronne 2003-12-16 17:18 ` Eric McDonald 2003-12-16 19:14 ` Bruno Boettcher 2003-12-16 22:55 ` Eric McDonald 2003-12-16 23:09 ` Bruno Boettcher 2003-12-17 10:27 ` Jim Kingdon 2003-12-17 10:28 ` Peter Garrone 2003-12-17 15:37 ` Peter Garrone 2003-12-17 16:54 ` Eric McDonald 2003-12-17 10:42 ` Peter Garrone
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).