 |
|
Fromafar
|
|
quote: Originally posted by Martin Gühmann
I just tried this and I wasn't able to recreate this bug with the debug version. |
quote: 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.
|
|
|  |
 |
|
Fromafar
|
|
quote: 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).
|
|
|  |
 |
|
Fromafar
|
|
quote: 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.
quote: 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.
|
|
|  |
 |
|
Gilgamensch
|
|
France
Jun 2002 time: 06:34
|
|
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.
|
|
|  |
 |
|
J Bytheway
|
 |
England
Jul 2001 time: 05:34
|
|
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?
code: 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();
}
Last edited by J Bytheway on 04-04-2004 at 01:29
|
|
|  |
 |
|
Fromafar
|
|
#19: Trade route revalidation. You could interpret this as: not using the path as stored in the file, but recomputing it when loading. If so, fixing this would actually introduce a cheat to prevent the caravan loss that occurs when you reroute through the GUI.
The great library start change can be verified by starting a new game and opening the great library immediately. If you get Advanced Infantry Tactics on display, the change is missing.
|
|
|  |
 |
|
Peter Triggs
|
|
Gone Fishin, Canada
Jan 2000 time: 05:34
|
|
Re #19: And on top of that, whatever they did probably introduced an even worse bug. I remember people complaining to high heaven about how when you loaded a saved game you'd often find that your trade receipts had dramatically declined. Unless someone actually finds a bug with this, I think we should leave it alone.
|
|
|  |
 |
|  |
 |
|  |
All times are GMT. The time now is 05:34. Apolyton Time is 00:34. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|