Is there a limit to the number of parties?

[Jinnai]

A search found some threads that discussed limits, but I couldn't find a direct reference to the number of parties the game is limited to.  I have seen something that suggested the number is over 600, but something I'm considering may put the number of parties I implement closer to 6000.

Has anyone encountered a limit to the number of parties before the game crashes?

 

[ealabor]

well..

I don't know about hardcode limits, but anyone using the reveal all cheat with 6000 parties is going to crash.

Its plausible to work it without the reveal cheat seeing as the partys would only be visible in range.


What you need to also consider is the AI. Your parties will chugg the map and potentially crash it when they are trying to spawn on timers. I'm not sure how much cpu strain it takes for them to process commands though.

You could offset that to a degree by randomizing the spawn/respawn timers in uh.. triggers.  it would be a task in itself to work that one out.

 

[Jinnai]

AI is not a concern.  And why do you think reveal all would cause a crash?

 

[Lonehwolf]

AI is not a concern.  And why do you think reveal all would cause a crash?

Because that many parties on the map, even 2000 would probably put strain on low end CPU and GFX.

 

[ealabor]

AI is not a concern.

It's a serious factor. You try to have all those parties spawn from triggers as once and nothing nice will happen

And why do you think reveal all would cause a crash?

As lone pointed out.

It would be the same concept as loading a battle with several thousand troops. Polygons and texture sheet cpu explosion.

 

[Lonehwolf]

It would be the same concept as loading a battle with several thousand troops. Polygons and texture sheet cpu explosion.

The thing you have to keep in mind here ain't your computer, but the potential "client"'s computer.  You want to cater for as many as possible.  While 2Ghz quad core processor can bang that ezmode, others may not be able to.  A good coder focuses on content, and efficiency.  Excess coding to provide fun in a way that could be done in an easier less strainful manner is a prime example of bad coding.  Try delivering the best package in the least strainful way on the computer.  We have evolved from those 8-bit games but we're still chained with limits cause not everyone has the latest computer build.

anything above 1000, as a rough estimation, is not something I recommend.  IF you really can't help it, at all... well then, it's your mod

 

[Jinnai]

Believe me, I understand having to code for slower computers.  And also believe me when I say AI is not a concern.  I can understand a polygon issue, unless the party models are say... simple cubes.  I have no idea how the game handles textures in memory, but if it doesn't just map a single texture instance, that makes me sad.  Well... I'll finish writing what I'm working on anyway, then just experiment.  If I find that upper limit I'll share what it is.

 

[Lonehwolf]

Believe me, I understand having to code for slower computers.  And also believe me when I say AI is not a concern.  I can understand a polygon issue, unless the party models are say... simple cubes.  I have no idea how the game handles textures in memory, but if it doesn't just map a single texture instance, that makes me sad.  Well... I'll finish writing what I'm working on anyway, then just experiment.  If I find that upper limit I'll share what it is.

Would be good to know :p

 

[Jinnai]

For those curious here are the results of my tests.
I'm running a core2 6600 with 3 gigs of ram, so my machine isn't slow, but no the fastest out there either.

I basically started throwing down hundreds of bridges all over the map, so they had no AI needs, but they were always visible on the map.

At 1000 total parties in the game the view all cheat became unusable, but no other side effects noticeable.  I find this interesting because it shows that parties are handled very differently with that cheat turned on.  With it off there was no slow down at all, yet you could always see all the bridges on the map.

At 2000 total parties in the game the accelerated time from resting started showing skipping and slow down, so this puts it as the upper limit in my mind for my particular processor.  Normal movement around the map had no problems at all, however.

At 2439 parties in the game (the max I hit before calling it quits) the normal map movements were slightly jittery, but not too bad.  However, loading the screen initially did take a second or two, which was unusual from the norm.

At no point did the game crash or exhibit any errors.  Even with over 2400 parties I was able to engage in combat, visit towns and villages, you name it.  For all intents and purposes I would be willing to say there is no upper limit.  It becomes a matter of CPU usage.

 

[Lonehwolf]

At no point did the game crash or exhibit any errors.  Even with over 2400 parties I was able to engage in combat, visit towns and villages, you name it.  For all intents and purposes I would be willing to say there is no upper limit.  It becomes a matter of CPU usage.

core2 6600 should be a dual core 2.4 or 2.6 Ghz I believe.  That's definitely not a modest computer you have, so if you encountered slow downs at that point, I believe any more than 600 is stretching it.  Some don't even have dual cores, and hit 3Ghz maximum for processing.  To open your mod up to as many players as possible going above that limit would probably be unwise, unless you have to.  Either way 6k troops on a map is quite a lot.  I'm unsure whether the strain was on your CPU or GFX seeing how the CPU processes things visible or not to us, while the Graphic card renders all that's visible.  It seems you encountered stuttering when the cheat was on, so my guess would be is that the GFX is determinant as well when it comes to parties.

