PROJECT: To Do List for Patch v1.2

[Fromafar]

Originally posted by Martin Gühmann
I just tried this and I wasn't able to recreate this bug with the debug version.

Originally posted by Locutus
I was able to recreate the bug [...] with the latest playtest build BTW.

I can confirm both, and suspect that the crash is prevented by the Astar.cpp modification of 2004.02.26.

Martin: do you still have the (ctp2.)map file of the latest playtest release somewhere? When you have the correct map file, the generated logs\crash.txt should point to Astar::FindPath. I can't verify this, because I don't have the correct map file.

[Martin Gühmann]

Well I have the ctp2.map file, the time stamp is:

Timestamp is 40379ea1 (Sat Feb 21 19:08:33 2004)

So far with the current playtest version I was able to recreate the crash, but not with the debug version, even if I followed Locutus' instrcutions. The next step would be to recompile the ctp2.exe again, with the changes in from the debug version.

Unfortunatly the game didn't created a crash.txt in the ..\ctp2_code\ctp\logs\ directory. But here is the ctp2.map file.

-Martin

[Flinx]

I just rediscovered a very frustrating bug: when you reload from an autosave you loose all of your research – had 1 turn to complete a tech, started a war by mistake, reloaded the autosave, now have to wait another 19 turns – Argh!!!

[Flinx]

Actually the bug is a little more specific:
> one turn to go on 'tech1'
> end turn
> select 'tech2' at start of turn
> do stuff or not but BEFORE you end turn
> reload autosave
> you are back to researching 'tech1' from the beginning.

[Fromafar]

Originally posted by Martin Gühmann
Unfortunatly the game didn't created a crash.txt in the ..\ctp2_code\ctp\logs\ directory. But here is the ctp2.map file.

Thanks, and a positive confirmation that the crash is indeed in Astar::FindPath.

You may have to set EnableLogs to Yes in userprofile.txt to generate crash.txt with the final version (i.e. when _BFR_ has been defined).

[Martin Gühmann]

Originally posted by Fromafar
You may have to set EnableLogs to Yes in userprofile.txt to generate crash.txt with the final version (i.e. when _BFR_ has been defined).

Indeed it was set to No in the source code version of my userprofile.txt.

Well one bug less on our to do list.

-Martin

[Fromafar]

Originally posted by Locutus
Ok, I'll add the pathfinding issue then.

I am not convinced yet that there is that big a problem with the pathfinding.

Originally posted by Dale
Actually, the function returns: ASTAR_BLOCKED so it's viewing it as unpassable, but then the Astar function doesn't look for another path when returned ASTAR_BLOCKED it just closes that node.

What we need to do it specific a different return like: ASTAR_OCCUPIED and when that's returned to the Astar function, make it keep the node open but try other directions from there.

Changing this may help in the case of a path that goes through a temporarily occupied tile. In this case, you can just compute the path as if there was no block, and - hopefully - by the time you reach it, it will no longer be occupied. As long as everyone keeps moving, it does not matter that there are a lot of other people using the same road. It only becomes a problem when they stop moving .

If the block is stationary, the chokepoint will still be occupied by the time you reach it. In this case, you may have to fight, or move your own troops ("guarding the pass") out of the way temporarily. If you can't or won't, the block is unpassable, and you have to lay out a path around it. And this is exactly what the current algorithm does. You may see this at the user interface: when you select a 12-unit army, its path projection will carefully go around your own guarded cities. This may result in a suboptimal path (using too many movement points/turns), but it does get you to the goal eventually!

Having 12-unit AI armies just standing around could be a completely different problem. I have seen this in situations (e.g. around Babylon in the Alexander scenario) where there is no visible chokepoint (mountain pass, land bridge, etc.) at all. That is, if the goal would have been to attack me. My guess is that the goal and chokepoint is the city itself. Maybe an army got scheduled to help defend the city, and some more units joined along the way. Or new defenders got created in the city itself. But this is just poor scheduling, and has nothing to do with pathfinding.

[Martin Gühmann]

I understood it that the problem is that just one path is calculated and when the army moves and it encounters a blocked tile in its path it doesn't compute an alternative path. If the path is blocked by a city then the goal should become invalid or this city should become the new goal.

-Martin

[Flinx]

Longer movement commands take non-optimal routes. Two examples where pathfinding could be improved:

e.g. moving an archer around a bay, I want to automate the following path 996633 (6turns) but the game suggests 88666323 (8turns); interestingly/strangely the game will correctly get the archer to 99663 in 5 turns.

e.g. manually get a ship in deep ocean, try to give a long movement command through a narrow channel to the north-west and then east along coast to my city, but game suggests south to the nearest coast, east, north, and west along the coast to the channel taking 3 extra turns, then east to my city; selecting the channel gets the ship to correctly sail north-west

(the game has always done this for me by the way, but since we are talking about pathfinding I thought I would bring it up)

[Gilgamensch]

copy&paste out of the wrong thread:

One thing I would like to see fixed:

The build-list: You can only put objects in the queue or build-list, which you have researched or you have the prerequisists. IIRC in CTP, you were able to make one from scratch and keep it for the whole game.

Big MC's comment about the Governor reminded me of this little bit annoying problem.

[kaan]

How about the no gold for tech diplo bug?

I know i said i would look into it but i havent been able to compile anything since i installed .NET

Good luck bughunting

[Martin Gühmann]

Originally posted by kaan
I know i said i would look into it but i havent been able to compile anything since i installed .NET

Did you try everything that you can find in that compiling with .Net thread, Klaus?

Anyway are there any problems if you would in addition install VC++ 6.0?

-Martin

[kaan]

Originally posted by Martin Gühmann


Did you try everything that you can find in that compiling with .Net thread, Klaus?

Anyway are there any problems if you would in addition install VC++ 6.0?

-Martin

well its the VC++ 6 thats the problem, i installed VS7 also and it seems to have interfered somehow.
The problem is that im forced to have VS7 now because of work.
Maybe i should put a few hours into making the source compil e in cygwin

[Martin Gühmann]

I think it is more promissing to make the code compile in .NET, espeacilly if you consider that it was already compiled successfully on .NET. Maybe there were some problems, but we could also need some .NET coders.

To get it to compile on .NET can be difficuilt for instance create a new Console project and try to compile this:

[CODE]
#include

int main(){
ifstream fin;

return 0;
}

It just contains the declaration of fin but I had serious trouble to compile, finally I figuered out it was something in the project properties, afterwards I compared it with a valid .NET project that uses ifstream.

So I want to say that the project properties could be a reason why it doesn't compile. But actual that should be less likely as the project is converted to the .NET format.

-Martin

[J Bytheway]

Issue 31 was fixed by Martin recently.

I've been investigating 32 but can't see anything that could cause it to happen. The relevant code seems to be this from CauseAndEffectTab.cpp. Is there anywhere else that you can change the science rate?

	sint32 scienceTaxLevelSet = spinner->GetValueX();
	double currentScienceTax = 0.0;
	player->GetScienceTaxRate(currentScienceTax);
	if(scienceTaxLevelSet !=
		static_cast((currentScienceTax * 100.0) + 0.5))	{ 
		player->SetTaxes(
			static_cast(scienceTaxLevelSet) / 100.0);
		UpdateCities();
	}