PROJECT: Playtest (Thread No. 5)

[Martin Gühmann]

Originally posted by CajunArson
I've slung some code in my time, do you know where the main path-finding code is in the source tree? If I can get some free time I'd take a look at it and maybe there is a way to speed things up.

No, that isn't the problem, the problem is caused by the fact that the AI does not have enough sea transporters. You can use the cheat editor to verify this hypothesis by simply giving the Japaneses more transporters and then see what happens. If it is related to the missing transport capacity the slowdown should disappear.

-Martin

[CajunArson]

Martin Gühmann: Mein Deutsch is furchtbar, aber du kennst diese Problem 100%

Yeah, I added some sea transports to the offending civs and the game speed was massively faster and back to being perfectly fine. So for my next question... is there anything I can do to help in convincing the AI to either build more transports or to get around having the AI wait too long when no transport is available?

[Ekmek]

yuou want to start going into the code start here:

http://ctp2.darkdust.net/

once you get into it the code is somewhere in here:

https://ctp2.darkdust.net/svn/trunk/ctp2_code/ai/

[CajunArson]

Hey Guys,
Well I looked into the bug, and I have an initial patch which might help to reduce the problem with turns taking forever when no transport is available. I think I found the offending code in the AI's scheduler logic.

The file in question is: ctp2_code/ai/strategy/scheduler/scheduler.cpp
In the Scheduler::Match_Resources method, all of the 'plans' in place get iterated over, and for each 'plan' whose goal is to board a transport (GOAL_NEEDS_TRANSPORT) there is a bunch of highly iterative code that appears to try to match a unit seeking transport to a transport vessel. I think (hope) that this code is where the game bogs down when there are a whole bunch of 'plans' for transport that cannot find a matching transport vessel.

My current patch is not the best solution in the world, but it is simple and I don't think it will cause any crashes or really bad behaviour. Basically, I let the expensive matching code run until you hit a situation where there is no transport available. Normally this expensive code will run for every 'plan' that wants to get a transport and if there are a bunch of these 'plans' that can get expensive. My solution is to have a simple flag that tells me if I already ran into a situation where the transport was not available. If I did, then I skip doing the expensive code more than 1 time, and just let the plan go to 'failure'.

I really hope that the slowdown is not occuring in the 'failure' part of the plan, but you can test out my patch to see if it helps or if the planning is still too slow. If I get time I could start working deeper into the matching code itself to see if it is possible to speed things up there... lots of iterations are how you cripple even the fastest CPU.

I have a patch that is posted in the next message for you to try out. Remember, the file to patch is: ctp2_code/ai/strategy/scheduler/scheduler.cpp

[CajunArson]

--- ./scheduler.cpp 2007-07-23 14:22:02.000000000 -0500
+++ ./scheduler.cpp_edit 2007-07-24 12:04:27.000000000 -0500
@@ -568,6 +568,7 @@
Plan_List::iterator tmp_plan_iter;
Sorted_Goal_Iter goal_ptr_iter;
bool match_added;
+ bool out_of_transports = false; // this tells us if we have run out of available transports or not

#if 0
// This does nothing but waste time. AreAllGoalsSatisfied is never used.
@@ -701,28 +702,33 @@

case GOAL_NEEDS_TRANSPORT:

