Greetings and Bug Reports

[chadhogg]

Greetings, Apolytoners. This site has come a long way since I first viewed it as a Civ II junkie. I am a graduate student working at Lehigh University on a project to integrate Call To Power II with the Testbed for Integrating and Evaluating Learning Techniques (TIELT). This project was previously headed by Apolyton member Ushhan Gundevia.

We had been building our own changes on a stale checkout of version 429 of your code until I recently discovered some bugs that caused me to decide we should merge whatever changes the Apolyton code has experienced into our codebase. I have therefore built an unchanged copy of revision 656 and done some additional testing.

I have started two games and each one when the game crashed to the desktop. I haven't been able to debug this yet, but I will attempt to do so and submit my changes if I am able to fix them (and get an svn account). Looking at the log files, both crashes appear to be in ArmyData::BeginTurn(), and both occur during enemy turns. If anyone is interested I can post the save files that will trigger the crash as soon as you end your turn.

In addition to these crashes, I noticed a few other things that I assume are minor bugs. First, I noticed that while the names of some units are in mixed case, some of them such as the longbowman show up as UNIT_LONGBOWMAN or something, looking like a macro name. Second, I disbanded a city by building a settler in a city with population of 1 and did not lose my empire borders. Third, attempting to disband a military unit had no effect.

Hopefully I will be able to get back to you in a day or so with solutions or at least explanations for these problems. Thanks for all the work the community has put into this!

[Martin Gühmann]

Originally posted by chadhogg
I have started two games and each one when the game crashed to the desktop. I haven't been able to debug this yet, but I will attempt to do so and submit my changes if I am able to fix them (and get an svn account). Looking at the log files, both crashes appear to be in ArmyData::BeginTurn(), and both occur during enemy turns. If anyone is interested I can post the save files that will trigger the crash as soon as you end your turn.

The ArmyData::BeginTurn() crash is caused by E's unit updater code, so far I think I should have fix it, unfortunately there is another crash that only occurs in the final version and not in the debug version. So far I haven't sorted it out. And until then I won't provide a new revision.

Originally posted by chadhogg
In addition to these crashes, I noticed a few other things that I assume are minor bugs. First, I noticed that while the names of some units are in mixed case, some of them such as the longbowman show up as UNIT_LONGBOWMAN or something, looking like a macro name.

That's because E added two new units to the game and forgot to update the string files. Anyway I don't know whether these two additional units cause any problems for existing save games, therefore I might remove them.

-Martin

[Ekmek]

Originally posted by Martin Gühmann


The ArmyData::BeginTurn() crash is caused by E's unit updater code, so far I think I should have fix it, unfortunately there is another crash that only occurs in the final version and not in the debug version. So far I haven't sorted it out. And until then I won't provide a new revision.

this crash I faced before which means there might be an error with the upgrade path. meaning that two units that one unit can upgrade to are available at the same time. So I have to recheck that. I haven't thought of a code work around for that yet, so if you've been looking at that Martin, thats the problem.

That's because E added two new units to the game and forgot to update the string files. Anyway I don't know whether these two additional units cause any problems for existing save games, therefore I might remove them.

-Martin

man, I thought those were included with Tamerlin's files. I'll get to that. The two unit issue I think is resolved if both units are at the end so I'll check that as well. hopefully today or tomorrow.

[chadhogg]

Ok, it sounds like you are already working on these problems, so it would not be a good use of my time to try to debug them, but that we cannot expect a fix to be released in the immediate future. In that case, I may just upgrade our source to your revision 654 for now. (Looking at the commit logs, it seems like the changes that caused these bugs were in revision 655.)

By the way, it might be nice to have a branch of the source code that only gets bugfixes and no new features. I haven't been able to find such a thing, so I presume it does not exist.

Thanks for the responses,
Chad

[Ekmek]

Originally posted by chadhogg
Ok, it sounds like you are already working on these problems, so it would not be a good use of my time to try to debug them, but that we cannot expect a fix to be released in the immediate future. In that case, I may just upgrade our source to your revision 654 for now. (Looking at the commit logs, it seems like the changes that caused these bugs were in revision 655.)

that was basically what I was going to do while I went through the changes. its actually a problem in the units.txt file and not in the code (well kind of).

By the way, it might be nice to have a branch of the source code that only gets bugfixes and no new features. I haven't been able to find such a thing, so I presume it does not exist.

Thanks for the responses,
Chad

yeah that would be a way to go but not sure how we can keep them in parrallel.

Most new features aren't supposed to be implemented except by modification. however we wanted the upgrade stuff because how it works now the human disbands a unit then builds a new one ut the AI doesn't iprove its armies. Upgrading, seen in other civ games, is a way to make it less tedious for the human instead of just disbanding and the code i had allowed the AI to do the same.

[Martin Gühmann]

Originally posted by E
that was basically what I was going to do while I went through the changes. its actually a problem in the units.txt file and not in the code (well kind of).

Not really, the problem was that killing the last unit in an army may invalidate its army, while you are still executing a method of that army. And that makes the game crash. Anyway the SetType method seems now to work, but we have still to address the MP upgrade issure.

-Martin

[Ekmek]

chadhogg,

could you post a savegame of the crash from 656? I looked at the upgrade chain and it looks ok but seeing where the crash is will help me find out which unit is doing it.


Martin,

I'll check out the settype stuff. do you think upgrading should only go in unit or stay in army based on the comments in the code.

[chadhogg]

It doesn't look like attaching files to the forum post is working as I would expect, so I put them up at http://sigaserver.dyndns.org:8765/~c...UTOSAVE-Chad03 and http://sigaserver.dyndns.org:8765/~c...TOSAVE-Chad04.

They are from two different games, but the circumstances of the crash appear to be the same.

By the way, I built the 654 revision and have been playing it a bit. I was able to get further into the game without a crash than I had in 656, but I am now experiencing them. In this case, however, I think the crashes are caused by my machine running out of memory. I am in the process of building a release version, in hopes that it will have a much smaller footprint than the debug version and solve the problem.

Hope this is helpful,
Chad

[Martin Gühmann]

Originally posted by E
I'll check out the settype stuff. do you think upgrading should only go in unit or stay in army based on the comments in the code.

E, better don't put any work into it, I have on my hard disk a version containing some modifications that should fix the problem, but of course some tests still need to be done.

So for now everyone who wants to test the other changes can use the unit.txt from revision 654 or earlier.

And chadhogg concerning attaching files: The forum accepts all files you just have to zip them, actually this is the proper way to deal with attachments, since we don't want to attach more bytes than necessary.

-Martin