wex@banzai-inst.SW.MCC.COM (Alan Wexelblat) (07/13/88)
I was glad to see the new version of xconq; however, I am disappointed by a number of core-dump-producing bugs I have seen so far. In particular, several of the periods do not work at all, simply core dumping without ever starting up (beirut & conquist in particular). It is also possible to produce a core dump by saving a game and restarting it with a different list of displays than the original, eg: foo % xconq -e 6 -v & <xconq comes up, is played for a while and then is saved> foo % xconq bar:0 -e 6 -v & Xconq tries to reread the save file and promptly core dumps. I also get core dumps if I'm playing with another human and the other human starts to read the help screens when it's not his turn. If the help screens (which are very nice, by the way) are still up when it becomes his turn, xconq gets an IOT, tries a panic save, and core dumps. I'm also disappointed at the stupidity of the robots. They don't have any aggressiveness; for example, if I have a unit sitting next to one of their cities which contains units they don't even attack my unit. In the starwars period they don't do *anything*. It also seems odd that one infantry unit (standard period) can destroy two infantries and capture two armors just because they happened to be sitting in a town. It ought to be harder to defeat units in a town, right? And you ought not to be able to capture a town while there are functional enemies inside it. Ah, well, perhaps in version 6.
shebs%defun.utah.edu.uucp@utah-cs.UUCP (Stanley T. Shebs) (07/13/88)
In article <896@banzai-inst.SW.MCC.COM> wex@banzai-inst.SW.MCC.COM (Alan Wexelblat) writes: >I was glad to see the new version of xconq; however, I am disappointed by a >number of core-dump-producing bugs I have seen so far. In particular, >several of the periods do not work at all, simply core dumping without ever >starting up (beirut & conquist in particular). There will be a set of patches soon, although coredumps in beirut are news to me. What system are you using? >It is also possible to produce a core dump by saving a game and restarting >it with a different list of displays than the original, eg: [...] The save/restore problem I just noticed myself for the first time today, so that's something else to work on. >I also get core dumps if I'm playing with another human and the other human >starts to read the help screens when it's not his turn. If the help screens >(which are very nice, by the way) are still up when it becomes his turn, >xconq gets an IOT, tries a panic save, and core dumps. This is also one I haven't heard of before, but then nobody at Utah ever seems to read the help screens. :-( >I'm also disappointed at the stupidity of the robots. They don't have any >aggressiveness; for example, if I have a unit sitting next to one of their >cities which contains units they don't even attack my unit. In the starwars >period they don't do *anything*. Smart machines are incredibly difficult to write, and I think some weightings got bolixed in the last round of experiments. Even so, attacking someone you're next to is not always a good idea. In the current release, the machine player forms units into groups, each with a specific goal. They seem to be a little too single-minded about the goal right now, that should probably be weakened. If anyone has implementable suggestions that work for all periods, I'd love to hear about them... To start to understand the workings of the machine players, use -D with two machine players against each other, and run the output into a file. Be sure you have plenty of disk space available! >It also seems odd that one infantry unit (standard period) can destroy two >infantries and capture two armors just because they happened to be sitting >in a town. It ought to be harder to defeat units in a town, right? And you >ought not to be able to capture a town while there are functional enemies >inside it. There is a parameter called "protect" that you can use to make infantry protect a town. In the standard period, its only use is to reduce the chance that hits on a city affect the occupants, but adding a line like 10% cities [ i a ] protect will do what you want. I didn't put it in because I figured armies in town were too busy partying to be of any use in defense. :-) If you don't like the settings in the standard period, they're very easy to change - that's why I spent so much time on the period machinery! Keep in mind that a lot of the parameters in the standard period were honed after many hours of playing, and that protection of occupants was hotly debated for some time; but then I wouldn't expect everybody in the world to agree on the correct values. stan shebs shebs@cs.utah.edu
cnc@hpcilzb.HP.COM (Chris Christensen) (07/13/88)
>>I was glad to see the new version of xconq; however, I am disappointed by a >>number of core-dump-producing bugs I have seen so far. In particular, >>several of the periods do not work at all, simply core dumping without ever >>starting up (beirut & conquist in particular). >There will be a set of patches soon, although coredumps in beirut are news >to me. What system are you using? This is the bug I posted about earlier that is caused by the buildings revolting. There was a bug in this code that I sent to Stan. Put: true B neutral in the beirut.per file and it will avoid the buga and run better anyway. >>I also get core dumps if I'm playing with another human and the other human >>starts to read the help screens when it's not his turn. If the help screens >>(which are very nice, by the way) are still up when it becomes his turn, >>xconq gets an IOT, tries a panic save, and core dumps. > >This is also one I haven't heard of before, but then nobody at Utah ever >seems to read the help screens. :-( > We have seen that one also. We also have a problem with xconq hanging when two players are playing. Chris
wex@banzai-inst.SW.MCC.COM (Alan Wexelblat) (07/14/88)
In article <5598@utah-cs.UUCP>, shebs%defun.utah.edu.uucp@utah-cs.UUCP (Stanley T. Shebs) writes: > There will be a set of patches soon, although coredumps in beirut are news > to me. What system are you using? Excellent! I will apply the patches as soon as I see them. I am using a Sun 3/160. The source code was compiled with the C compiler supplied with Sun OS 3.5. I am running the xconq program on a local version of the X10R4 server (we have several improvements/speedups over the standard Sun X10 server). > [...], but then nobody at Utah ever seems to read the help screens. :-( I find them to be very useful. I just wish there was some access method other than sequential... > Smart machines are incredibly difficult to write, and I think some weightings > got bolixed in the last round of experiments. What weightings should I play with to change the robots' behavior? Are there some that are easier to understand/manipulate than others? EG: in the standard period, the robots place a very high value on building airbases. They apparently place more value on this than on capturing neutral towns/cities! > If anyone has implementable suggestions that work for all periods, I'd > love to hear about them... In every game in every period that I've ever played, blitzkrieg seems to be the optimal strategy for loose units. There are also some good heuristics that I've found helpful: - Always leave at least one unit sleeping next to a city to recapture it if it's taken by the enemy. - If a city is producing something that takes a long time to build (like a battleship or a deathstar) leave a ring of units around the city so that it's hard for the enemy to get in and disrupt production. - Try to capture cities on as many land masses as possible. - Coastal cities are better than inland ones. I don't know how easy it would be to code these heuristics into your system, but that's the way I tend to play xconq. > If you don't like the settings in the standard period, they're very easy > to change... I confess I haven't read that part of the documentation yet (been too busy playing :-). But there are some errors in the settings that you may want to change for future releases: - in the Napoleonic period, cavalry can't go onto the plains - " " " " , the bitmap "artillery" is missing - " " " " , artillery has a movement of 4 (!!) - " " " " , artillery can't be unloaded from a troopship - in the future period, transport subs can't carry anything - " " starwars " , walkers can't go onto the ice - " " " " , x-wings can't land on cruisers, even though y-wings and tie fighters can There are also some things I consider odd. EG: in the standard period, a tank on the plains can't attack an infantry in the mountains. However, if the tank is in a town, it can. In the napoleonic period, artillery can't attack a frigate from a town; however, if it's on the plains it can attack. I hope this helps you; the new xconq is really a lot of fun!!
wex@banzai-inst.SW.MCC.COM (Alan Wexelblat) (07/15/88)
In article <2270001@hpcilzb.HP.COM>, cnc@hpcilzb.HP.COM (Chris Christensen) writes: > ... the bug I posted about earlier that is caused by the buildings > revolting. This posting somehow never reached our site. I will put your fix into our beirut.per file. > We also have a problem with xconq hanging when two players are playing. We have figured out why this happens and I've reported it to Stan. The reason is that the player whose turn it is *not* causes the xconq window to be redrawn (eg by exposing another X window over it). This causes input to hang for the player who's trying to move. The solution is to have the non-moving player click the mouse in the xconq window; this frees up the screen of the moving player who can then continue his turn.