- AI_DPRINTF(k_DBG_SCHEDULER, m_playerId, goal_ptr->Get_Goal_Type(), -1,
- ("\t\tGOAL_NEEDS_TRANSPORT (goal: %x squad: %x)\n", goal_ptr, squad_ptr));
+ // optimization: If we have previously failed to get a transport, then skip trying to get a transport now:
+ if (!out_of_transports) {

- tmp_plan_iter = plan_iter;
- tmp_plan_iter++;
+ AI_DPRINTF(k_DBG_SCHEDULER, m_playerId, goal_ptr->Get_Goal_Type(), -1,
+ ("\t\tGOAL_NEEDS_TRANSPORT (goal: %x squad: %x)\n", goal_ptr, squad_ptr));

- match_added = Add_Transport_Matches_For_Goal(goal_ptr, tmp_plan_iter);
+ tmp_plan_iter = plan_iter;
+ tmp_plan_iter++;

- if(!match_added)
- {
- AI_DPRINTF(k_DBG_SCHEDULER, m_playerId, goal_ptr->Get_Goal_Type(), -1,
- ("\t\t **NO transports found. Failing.\n"));
- }
- else
- {
- AI_DPRINTF(k_DBG_SCHEDULER, m_playerId, goal_ptr->Get_Goal_Type(), -1,
- ("\t\t Transports found.\n"));
+ match_added = Add_Transport_Matches_For_Goal(goal_ptr, tmp_plan_iter);

- plan_iter++;
+ if(!match_added)
+ {
+ AI_DPRINTF(k_DBG_SCHEDULER, m_playerId, goal_ptr->Get_Goal_Type(), -1,
+ ("\t\t **NO transports found. Failing.\n"));
+ out_of_transports = true; // record the fact we could not find a transport
+ }
+ else
+ {
+ AI_DPRINTF(k_DBG_SCHEDULER, m_playerId, goal_ptr->Get_Goal_Type(), -1,
+ ("\t\t Transports found.\n"));

- break;
- }
+ plan_iter++;
+
+ break;
+ }
+ } // if out_of_transports is true, we just fail like in the original code

case GOAL_FAILED:

[CajunArson]

Hey guys, OK for the above patch, if you want me to email the patch file or anything else just post an (obfuscated) email and I'll send it there instead.
I don't have my own Windows build environment, so I'll let the experts try it out. If there are compile problems (I hope not, it's very simple) or anything else let me know!

[Martin Gühmann]

Well, you are on the right way, however there is a reason for that code, namely during this code it is checked how many transporters are missing, this is stored for the build list. Unfortunatly this doesn't work so well either. Actually the code trys to find unasigned transporters, for instance your current goal needs 3 tranports, but your last goal failed, because you had 3 tranports but you needed 4. In that case you could give the transports to the goal.

Well I still consider whether this is the best idea since the AI could go into life look state, doing a lot of little things without doing the main goal. However better way to do it would be to build up a transport database for each turn with free transporters, so you could just iterate these and assign them if necessary.

But for now we can go with your fix. And maybe consider the issue a little bit deeper.

-Martin

[CajunArson]

ACKK!
OK, the patch did not print correctly, I'm attaching the ASCII text file instead... html formatting...

A few more notes:

1. This is based on the revision 770 scheduler.cpp file.
2. To get it to apply, just put the patch file in the same directory as the scheduler.cpp file and run:
patch < scheduler_patch.txt

Do you guys have patch available? I develop under Linux exclusively so I'm not always sure what you have.

[Martin Gühmann]

Originally posted by CajunArson
Do you guys have patch available? I develop under Linux exclusively so I'm not always sure what you have.

TortoiseSVN has such a tool we can use for it.

-Martin

[CajunArson]

Oh yes, I fully agree that it is better to save the state of which transports are needed and match them up effectively... my patch is definitely a hack, but I hope it will help in performance.
As for more transports, in the short term could we apply a heuristic to encourage more transports to be built whenever we get a situation in which an army fails to match with a transport?
It might not be as accurate as a real database of the matches, but it could help alleviate problems.

[Ekmek]

Cajun,

Could you just post (it will have to be a zip) the schedule.cpp file with te fix. I'll back up the original and then try a build (its easier for me this way)

thx

[Martin Gühmann]

Originally posted by CajunArson

As for more transports, in the short term could we apply a heuristic to encourage more transports to be built whenever we get a situation in which an army fails to match with a transport?

One problem with transports is they are very vulnerable and so you need an army to protect them or build them when you have all the other invasion armies. BUt probably this is more a question of AI startegy.

-Martin

[Martin Gühmann]

Originally posted by E
Could you just post (it will have to be a zip) the schedule.cpp file with te fix. I'll back up the original and then try a build (its easier for me this way)

Go to the folder were you want to patch into it. Right click on it select TortoiseSVN and then click on Apply Patch...

So what is so diffcuilt about it?

-Martin

[Ekmek]

it looks for a .diff or .patch file i changed the file to scheduler.patch and it says index not found

[CajunArson]

Hrmm... it seems to be OK here, but patches can be problematic sometimes. I have attached the full file as a zip, see how that works.