minar@reed.bitnet (Nelson Minar,L08,x640,7776519) (08/16/90)
In article <7575@ucdavis.ucdavis.edu> hardaker@iris.UCDavis.EDU (Wes Hardaker) writes:
[I want xconq docs]
We're using the documentation from xconq 5.1. Its missing several things,
such as the new format of map files, and the conspicuous omission of telling
us that everyone moves simultaneously now (a very nice thing).
I'm about convinced that the xconq 5.3 distribution is bogus, ie not from
shebs@cs.utah.edu.
Does anyone know the history of xconq 5.3? What happened to xconq 5.2? Where
is Stanley Shebs now? Is he a student, and not at utah for the summer?pierson@encore.com (Dan L. Pierson) (08/16/90)
In article <15341@reed.UUCP> minar@reed.bitnet (Nelson Minar,L08,x640,7776519) writes:
Does anyone know the history of xconq 5.3? What happened to xconq 5.2? Where
is Stanley Shebs now? Is he a student, and not at utah for the summer?
Last I knew, Stan was working in Silicon Valley, I think for Apple.
--
dan
In real life: Dan Pierson, Encore Computer Corporation, Research
UUCP: {talcott,linus,necis,decvax}!encore!pierson
Internet: pierson@encore.comabc@Matrix.COM (Alan Clegg) (08/17/90)
In article <15341@reed.UUCP> minar@reed.bitnet (Nelson Minar) writes: >In article <7575@ucdavis.ucdavis.edu> hardaker@iris.UCDavis.EDU (Wes Hardaker) writes: >[I want xconq docs] > >We're using the documentation from xconq 5.1. Its missing several things, >such as the new format of map files, and the conspicuous omission of telling >us that everyone moves simultaneously now (a very nice thing). Yes, 5.3 has some nice features (all undocumented). >I'm about convinced that the xconq 5.3 distribution is bogus, ie not from >shebs@cs.utah.edu. This is true. As of my last conversation with Mr. Shebs, he has taken a job with Apple. He MAY be reached by shebs@apple.com, BUT, he told me that he is NO LONGER WORKING WITH XCONQ!! >Does anyone know the history of xconq 5.3? What happened to xconq 5.2? Where >is Stanley Shebs now? Is he a student, and not at utah for the summer? The history of xconq leaves off with Stan giving up responsibility of its upkeep to some (un-named) person(s) on the net. That person(s) created 5.3 and never documented any of it. I believe that it might be time for SOMEONE to take up the sources to Xconq and do 'moderation' of the sources so as not to get 18 bezillion versions running everywhere. I would like to do this job, but don't know where Stan is now, or how he would take to somebody 'adopting' his code. -abc -- Alan B. Clegg uucp: ...!mcnc!matrx!abc Matrix Corporation inet: abc@matrix.com Raleigh, NC "They were all wrong. The workstation model is obsolete." A. Tanenbaum
shebs@Apple.COM (Stan Shebs) (08/21/90)
(Geez, I go on my honeymoon for two weeks and come back to doubts about my existence!) Hi everybody, this is the authentic Stan Shebs, who is (mostly) responsible for xconq versions up to 5.1, which was released July 88. I don't know very much about 5.3, not even who did it (somebody at DEC?). It seems like there were a number of gratuitous changes (personally, I think changing file formats without providing a conversion program deserves bamboo slivers under the fingernails). 5.2 never happened - basically I got my PhD from Utah one week after 5.1 came out, went to work for Apple, and haven't spent much time on xconq since. I was working on a truly distributed xconq, and it sort of worked, but the bugs were very deep and very serious, and prompted me to work on an entirely new game architecture that's better suited for distributed games. Eventually I should be able to use it to build a new game that plays like xconq, although probably sharing very little code with the existing program. (Sorry, but it's not yet to a point where I can discuss it in any greater detail.) So, the situation is that I'm out of the picture, and somebody else needs to step in, take charge, and release a version of xconq (5.4 presumably) that fixes all the bugs and incorporates the improvements that have come along in the past two years. So far I've had lots of volunteers, but no one has yet followed through and actually produced a new release of xconq. :-( stan shebs Apple ATG System Software shebs@apple.com
minar@reed.bitnet (Nelson Minar,L08,x640,7776519) (08/22/90)
Good to hear you are alive, Stanley. I, too, am interested in making sure that xconq is properly moderated, and NOT by the person who 'released' xconq version 5.3. The simultaneous movement is good, but other things are messy. I do recommend that we use xconq 5.3 for a starting off point. I would offer to moderate xconq myself, but I am going to be a very busy college student this fall, and I know almost nothing about X programming (yet). I would be happy hacking on the sources, though. Here is a partial bug list for xconq 5.3, both small things and big things: mouse selection of the unit production was broken. Patched at reed. units being carreid by other units could still produce things (put an infantry in a bomber, and have it building bases while it is being carried). Patched at Reed, but patched wrong (it should be setable in the .per file) weird bug that prevents units with < 10% chance of hitting other units to succeed (preventing, for example, bombers from attacking each other even if they have a 9% chance to hit). Patched at Reed. units from teams numbered > 6 do not have the proper numbers attached to their icons. This is the result of a sloppy patch to allow more than 7 players, and should be easily fixed. the period programming currently limits you to only 14 unit types, presumably because of "limitations in the view mechanism" (maybe only a nybble for the unit type?) A preliminary look through the source code did not show any obvious built in limit. xconq 5.3 has no documentation, and no working maps. Working maps exist, but the xconq 5.1 documentation needs updating. xconq occasionally breaks its own map files, causing core dumps when trying to restore. Restoring multi-player games is nonintuitive. An odd bug that occasionally lets pieces move farther than they should be able to. The game is too damned slow. In an 8 person game, with one other human and 6 computer opponents, if I have 80 units and put them all on sentry, it can take the game more than a minute and a half to go through all of the units and say 'oh, its on sentry, do nothing with it.' This leads one to having frequent waits while the game decides to let you move a piece. I suspect that it is the result of nonclever integration of multiple players moving at the same time, either on the X side or the machine side. Or else someone is losing a pointer somewhere, and taking a long time to recover :) Most of these bugs are fairly simple to fix, really.. There are also some 'features' I would not mind seeing: give transports (cities, bombers, troop transports) the ability to be protected by what is inside them. It is awfully unrealistic to read "You have captured the Italian city Obnazgul, (killing 8 i)." Those 8 infantry should be able to defend their city (while the same 8 infantry might not be able to defend the transport they are aboard). stacking pieces in a hex. There is no obvious reason why a fighter cannot be in the same hex as an infantry, other than the programmign headaches it causes. There are multiple schemes for handling this sort of thing. preemptive choices of moving pieces. Now that we have simulatenous movement, I should be able to say "I want to move these pieces at the beginning of the next turn." an interface for finding pieces (maybe). Seeing that your 280th infantry is being pummeled is nice. Where IS that 280th infantry? This might be a bad idea. better order programming for troops. Maybe a bank of little buttons to hit in addition to the key commands (do you remember if its little e or big E to wait for a transport?) It would also be nice to give troops little programs, rather than one order. This might be too big of a feature. Anyway, these are some of my ideas for xconq 5.4 (6.0?) I'd be willing to try to make some of them happen, but I really can't moderate the changes.
shebs@Apple.COM (Stan Shebs) (08/23/90)
In lieu of actually doing anything, I thought I'd get some of my reactions on the record here... In article <15356@reed.UUCP> minar@reed.bitnet (Nelson Minar) writes: >weird bug that prevents units with < 10% chance of hitting other units to > succeed (preventing, for example, bombers from attacking each other even if > they have a 9% chance to hit). Patched at Reed. This wasn't a bug. There were two reasons to include this limitation: first, it helps prevent some stupid behavior by the machine player code (OK, OK, there are plenty of other stupid behaviors :-) ), and secondly, even unsuccessful attacks consume moves, so attackers could chew up the defender's movement allowance with very little risk. The 10% rule was easy to do, there are probably better solutions. >units from teams numbered > 6 do not have the proper numbers attached to their > icons. This is the result of a sloppy patch to allow more than 7 players, > and should be easily fixed. The limitation to 7 players wasn't entirely arbitrary - the icon design doesn't really leave any room for two-digit side numbers, and even the numbers 8 and 9 are very confusing in a 3x5 font displayed as red-on-green (a real design boner - consider which form of color blindness is most common!) >the period programming currently limits you to only 14 unit types, presumably > because of "limitations in the view mechanism" (maybe only a nybble for the > unit type?) A preliminary look through the source code did not show any > obvious built in limit. I changed it to be larger once and lots of stuff broke, so I documented the bug to avoid having to fix it. 1/2 :-) >Restoring multi-player games is nonintuitive. Amen to that - I'm *still* trying to think of a good way to do it! Note that the netwide empire-type games don't allow save/restore at all... >give transports (cities, bombers, troop transports) the ability to be protected > by what is inside them. It is awfully unrealistic to read "You have captured > the Italian city Obnazgul, (killing 8 i)." Those 8 infantry should be able > to defend their city (while the same 8 infantry might not be able to defend > the transport they are aboard). That's what the "protect" parameter in the period description is for - but it may not be set correctly in your version of the standard period. Actually, the parameter is a little hard to set correctly anyway, since it doesn't always figure into the hit/capture probabilities in a plausible way. My conclusion is that it would have been better to hardcode more reasonable behavior for the standard period, and not to try to parametrize the whole program... >stacking pieces in a hex. There is no obvious reason why a fighter cannot be > in the same hex as an infantry, other than the programmign headaches it > causes. There are multiple schemes for handling this sort of thing. For "headache" substitute "migraine". There are substantial hassles with display, input, and period specification. The designs I've seen in other (computer and non-computer) games have been clunky and unpleasant. I'd sure like to see some good ideas! >an interface for finding pieces (maybe). Seeing that your 280th infantry is > being pummeled is nice. Where IS that 280th infantry? This might be a bad > idea. No, this is something that ought to be done. A "fast X display" solution is to flick the screen over, a cheap solution is to add something like "30 hexes NW of your current view" in the message. >better order programming for troops. Maybe a bank of little buttons to hit in > addition to the key commands (do you remember if its little e or big E to > wait for a transport?) It would also be nice to give troops little programs, > rather than one order. This might be too big of a feature. My half-working Sunview version has buttons, they seem to be OK. Little programs for units is getting complicated. An alternative I've wanted for awhile is for players to be able to specify a whole command hierarchy, so you would only to have give the detailed orders to a group commander, and then it would actually do the turn-by-turn movement of units, bugging you when there is a special problem. This could also be used to speed up the game via "command points" that are too scarce to be wasted on the details of flying fighters about, so you leave that to the group commanders. I've been doing a little experimenting, but no conclusions yet. stan shebs shebs@apple.com
jaa@cluster.cs.su.oz (James Ashton) (08/23/90)
In article <15356@reed.UUCP> minar@reed.bitnet (Nelson Minar) writes: >Good to hear you are alive, Stanley. > >I, too, am interested in making sure that xconq is properly moderated, and NOT >by the person who 'released' xconq version 5.3. The simultaneous movement is >good, but other things are messy. I do recommend that we use xconq 5.3 for a >starting off point. I would offer to moderate xconq myself, but I am going to >be a very busy college student this fall, and I know almost nothing about X >programming (yet). I would be happy hacking on the sources, though. I'm not sure we need hacking by someone unfamiliar with X and who is likely to be busy and later to move on anyway. [... bug and wish list deleted ...] I'm about to list some further bugs we've found but with regard to the wish list, surely we sould remove the bugs from the existing version before we try to add new features with their own bugs. You'll notice that many of the 5.3 bugs are due to the new features added since 5.1 When we've an apparently bug free version for people to use, then we can start on souped up versions. Sometimes when a unit enters a base with low supplies it seems to be forgotten. We've had this happen to bombers, transports. Survey mode shows the unit to exist but it never gets any moves. Units in bases still manage to achieve negative supplies. Restorations still cause core dumps often. In multiplayer games there are problems when most of the players have finished and are in survey mode. The game never seems to get to asking the still moving players to move their final few units. It looks like it's hung up on one of the survey mode players and wakes up when they use a mouse click to examine a unit. Things are definitely much too slow anyway, we find commonly more for some players than others. You can spend most of your time in move mode waiting for the machine to think of a unit for you to move. James Ashton.
minar@reed.bitnet (Nelson Minar,L08,x640,7776519) (08/23/90)
In article <1158@cluster.cs.su.oz> jaa@cluster.cs.su.oz (James Ashton) writes: >I'm not sure we need hacking by someone unfamiliar with X and who is >likely to be busy and later to move on anyway. I concur (speaking as the person who is unfamiliar with X) >You'll notice that many of the 5.3 bugs are due to the new features >added since 5.1 When we've an apparently bug free version for people >to use, then we can start on souped up versions. Good point. Get it working first. I might add at this point that whoever did 5.3 was fairly sloppy with it, and we should really avoid mistakes like that. >Sometimes when a unit enters a base with low supplies it seems to be >forgotten. We've had this happen to bombers, transports. Survey mode >shows the unit to exist but it never gets any moves. Units in bases >still manage to achieve negative supplies. I think this is one of the 'features' of xconq, rather. What happens is that your fully-fueled transport will move into a base, and the base will say 'oh, I don't have any fuel - lets take it from the transport' and so your transport loses (out of fuel). Its not funny when you trap your battleship in a base this way, and the only way to get it out is to move infantry into the base, have them give over their fuel, and disband them. (bringing up the issue of supply lines, an interesting .per capability). Anyway, this is (I am told) actually setable in the .per file. If one sets it the other way (and I regret I do not know offhand what the 'other' way is), moving objects tend not to get fueled automatically (you have to do it by hand), but they never get trapped at least. >Restorations still cause core dumps often. Same here. >In multiplayer games there are problems when most of the players have >finished and are in survey mode. The game never seems to get to asking >the still moving players to move their final few units. It looks like >it's hung up on one of the survey mode players and wakes up when they >use a mouse click to examine a unit. I hadn't noticed the last bit, about other players survey modes locking things up. I think its actually the same problem as you relate below: >Things are definitely much too slow anyway, we find commonly more for >some players than others. You can spend most of your time in move mode >waiting for the machine to think of a unit for you to move. I suspect some non-clever code concerning finding the next piece to move.
chris@momenta (Chris Christensen) (08/24/90)
This is all well and good, but the real important question is: does the latest version of xconq include the insect scenrio I sent you last year? ;-) (and, now that you are at apple, where is the mac version?) Chris Christensen
shebs@Apple.COM (Stan Shebs) (08/25/90)
In article <1990Aug23.234220.17814@momenta> chris@momenta (Chris Christensen) writes: >This is all well and good, but the real important question is: >does the latest version of xconq include the insect scenrio I sent you >last year? That was a pretty amusing scenario, I played it a few times! Not in the "latest release" (5.1 or 5.3, take your pick), but a must-have for any future releases... >(and, now that you are at apple, where is the mac version?) Have worked on it off and on, but Mac design and philosophy is very different, so have been spending more time on other things... stan shebs shebs@apple.com
mday@iconsys (Matt Day) (08/26/90)
In article <9923@goofy.Apple.COM> shebs@Apple.COM (Stan Shebs) writes: >In article <1990Aug23.234220.17814@momenta> chris@momenta (Chris Christensen) writes: >>(and, now that you are at apple, where is the mac version?) > >Have worked on it off and on, but Mac design and philosophy is very >different, so have been spending more time on other things... Strategic Conquest is a pretty good imitation, I would say.. -- /* Matthew T. Day, Sanyo/ICON, mday@iconsys.icon.com || uunet!iconsys!mday */
warkent@ltisun5.epfl.ch (Ken Warkentyne) (08/28/90)
> Restorations still cause core dumps often.
Did you fix the standing orders allocation bug? The array was allocated
but not initialized so that all the pointers in it were not nil.