>What version of xconq should we have built? CVS (as of when)?
>One of the downloads?
Good call. I'm currently stuck on a WinXP machine, so the version I am
using now is the 8/08/2004 build.
> Good call. I'm currently stuck on a WinXP machine, so the version I am
> using now is the 8/08/2004 build.
Hmm. I don't see that version for Linux.
Jim Kingdon wrote:
>>Good call. I'm currently stuck on a WinXP machine, so the version I am
>>using now is the 8/08/2004 build.
>
>
> Hmm. I don't see that version for Linux.
Jim, if you have an RPM-based Linux system, I could produce a matching
set of RPM packages, Windows installer, and source tarball.
Eric
> Jim, if you have an RPM-based Linux system, I could produce a matching
> set of RPM packages, Windows installer, and source tarball.
I have Red Hat 8.
So yes, if you provided those things I could use either the RPM or the
sources.
Jim Kingdon wrote: >>Jim, if you have an RPM-based Linux system, I could produce a matching >>set of RPM packages, Windows installer, and source tarball. > So yes, if you provided those things I could use either the RPM or the > sources. Well, if you don't mind building from sources, I'll just provide the tarball, because the RPM packages take longer to create. I'll try to get them posted to my Web site sometime tomorrow afternoon. Would you prefer a build against the most recent snapshot from the sources.redhat.com CVS server (plus the scheduler modification rollback/delay command fix that I posted a few days ago), which has Hans' partially-completed attack/fire stuff? Or, would you prefer a build against my local source tree, which has scheduler buzzing reductions and efficiency improvements (with working delay command), a bugfixed and improved SDL interface, a fix to the cXP bug that Elijah reported recently, and improved UI responsiveness during AI turns, but which does not have Hans' partially-completed attack/fire stuff? Eric
> Well, if you don't mind building from sources, I'll just provide the > tarball That's better, actually. The sources are pretty sure to build and work here. Binaries are a matter of worrying about glibc versions and what-not. > Would you prefer a build against the most recent snapshot from the > sources.redhat.com CVS server . . . > Or, would you prefer a build against my local source tree, which has Use your judgment. Whichever one you think is more likely to make it through the whole game without crashing. None of the features you mention strikes me as particularly essential (one way or the other). My most recent game was with xconq from CVS with top ChangeLog entry of "2004-08-21 Hans Ronne <hronne@comhem.se>" and I indeed made it to the end of game. For whatever that is worth.
Jim Kingdon wrote: >>Well, if you don't mind building from sources, I'll just provide the >>tarball > That's better, actually. The sources are pretty sure to build and > work here. Binaries are a matter of worrying about glibc versions and > what-not. Well, a source RPM would have been provided with the RPM packages, so I don't know how much of a problem that would be. But, I'll do a tarball anyway. > Use your judgment. Whichever one you think is more likely to make it > through the whole game without crashing. None of the features you > mention strikes me as particularly essential (one way or the other). Well, actually the scheduler improvements would allow you to finish your turn naturally (i.e., without pressing 'Enter') when formations are in use. Otherwise, you would tend to get stuck near the end (delay and reserve are of no help in such case). But, if no one uses formations, then I guess it is no big deal. > My most recent game was with xconq from CVS with top ChangeLog entry > of "2004-08-21 Hans Ronne <hronne@comhem.se>" and I indeed made it to > the end of game. For whatever that is worth. Ah, quite recent. Must have been playtesting the attack/fire stuff.... Eric
There is apparently an Xconq bug (using the sources recommended by Jim, plus my delay command fix) when attempting to set up a net game with more than 2 players. Trying to network 3 instances of Xconq under either Windows or Linux results in a message about trying to assign 4 players to 3 sides (even though there is not a fourth player and the indepside is not an active participant), and then lots of screwiness follows, including one of the 3 players getting kicked out of the game. I personally don't feel like fixing this bug right now. Eric
Eric McDonald wrote: > There is apparently an Xconq bug (using the sources recommended by Jim, > plus my delay command fix) when attempting to set up a net game with > more than 2 players. Trying to network 3 instances of Xconq under either > Windows or Linux results in a message about trying to assign 4 players > to 3 sides (even though there is not a fourth player and the indepside > is not an active participant), and then lots of screwiness follows, > including one of the 3 players getting kicked out of the game. > > I personally don't feel like fixing this bug right now. This bug is now fixed, __just in case you guys have been waiting eagerly these past 4.5 months to play some 3-or-more-way Xconq. The fixed binaries can be found here: http://sourceforge.net/project/showfiles.php?group_id=124062&package_id=135573&release_id=297705 Eric
I'm up for some multiplayer XConq, if only on a fact-finding (read: bug-stomping) manner. Of course, I'm open to some serious fun, too, wherein I promise to annihilate all comers... --- Eric McDonald <mcdonald@phy.cmich.edu> wrote: > Eric McDonald wrote: > > There is apparently an Xconq bug (using the > sources recommended by Jim, > > plus my delay command fix) when attempting to set > up a net game with > > more than 2 players. Trying to network 3 instances > of Xconq under either > > Windows or Linux results in a message about trying > to assign 4 players > > to 3 sides (even though there is not a fourth > player and the indepside > > is not an active participant), and then lots of > screwiness follows, > > including one of the 3 players getting kicked out > of the game. > > > > I personally don't feel like fixing this bug right > now. > > This bug is now fixed, __just in case you guys have > been waiting eagerly > these past 4.5 months to play some 3-or-more-way > Xconq. > > The fixed binaries can be found here: > http://sourceforge.net/project/showfiles.php?group_id=124062&package_id=135573&release_id=297705 > > Eric > > __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com
Elijah Meeks wrote:
> I'm up for some multiplayer XConq, if only on a
> fact-finding (read: bug-stomping) manner. Of course,
> I'm open to some serious fun, too, wherein I promise
> to annihilate all comers...
I am willing to do battle with you and Tom sometime after 0200 GMT
Saturday (Friday evening in my timezone).
Eric
> Elijah Meeks wrote:
>> I'm up for some multiplayer XConq, if only on a
>> fact-finding (read: bug-stomping) manner. Of course,
>> I'm open to some serious fun, too, wherein I promise
>> to annihilate all comers...
>
> I am willing to do battle with you and Tom sometime after 0200 GMT
> Saturday (Friday evening in my timezone).
>
> Eric
I'd like to join in, but I had a couple of problems with the latest
build on Windows, all seeming to do with multiple units in a single
cell. I was playing time.g, and found that when I loaded a third
phalanx onto a trireme, the third phalanx occupied the whole of the
cell, effacing the trireme. When focus shifted to another piece, only
then did the proper disply appear - i.e., a small trireme with 3
phalanxes beneath it.
When I woke up all the contained phalanxes in a trireme with a W
command, one of the phalanxes on board never got the focus; I had to
switch to survey mode to manually give it orders.
Finally, I had a multitude of phalanxes on the shore, 4 to a cell, all
asleep. When I switched to survey mode and selected one in order to
wake it up, the program crashed.
Are these all related? - Robert.
On Jan 19, 2005, at 8:41 PM, Eric McDonald wrote:
On Thu, 20 Jan 2005, Robert Goulding wrote: > I'd like to join in, but I had a couple of problems with the latest > build on Windows, all seeming to do with multiple units in a single > cell. I was playing time.g, and found that when I loaded a third > phalanx onto a trireme, the third phalanx occupied the whole of the > cell, effacing the trireme. Right. My fault for not communicating the unit display changes better. The idea is that if you are a fairly close map magnification, such as the default one (cells are 44x44 and units are generally 32x32), then about the smallest an unit image can be shrunken is to 16x16 before it becomes hard to identify. In a transport's 32x32 grouping box, 2 16x16 images may fit in the lower portion. If three units are placed in the transport, then the occupant sizes must be rescaled to 8x8, making them hard to see. So, as a counter to this, I made it so that one such occupant is the current unit, it fills up the transport's grouping box so that it stands out more. Similarly, occs did not show up at all in the isometric view. To counter this, I likewise made it so that the current unit, if an occ, would fill the same region that its transport would. I had thought this was an aid to game play to make it so. But, like I said, my fault for not more directly communicating such change and its rationale. Another change that I made was that if a transport is in a cell with other units, then the transport will still have a grouping box drawn around it, even if its occs cannot be displayed at the shrunken view. This is done so that there is still some indication that it has occs. Perhaps you noticed this as well. > When I woke up all the contained phalanxes in a trireme with a W > command, one of the phalanxes on board never got the focus; I had to > switch to survey mode to manually give it orders. This sounds odd. If you can attach a saved game demonstrating the bug, it would be quite helpful. > Finally, I had a multitude of phalanxes on the shore, 4 to a cell, all > asleep. When I switched to survey mode and selected one in order to > wake it up, the program crashed. That is not good. If you have a saved game that allows easy reproduction of the bug, it would helpful. Thanks, Eric