I'm interested in the outcome of this, I have been playing with the sorian AI from vinilla and I can safely say that any 80 x 80 map for me and my friends v the AI is just a no go. (The slowest machine in the batch is a duo 6400 pushed to 3.2) as the sim speed just drops to -7 or -8 in a mear 30 mins

I will try out 1.9.9C with 3603 with my mates and test it out, We don' tuse any other mods what so ever so if it is just that I will report back the findings

We played some more games and there was no slowdown at all.
We played on Serpahim Glaciers with 1 Water AI. And Mods activated:
Anti-Nuke Price
BatteryAcid's Rapid Fire Artillery Defense
Bonomel's Air Borne Engineers
Cliff Hanger
Community Bug Fix V3
Hotstats Intelligent Shields
Ship Wreckage
Supremilated: AutoMassFabs V2
T3 Mobile Anti Air-Units V3
Total Veterancy
Total Veterancy Auto XP
Total Veterancy UI

The interesting part is that Serpahim Glaciers slowed down more than Sethons or other 20x20 maps in the past. We will try it on Sethons if the slow down there ist gone too

EDIT:

Sethons no slowdown too

Funmaker I also made a copy and patched it to 3603beta also reverted it back to Sorian 1.9.9.c

3 Sorian AI Adaptives with me hiding out in my AI teammates base..500 unit cap on Setons Clutch with 15 mods enabled while most of them are unit mods..At 36minutes the game was at -2 actual speed..

My crappy computer: Core2duo E6750, 2gig ram, WinXP 32

So although i cannot verify your results (also i forgot how simspeed goes on my 3599) i think we need some more testing..Any one else ?

EDIT: Run the same game with 3599 and Sorian 2.0, results were nearly same -2 speed around 30min mark...

I wish I could get involved but some of the applications for dev dont run on win 7 64 bit. I removed the beta patch and went back to the prior patch as well as prior sorian release. The newest sorian release seems to slow down sim speed. I considered helping with AI dev but until they actually release a map editor to work with the markers that will run on win 7 64 I cant see myself doing it. I dont wanna down grade to xp 64. I commend sorian and duncane for their awesome work. I just wish I could get involved. Being an engineer I might be able to help.

Which dev programs are you talking about? The in game debugger? As far as I know that never has really worked right. Most of us just use the log window and ~ key ingame console.

I had problems to when everything was installed in Program Files 86. I could not get any of my programs to work. I use mostly Crimson editor, Win Merge and 7zip. None of these would work anymore because of the UAC.

In my case I moved everything out of the Win 7 program Files 86 and created a games directory in Local Disk C. I had to do this with all my games. Elder Scrolls, Sins of a Solar Empire etc because none of the game tools would work because of the UAC even trying to run as admin.

I should add that when I first moved the games out of Win 7 program files things still did not work because even using the game uninstallers remnant files were still left behind. especially in Virtual store. using search I tracked down every old game file and deleted them all and then did fresh installs and now all my programs work again.

Maybe that is your problem also? if so I hope this info helps

Moe

For getting rid of crap games leave after uninstalling and not worrying about them leaving remnants behind try CCleaner

Its a combination registry cleaner and remnant remover and uninstaller. I think can also be used to change what application start up when you log in to a user account.

Just be sure to check what it wants to delete before deleting it.

Some promising news;

It's been some months now since I started tearing apart the AI. In that time I've seen and learned a great many things - but until recently - I couldn't really put my finger on the nature of the 'creeping' slowdown.

Obviously, the issue is related to a great many things - and I came to the conclusion that no matter what - even if everything was perfect - as the number of units in the game increases - performance will always slow down. However, the degree of slowdown should not be so severe as to make it a chore to play large games. The previous attempts to identify the slowdown, by limiting the number of expansion/naval bases created by the AI seems to help - and more importantly - led me to examine the nature of the 3 core 'managers' central to any base.

The PlatoonForm, Engineer and Factory managers are essentially very busy processes - and without going into great detail - my investigations revealed that as the game progresses - and the build conditions for the various units, buildings and platoons are met - these Managers get severely overloaded. Consider that the creation of each new expansion/naval base adds another set of these - and you can see why things get so slow. In response - the games own internal controller senses this - and slows the game down.

I tried many things - like creating engineers with longer tasks in mind - so that they weren't constantly bugging the Engineer manager for new jobs as frequently. (Case in point - Resource engineers - once they build a mex they go home and want new work - I altered them to repeat until there were no more available mass points).

Long story short - a significant gain in long term performance can be gained by using very specific Build Conditions for everything. Example;

Most engineering tasks require a specific tech level of engineer to do thier job. However, looking at the standard build conditions - I came to realize that none of the jobs bothered to check if the required engineer was even available (in the 'Pool') before trying. Net result - the Engineer manager goes thru all of the steps to fill a job for which no engineer is available. Not only is this inefficient, it also means that other jobs of the same and lower priority - that could be filled - get overlooked by the Engineer manager.

This gives some explanation as to why certain jobs - which on the surface should be able to done by the AI - never seemed to get done - the Engineer manager would get so clogged looking at jobs it could never fill - it couldn't reliably get around to the ones that could.