Where the 2000 + parties you inputted all visible on the map?  I doubt it probably 40% of them were probably garrisoned and waiting at towns/castles.  And we're talking about actual parties not troops, correct?

 

[ealabor]

I basically started throwing down hundreds of bridges all over the map, so they had no AI needs, but they were always visible on the map.

I see..

I misunderstood what you were trying to get it. I thought you were referring to AI parties, as opposed to other files in module_parties such as towns etc.

Yeah reveal all with only slow down as based on the number of AI parties running around. Static parties are handled a little differently, being that they always visible as im sure you know. Trees and icons account for static parties. Icons will always be visible regardless of distance. Not sure about tree's though, because if you make a map big enough, it acts as a scene, and if you get far enough the map can leave the field of view, which might stop displaying trees at that point.


One thing you should test is going to a corner of the map, then go to ground level view and try to pan your field of view across the map. That'll test the performance 

 

[Jinnai]

I think both of you misunderstand... (though different things)

Lonehwolf: It was definitely CPU limitation, not graphics card.  And if you read what I wrote again, all of the parties were visible at all times as they were bridges.  (Yes, the game treats bridges as parties.) Which means no AI calculations were required, but it any time the game does a try_for_parties it still has to loop through them all.

ealabor: Moving around at ground level had no effect on speed as opposed to moving around above the map.  And reveal all slowed down due to the bridges being there, which means it has nothing to do with AI calculation.  And as they ARE always visible anyway, I found that very strange that turning on the view all cheat made such a difference in performance.  It was definitely the number of bridges on the map too, because as the number of bridges increased the slowdown with view all turned on was directly proportional.

Still, was an interesting experiment, I think.   And I think I can still get away with a limited version of what I was originally trying to do.  And of course a game setting switch to turn it off for people that it just slows down too much for.

 

[Lonehwolf]

I think both of you misunderstand... (though different things)

Lonehwolf: It was definitely CPU limitation, not graphics card.  And if you read what I wrote again, all of the parties were visible at all times as they were bridges.  (Yes, the game treats bridges as parties.) Which means no AI calculations were required, but it any time the game does a try_for_parties it still has to loop through them all.

ealabor: Moving around at ground level had no effect on speed as opposed to moving around above the map.  And reveal all slowed down due to the bridges being there, which means it has nothing to do with AI calculation.  And as they ARE always visible anyway, I found that very strange that turning on the view all cheat made such a difference in performance.  It was definitely the number of bridges on the map too, because as the number of bridges increased the slowdown with view all turned on was directly proportional.

Still, was an interesting experiment, I think.   And I think I can still get away with a limited version of what I was originally trying to do.  And of course a game setting switch to turn it off for people that it just slows down too much for.

Ooh skipped that line ealabor quoted ;o

 

[ealabor]

So you have no AI parties running around then?

 

[Jinnai]

Just the standard lords and patrols, which should equal to about 200 to 300 AI parties.  The thing is, the way the game actually handles AI is in two phases.  There's the behaviour, which is handled internally, such as hold position (what bridges do), or travel to position (which most typical parties do), so I have no idea what kind of difference in processing that provides, but it seemed that bridges added very little to that, and I'll explain why I think that.

The other phase of the AI is in the party slot and handled in the module_system.  There are a number of simple triggers that loop through all parties to handle this one.  And I added one that was called every tenth of an hour.  All it did was loop through the parties list and sum up the number of parties.  That extra code noticeably added to the slowdown at around the 2000 mark as well, but not before.  Every 500 parties I added another such trigger.  Each time there was no noticeable change until I hit the 2000 mark, which is another reason I consider it the cap (for the grade of CPU I have, not sure if it's a global thing.)  Though the stuttering was there both with and without the added trigger.

When I saw the 2000 mark was the upper end for pleasant playability (if you don't mind some game stutter it could've gone higher) I did change one of those tenth of an hour loop all party triggers to set the behaviour of ALL parties to hold, which essentially turned all lord parties and patrols and caravans into bridges.  I went back and tested if this had any affect at 1500, 1750, and 2000 parties.  I was able to push to about 2100 parties before the same level of stuttering.  I would guess it's because there's usually only about 100 parties (in my mod) at any point in time actually trying to figure out a path to a destination.  Hence, the hold behaviour had no real affect on CPU time at all.

I have not tested turning all the bridges into kingdom hero parties and seeing how the game responds, but I imagine that will depend entirely on how far apart the AI triggers are spaced.

 

[WilliamBerne]

I don't care what tests you have made, what I know is:
start a new game, ctrl+t open the whole worldmap, my fps is 40. after one day, when all the lords have been spwaned and begin to "think" what they should do next, my fps down to 20.

 

[Jinnai]

I tried searching for this topic before I even created this thread, but didn't find anything.  Do you have a link to your post?

EDIT: I see your new thread in this forum, so I guess nevermind.