Shard AI seems to be causing severe framerate drops for me.

[Chrithu]

Hello there,

I am currently playtesting the different AIs that come with Spring/BA in order to find the best one for me and my friends to play co-op against.

Thus far I like Shard the best as far as behaviour goes but everytime I start a game using that AI after about 20 minutes the framerate drops from 60 down to 8ish for some reason. It only happens using Shard AI.

My Spring Version is 0.96 and I am running BA 7.91. The Map is DeltaSiegeX. When adding the Bot it says Interface Version 0.1. I can't say exactly which Shard Version that is but is the one that came with Spring 0.96.

I am running on Win 7 64bit.

Has anyone else run into a similar problem? Or can anyone hint me on how to acquire more informtion to narrow down the cause for the framedrop?

Thx for any helpful reply.

Chrithu

[zoggop]

It's a combination of two things: First, the Lua code I wrote for Shard to play BA is pretty ineffecient. Second, as I understand it, the Shard-Spring interface keeps certain data in memory forever. (AF, who wrote Shard, understands this better.) My Lua code for BA accesses those kinds of data more often, and so eventually uses ridiculous amounts of memory. Once the memory usage maxes out the available memory, it gets really slow, like you describe.

I'm guessing it's the second that's the problem for you, but maybe not? Try running Spring in windowed mode and check its memory usage late in the game.

PS it's nice to hear the Shard BA config is behaving in a way that's fun to play against! sorry it fails otherwise

[AF]

Have you considered that a big game requires more effort from Shard? Without more information we're simply speculating

[PicassoCT]

Speculating.. that something a AI always has trouble with..

Cause if you have a scenario-tree which branch to walk down..

[Chrithu]

Sorry for the late reply:

The memory usage (leak?) definetly is the problem.

My friends and me made several tests running Shard and no matter how much memory you throw at it it will just eat it all up.

One of my friends even setup his own lobby server on his server machine at home and had the bot run on it and Shard just ate all the 8 Gig of ram after about 50 to 60 Minutes of playtime.

This seems to hint more at a memleak rather than just inefficent coding because 8 GB is an insane amount of data.

For the time being we will restrict ourselfs to non-water maps so we can use other AIs which do a good job too on those.

As far as additional Info goes: We are 5 people and usually play cooperative versus 5 AIs. In order to up the challenge we mix AIs (Shard, E323 and KAIK). The machines that run Shard Bots sooner or later run out of memor and have to quit the game.

The test on the server I mentioned earlier was done with Shard AI only.

[PicassoCT]

Time for a dirty-work-around crime? If you had another team, without units in stasis, governed by shard, and on memory-demise transfered the units.. and nobody is around to here it..

free (AF);

And by the power of the devs, this dirty-workaround- the moment it is installed, prompts the original devs, to get back to work, to at least break your fix.



PS: Lua is a nice language to do AI in - das Schwarm made by Knorke is quite impressive.

[zoggop]

If you had another team, without units in stasis, governed by shard, and on memory-demise transfered the units..

lol. don't forget, transfers the units and then starts another instance to wait for the next memory demise

for posterity, here's a link to the other discussion of this problem: http://springrts.com/phpbb/viewtopic.ph ... &start=620

my hunch is it's the large amounts of GetEnemies and/or GetFriendlies

ooo here's another lolzy solution: instead of using GetEnemies, just mill units around the map until one gets hurt, then we know an enemy of some sort is there

[PicassoCT]

Where the Com hurts his toe, the world gathers to weep!

Seriously.. there are c++ dlls who basically do garbage collection.. its unsynced anyway so why not.. get yourself free (;)

[zoggop]

Seriously.. there are c++ dlls who basically do garbage collection.. its unsynced anyway so why not.. get yourself free (;)

Seriously.. i not that smart

[AF]

The simple solution is to destroy the unit objects once the unit has died ingame on the next frame.

The problem here is if the lua AI keeps a reference to the object without cleaning up after itself, the AI could crash with a Segmentation fault. So I held off on implementing it, instead wanting a unit ID based system to work around the object problem entirely.

Instead I'm going to implement the original fix. Which I'll look at doing later today

[AF]

Actually, no, that already happens:

https://github.com/Tarendai/Shard/blob/ ... I.cpp#L116

They're removed from the unit map and then deleted

[zoggop]

They're removed from the unit map and then deleted

it did seem to be crashing from posthumous unit accesses before i made some lua changes to prevent those. but now of course the question is what does stick around in memory?

[zoggop]

AF, looks like there's a typo. The line that registers enemy unit deaths...

Code: Select all

struct SeNEMYDestroyedEvent* evt = (struct SEnemyDestroyedEvent*) data;

edit: there's a pull request fixing the typo