Likewise, with the Factory Manager - because the basic unit construction build conditions didn't specify that a certain tech level of factory was required - the manager would attempt to build T3 units when no T3 factory was either available - or even existed.

Again - like above - Platoons are formed with a certain minimum number of units specified - by adding a Build Condition to each platoon - that specified the minimum number and type of units required - the Platoon Manager doesn't try to build platoons until those conditions are met.

Addressing the above issues required the addition of extra Build Conditions to almost every Engineer, Factory and Platoon task - and there are a lot of them. But - in return - it was worth it. On a game with 3 AI - a 1500 unit cap - and a very large map - the typical slowdown would become pronounced at about the 20-30 minute mark. With the above changes - the slowdown still occurs but not until about the 50-60 minute mark and to nowhere near the same degree. It only became staggering when all 3 AI reached Unit Cap.

I won't decieve anyone here - there are many other underlying issues - many of them correctable - to one degree or another - but this one fundamental change makes a marked improvment.

Is there an .scd file you could share that would include your changes? The AI sim speed slowdown is still one of the worst remaining issues in my gameplay. I'd love to get my hands on anything that might help.

Well - I'd love to share it with everyone - but as I was originally working on this for play with my own narrow group of friends, I was incorporating repairs not only to the AI but adapting it for use with the Black Ops Unleashed and the Community Bug Fix mods. I have also made some minor changes to the LUA.SCD of FA itself. None of those extras are required to gain the benefit of this change - but it's why I can't just deliver a single file.

I can however show you an example of the kind of change I made - and where I made it - that should permit anyone with a little knowledge of unzipping and rezipping files - and using a text editor - should be able to perform.

The original AI - and other AIs' like Sorian and Duncane - split most of the Engineer, Factory and Platoon Formations into a large number of seperate files. These files, and the directories they reside in, are packed into an SCD file which is usually in the GAMEDATA directory. For example the original game AI is packed into the LUA.SCD file. Inside that SCD file are packed a series of folders and files (all text) that govern the AI and how it works. Sticking with the original AI - you'll see a LUA folder, and inside that, an AI folder.

The AI folder contains even more folders and files - but for my example we'll look at the AIBUILDERS folder and the file called AIECONOMICBUILDERS. This file governs many tasks (but not all) performed by the Engineers (the Commander included) - here is an example of one of the many tasks -



As you can see - this is a very high priority task (970) which means that it's going to get assessed very often - and processed - if all of the BuildConditions are true. Look at those closely - you'll notice that none of them check for the presence of an available engineer. It just checks if you actually have less than 3 TECH2 or TECH3 engineers - and that there is actually an available mass point within 250 grid units of the base.

I understand the intention of this - in that you don't want this job to be actioned if you have several TECH2 or TECH3 engineers - BUT - it doensn't check to see if you have any available TECH1 engineers. As a result - this job gets checked very very frequently until it can be filled. In a roundabout way - it will work - but it's being checked so often - that other tasks, with lower priority may not get processed as soon - or at all.

So - in the BuilderConditions - I've added a single new condition as follows;


This line checks if there are any unassigned TECH1 engineers available. It's no more difficult than that. The difficulty really lies in putting a line like this in ALL of the many tasks that engineers can perform - and those are spread out in many of the files.

Or, you could go one better and do what we did for Supcom 2 and add an entry to the build bp that lists the units (by id) that can perform that task. This would help split the faction specific builders as well.

I'm also using Sorian's AI, BlackOps, and the Community Bug Fix mods.

I took a look inside the Sorian AI and the folders and files you've mentioned hoping to try and integrate the changes you've mentioned. Wow, with my limited knowledge of the AI's files, it seems beyond my capabilities. I'm confused as to determining which tasks would require the modification line, and how to modify the example line as needed for each particular circumstance.

Is there any way I could get you to send me copies of the various .lua files you've modified, particularly in the Sorian AI? I'm not sure if these fixes were applies to both the standard AI files and the Sorian AI files? But if you could send me the individual .lua files modified for this fix, I'd be able to integrate them and re-zip the .scd files as required.

Appreciate any help you could give; would love to try and reduce the AI slowdown issue.

Looking at the code, there is a much easier solution (assuming this has an effect).

In lua/sim/BuilderManager.lua in the GetHighestBuilder() function change this line:



To this:



This will make sure that the build item is actually valid (priority >= 1) and that the engineer or factory can actually build the item before checking conditions.

I'll run some tests to see if this actually has a positive effect on sim speed. If it does I will release a new version of my AI mod with this change (might even sneak some other ones in there too).

Thanks Sorian! Hope this works...looking forward to your results. Let me know if there's anything I can do to help.

Glad to see the acknowledged 'guru' back for a visit !

That change certainly addresses the Engineer and Factory managers - but I did find that it was really the Platoon Form manager that had the most impact. At first I was reluctant to add more Build Conditions - but once I started on it - it made a real difference. Overall - Sim Speed improved by about 30-40 points at any given time in the late game - very noticeable. More importantly - platoons got more reliably formed - and the base decluttered as a result. That plays a significant role in keeping things moving.

Now if I could just knock the stuffing out of the Base Distress Response function I'd be a happy man. I've toyed with turning it off entirely - but that sometimes leaves the base exposed when there are plenty of pool units around to deal with it. I've compensated somewhat by having a Base Defense patrol - but it's hit and miss.

New version of Sorian AI is posted in his thread, incorporating these changes. I've not had the chance to test yet...hopefully by this coming weekend.

I've tested the new Sorian AI mod in an AI versus AI game. Normally by the 30 minute mark I was running +1, and -1 by the hour mark. This time, I was still running +4 at the 30 minute mark, and +2 at the hour mark. It definately seems better to me, but I've only had time to do this single test. Anyone else have any results?

I continue to have positive results in test after test - game after game. It's not a massive improvement to be sure - but it's significant. Of course, in some games, where the AI gets 'jammed' in his base - it's still a real pain - but there is light at the end of the tunnel. The usual cause for this 'jam' seems to be the Base Distress Manager, which often draws large numbers of units into the core of the base - causing an immense - and unstoppable traffic jam of units.

After working on this code, and finding small error after small error - the results are certainly tangible. As I noted previously - the most noticeable improvement in overall speed came after I put Build Conditions into the combat platoons that keep the Platoon Manager from trying to form them when the necessary units are not in the pool. I don't believe that was addressed with Sorians' most recent release. I haven't yet examined that - but if it isn't - and those are added at some later time - it should make an appreciable difference.

The more I work with this code - the more I realize that it deserves greater attention than it got. That's no slight on those that put in the time to improve it already - it's more a realization that there's so many possibilities yet untapped.

My recent changes do change the Platoon Form Manager. A check is done engine side to ensure the platoon can be formed at all before build conditions are checked.

I've been absent for a bit, but I wanted to follow up a bit on the issue regarding platoon formation. I put a code tag in to follow the platoon managers efforts to form platoons, and I still see the manager attempting to form platoons and then fail.

The additional code which Sorian recommended didn't change that behaviour as it does seem directly related to the build conditions for the platoon. One of the culprits appears to be the PoolGreaterAtLocation condition which apparently includes all units which are currently under construction as well as those already completed.

As an example, the platoon manager will begin repeatedly attempting to form an experimental platoon right from the time the experimental begins construction. This causes a good deal of thrashing by the manager code.

Best practice seems to infer that platoon build conditions should be as specific as possible to minimize (but not totally eliminate) this. Once I inserted a check into the PoolGreaterAtLocation function, to subtract the units of the called category being built, performance noticeably improved. Of course, having more build conditions in the platoons gives back some of this gain, but the improved reliability in the timely creation of platoons pays other dividends.

Would you mind posting the change?

I'd certainly be interested in anything that might possibly speed up the AI even further!

The alteration I made goes into the UnitCountBuildConditions.lua file.

The function which is modified is called;

HavePoolUnitComparisonAtLocation - which is responsible for returning the number of units of a given category at a given location. In total, 4 lines were added;



at the top of the function - so that units being built by factories can be accounted for and then next 3 lines at little farther down, just after the original function calculates a value for numUnits



This gets a number of functions actually reporting on the existence of certain units - while not including those being built.

Of course, adding code doesn't make anything necessarily faster - the real gain comes when the platoon Build Conditions - and the platoon template definition match up properly. This is why simply editing a platoon definition (to increase it's size or composition) doesn't always help your cause. Consider this build condition;



Then compare it against this edited platoon template;



You can see that this will allow the Platoon Manager to try and form the platoon as soon as there are 11 naval units - but the formation will fail because the platoon template requires a very specific (or larger) number of units.

This is where the gain can be made - by altering the build conditions to more closely match the template - or the template rewritten to more closely match the build conditions - the platoon manager is saved from going thru the formation process only to fail at the end.

The more important gain is that some other platoon, which may actually be formed has to wait in liine for all this to happen before it gets it's chance.

This is why it's so necessary to have the PoolGreaterAtLocation function accurately report what is built and not include what is being built.

So in the new setup the number of units is calculated correctly because it only includes the units that are completed. That updated value is then correctly used because instead of being 10 units including units being built it is now say 7 units and the plattoon manager will exit out right away instead of trying to make a plattoon it doesn't even have the correct number of units for correct? Or is that check not there?

The second set of changes checks if each type needed is there one by one and then exits if that unit isn't build yet.

Yes - that's exactly what is going on.

Once everything is lined up (build conditions and platoon template match) the platoon manager functions smoothly and can efficiently check all of the possible formations.

The naval platoon template I used as an example is a little over the top, but it's a good example of how one can get exactly what they're looking for. If the build conditions were expanded, to be more specific to that particular platoon - you'd get no thrashing at all. The example I provided would only reduce the chance of failure - but not eliminate it.

There is a small performance cost associated with adding more build conditions, but it's much smaller than the penalty associated with trying to form a platoon which will only repeatedly fail, sometimes dozens of times.

This set of changes would fix a large amount of the failed attempts in the platton manager and similar items have already gone in for the engineering manager and factory managers in Soran's AI?

Must be quite a speed up overall.