What should I know about mission director? (Yes, it IS the issue!)

[Space Traveller]

Well....I tried it. So far, no success =(

@Dome1: The dual convoy mission is from Albion Prelude. From what I can tell, you must have used the "/addon/07.cat" file? There is a "3.01 Generic Missions.xml" file inside. (under /addon/director/)

There is also a 13.cat file in the main folder (for TC, I think). It also has this file, but no trace of the dual convoy mission. As i am playing AP, i assume i am correct in using the last cat file from the addon folder...?

Now the most important question (and maybe the dumbest mistake of mine): can i go on with my save games? Or do I have to start anew? If the latter one is the case, disregard my statement that i had no success so far and i may try again.

Sorry for being not exactly an expert here...but i'm really determined to find the solution and get X3 running for me again! So thank you so much for all your help

[Nanook]

If you can't reproduce this issue in a vanilla game, then you need to take this discussion to the Scripting and Modding Forum. The Tech Support Forum is for dealing with issues with the vanilla game only. Any more discussions of a modded game will result in this thread being locked. Besides, there's a lot more expertise available in the S&M forum regarding modded games.

[Space Traveller]

@Nanook: I can understand your point of view. But like I said earlier, I experienced similar behaviour in my last game which was 100% vanilla. (I remember the problems to be less severe, but still the game got slower and slower as time went by)

Please understand that I can not simply "reproduce" this bug, as it happens to appear only after many ingame days and isn't exactly a sudden change but more of a "situation getting slowly but constatly worse". Starting a new game and investing many hours just to find out if the savegame will be "corrupted" again (and hence lose all my progress) isn't something I just can do so easily.

Also, I can only state again that this is neither a driver issue, nor is my system spoiled or anything. Any benchmark tool and many other games run without a single issue. The fact that resetting the mission director suddenly makes the game jump to constant 60 fps (even in heavy fighting scenes) also makes it rather obvious that my hardware is more of capable for X3.

Now someone in this thread seems to know a (potential) source for this problem and a way how to fix the game and make new savegames not "poison" themselves to the point of becoming virtually unplayable. And even this includes extracting and alterting some mission scripts, I really think what is going on here should be labelled "bugfixing/repairing" rather than modding. Even if the tools are highly similar.

However, if you (or someone else from the staff or anyone) has actually another idea where my problems might come from and how to combat them, of course I'm very grateful for any input!

[glenmcd]

Nanook is correct and that's why I opted out when the thread was becoming a lesson in how to script. That part does need to be taken elsewhere.

No matter what else you do, I suggest to immediately and permanently disable the vertical sync for your X3 games, so that you can see framerates go above 60 FPS. If you allow the game to limit to this, you don't get as much feedback. You can't identify the times when suddenly your framerate drops from 800 to 110. Things like this are critical to working out what is going on. So don't make it harder for yourself by letting this shield from valuable information remain.

Okay so here's a few suggestions. I've put up a new thread with subject "Supersized Complexes - without the lag - for all". Have a read in there and if it seems possible that your framerate and gate passing issues are more to do with complexes, then try out the fix suggested.

The very best way of communicating a problem to another X3 player often includes sending a save file. Send preferably vanilla saves to x3@glenmcd.com and I'll see what I can work out. In the past this usually quickly leads to a satisfactory diagnosis. Sometimes, it's the way the player goes about doing stuff in his game which exacerbates something in the X3 engine. A save communicates all of this.

Regarding generic missions, I may take a look at these today. By this I mean benchmark to attempt to get framerate penalty numbers for each mission type. Obviously, the target is zero for all. If I can complete those I'll report findings back here, even if it's to refer to a new thread if that seems necessary.

UPDATE 18th Feb: Missions benchmarking setup coming along nicely, been working on it all day. Should take a couple more days. Results should have some definitive answers for you.

[Xenon_Slayer]

There are known issues with some missions. I mentioned the ones we've identified here. Of course, if you see anything else odd, let us know and we'll take a look.

[glenmcd]

There are known issues with some missions. I mentioned the ones we've identified here. Of course, if you see anything else odd, let us know and we'll take a look.

Every time I looked closer (researched, tested and benchmarked) at the generic missions what I found just intrigued me more. Today I got to the point that I had a good selection of generic missions available yet after jumping around 61 sectors in less then five minutes, framerate was still excellent. I'm not suggesting that what I have is suitable for use by players. It's proof that even with the Mission Director bottlenecks remaining untouched, workarounds can get pretty close to something that even very fussy players (performance wise) can be satisfied with.

There's a performance bottleneck that can activate even with all generic missions disabled. It's to do with Asteroids. If you fly into a sector with asteroids even with completely empty generic missions file, it can trigger a performance penalty of the order of 150 FPS. All "framerate penalties" I give are valid when your framerate is at 1000 FPS already or very close to it. It cannot be cleared by resetting the Mission Director. It can be cleared by removing all Asteroids in the universe, or by jumping into a series of sectors with no asteroids in them. This is already assuming that all generic missions are disabled. If not, then you wouldn't be able to tell when it clears anyways.

EDIT 1st March 2016: On trying to get further with this asteroid issue, I'm having problems reproducing.
EDIT 4th March 2016: Still not able to reproduce asteroid issue (the one where Mission Director reset doesn't fix). Removing it from list.

Sector quotas:
I found that careful setting of these are essential for avoiding the worst of the MDs bottlenecks. I actually found that setting all four (trade/fight/build/think) quotas (in the globals file) to one (1) was the only sensible thing to do. When you have multiple generic missions of same type active in one sector, the performance penalty increases exponentially. With zero missions on offer in my test sector, framerate measured at between 998 and 1013. With just one mission active, the framerate seldom went below 998. In other words, the penalty is so small for one mission (which activates two cue instances for the first in a sector) that I could hardly measure it. Two of one mission type in a sector gave a penalty of something like 50 FPS, for the mission types that generally behaved themselves. The third gave 150 FPS penalty, the fourth 350 FPS penalty. Different missions are slightly different in this regard, but overall the message is clear. Stick to zero or one offering of each mission type throughout universe.

I tested all generic mission types for affect on framerate initially, and monitored while framerate recovered right up until all resources for that mission were recovered. Where this could not be achieved, I managed to find out why and these are detailed below too.

The following generic mission types I'd call "well behaved". They free up all resources quickly, they respect the sector quota and their overall framerate penalty is not bad at all, when the quota is kept down to one. Recovery time was in the range of ten to 25 minutes for these. On recovery, 1000 FPS was always the result. Framerate testing was always done in same sector and under similar conditions.

L2M101 - Assassination
L2M103 Transport (single) Passenger
L2M104a Deliver wares to station in need
L2M104b Deliver Illegal Wares to Pirate Station
L2M104c Deliver Illegal Wares to Trading Station
L2M105 Return Abandoned/Stolen Ship
L2M108 Xenon Invasion
L2M113 Follow Ship
L2M116 Transport Cargo
L2M129 Deliver Matching ship
L2M130 Passenger Transport
L2M134 Generic Patrol
L2M135 Defend Object
L2M136 Notoriety Hack
L2M147 Buy Sector Data


The next list requires more detail as each has an issue:


L2M150a Buy Used Ship from flying ship
L2M150a Buy Used Ship from station
It's possible to spawn one of each in a sector, while quota is set to one. Individually though they are quite well behaved and could go in list above.

L2M119 Escort Convoy
L2M127 Destroy Convoy
These two are by far the worst offenders when it comes to bringing down framerates very quickly in X3. The only possible exception exists if you have a large factory complex built using the old way with CCKs. There's so many problems with these two mission types that it's difficult to know where to start!
1. Neither respects sector quota, unless quota is zero. Even with sector quota set to one, I had up to six spawn per sector, which added up to 21 ships in that sector. That's just for one sector entry. I tried setting quota to 100 and it made no difference to these.
2. If you exit the sector and re-enter, the missions of this type that were on offer when you exited, are no longer on offer. However, the ships remain, and cues remain in the Mission Director, and the enormous framerate degradation from your first sector visit doesn't go away. Instead, it just gets worse each time. Nearly every other mission type completes and frees its resources in less than 25 minutes. These are never shorter than around 45 minutes, I've seen them go as long as four hours, and seemed to average around 2.5 hours. The framerate penalty per mission is something like 20 to 100 times that of most other missions. And that's just if you happen to have only one spawn. If unlucky and get a few in one sector (you can't restrict through setting of quota), either of these can halve your initial framerate in a single gate pass. On entering a sector, during the time that the "smoke clears", if you notice significant stutters at that time, it's likely that one of these mission types spawned.
3. The time until cues disappear and framerate returns depends entirely on ships flying to a station perhaps a sector or four away. If you're lucky, they'll fly at around 50 m/sec. That's when they have full hull. A Dolphin with damaged hull can fly as slow as 9 m/sec.

L2M133 Freight Scan
Similar to above, this mission type does not respect sector quota. When only one spawns, FPS penalty is negligible and it recovers quickly.

L2M144 Asteroid Survey offered from ship in space
This spawns a ship with name <race> Mapping Service <shiptype>. I only had a few spawn and all in different sectors and different races. However it has quite a problem. This mission doesn't clear without special action. Meanwhile, this ship hangs around forever, each providing a framerate penalty. Just entering the sector that it's in can make it jump out of existence. If not, destroying it will lead to framerate recovery in ten minutes or so. In any case this is a cleanup issue for this mission type. It is actually not related to the first issue mentioned in this post which is related to Asteroids but not any ships.

In the thread linked to in your post you mention that L2M145 Scan Asteroids has a cleanup issue. I found this particular mission type is okay in that regard. The fact that there are multiple issues all that relate somehow to Asteroids I guess complicates matters a bit. If you remove all asteroids in the universe, at least two framerate issues disappear. Unless you are very careful how you go about testing it's very easy to miss one while masking out the other. When things didn't add up for me, I found the initial Asteroids framerate issue that had no ties to the Mission Director by first disabling all generic missions, jumping through various sectors and watching out for framerate drops, recoveries and patterns. A pattern did emerge, and the only way I found to mask this out was to only enter sectors void of asteroids, or to throw away tests in which I did enter sectors with asteroids and the framerate penalty happened. I have not yet worked out why the framerate penalty doesn't occur every time.

L2M161 Buy blueprints:
This mission type does not respect quota. This leads to aggregating of framerate penalties as one flies around the universe, also to greatly increasing framerate penalty for each sector entered. This particular issue that is in multiple generic mission types can easily multiply overall framerate penalty by many times.


PUTTING IT ALL TOGETHER IN A WORKAROUND TEST:
I'll compare here two test runs. Each started in UKS East of Unseen Domain, entered each sector on route to Kingdoms End, then to Ghinns Escape, then to Queens Harbour, then back to UKS for the final framerate measurement. In each sector, total frames to date is logged as well as playing time and average frames per sector to date. Playership waits in each sector for 2 seconds only before using "Put into environment" used to enter next sector. Thus the ten second wait before entering next sector (jumpdrive) was avoided. Various things were done to ensure other sources of framerate penalty did not invalidate the results. For example there were no player factories. The "jobs.txt" file was completely empty, minimising the number of NPC ships in the universe other than those spawned for generic missions. Player had only one ship.

When framerate is already very high, it takes just a small additional CPU load to drop 50 FPS. Once framerate is down to below 100 FPS, it takes a lot more to drop this amount. Thus, keeping framerate in the many hundreds after jumping quickly through dozens of sectors with generic missions enabled, requires scrupulous attention to removing every single source of framerate penalty. This was my goal and this was achieved in the workaround.

Run "A" was closer to a Vanilla install in the following ways - all generic missions enabled, quota set to 4 for each, asteroids not removed. Run "B" had a small number of generic mission types disabled, quota set to 1, and all Asteroids in the universe removed before starting the test run. Complete removal of asteroids was unfortunate but necessary in order to mask out significant framerate penalty producers.

Framerates START->END:
A: 989 FPS -> 198 FPS
B: 1013 FPS -> 693 FPS

Total frames after 1/2/3/4/5 sector swaps:
A: 1980/3237/4234/5047/5866
B: 1995/3692/5019/6056/6987

Total frames after 10/20/30/40/50/61 sector swaps:
A: 11471/21520/30215/37890/44070/50233
B: 12804/26185/37138/49793/61270/73954

Average frames per sector across the 61 sectors:
A: 823
B: 1212

Cues showing as completed in Mission Director after 61 sector swaps:
A: 47
B: 8

Recovery of initial framerate through waiting in Unknown Sector:

A:
47 cues 9 minutes playing time, 196 FPS
40 cues 22 minutes playing time, 215 FPS
28 cues 28 minutes playing time, 288 FPS
20 cues 33 minutes playing time, 379 FPS
10 cues 38 minutes playing time, 550 FPS
6 cues 42 minutes playing time, 588 FPS
4 cues 43 minutes playing time, 740 FPS
2 cues 207 minutes playing time, 900 FPS
2 cues 240 minutes playing time, 970 FPS
2 cues 9000 minutes playing time, 970 FPS

Obviously, the final 2 cue instances didn't want to clear.

B:
8 cues 8 minutes playing time, 693 FPS
6 cues 16 minutes playing time, 760 FPS
4 cues 24 minutes playing time, 850 FPS
2 cues 25 minutes playing time, 960 FPS
0 cues 26 minutes playing time, 1013 FPS


Back-to-back tests (same 61 sector route performed twice without break):
Initial->Final framerates:
A: 1009 -> 86
B: 997 -> 593

Recovery:
A:
107 cues 11 playing minutes, 86 FPS
101 cues 19 playing minutes, 91 FPS
89 cues 23 playing minutes, 100 FPS
70 cues 28 playing minutes, 125 FPS
45 cues 35 playing minutes, 180 FPS
25 cues 41 playing minutes, 272 FPS
20 cues 48 playing minutes, 303 FPS
16 cues 60 playing minutes, 355 FPS
12 cues 76 playing minutes, 420 FPS
14 cues 91 playing minutes, 365 FPS
10 cues 92 playing minutes, 480 FPS
11 cues 101 playing minutes, 450 FPS
8 cues 103 playing minutes, 550 FPS
10 cues 110 playing minutes, 500 FPS
6 cues 111 playing minutes, 630 FPS
4 cues 120 playing minutes, 760 FPS
4 cues 150 playing minutes, 810 FPS
(At this point, I searched through universe for <race> Mapping Service <shiptype> ships and found two. On destructing the first, cues reduced to 2, framerate improved 810 FPS -> 910. On destructing the second, cues cleared to zero, framerate improved 910 -> 1000+. I reloaded a save as at 65 minutes playing time, performed the same destructs, again both reducing cues by 4 and improving framerate. Because in test "B" below I had removed all Asteroids in the universe, this issue did not arise in "B".

B:
11 cues 12 playing minutes, 593 FPS
0 cues 27 playing minutes, 1013 FPS

SETA:
Use of SETA can reduce framerate. However its affect is very different depending on your initial framerate. When framerate is already >990, SETA x 10 makes hardly any impact on framerate. But when you're already down to <60 FPS, framerate can halve and worse. The non-discerning player may not be too concerned with 50 FPS, but in these games, SETAx10 is critical in avoiding boredom, and if that means 5 to 10 FPS, that's something that's hard to overlook. Steering while flying is difficult and error prone, SETA is easily and non-intentionally broken out of and the entire immersive feeling of the game disappears.

FPS perspective:
Something that adds for example 2000 microseconds of execution time per frame, will reduce framerate from 1000 FPS to 333 FPS. But if your framerate is already down to 100 FPS, it will reduce to 83 FPS. At 60 FPS, it would reduce to 53 FPS. At 20 FPS, it would reduce by less than one frame per second (to 19.2 FPS).

Summary:
To get back considerable performance from TC / AP, I suggest the follow to be good candidates:
1. Find and remove the framerate penalty associated with asteroids, that is not related to generic missions (Removed 4th March 2016)
2. Unless you absolutely have to keep the Escort Convoy and Destroy Convoy missions and am prepared to pretty much rewrite them, just get rid of them. As far as I know, everyone hates them anyways. I've had them permanently disabled in all of my X3 games since 2011.
3. Seriously consider doing whatever it takes to ensure that there is never more than one instance of each generic mission type on offer at a time. This means maximum of one in any sector, and when you swap sector, to offer it again, first remove all traces of the previous instance. It looks like many mission types already behave like this, when quota is set to 1.
4. Fix the cleanup issue with the Mapping Service ships offering surveys.

Edit 4th March 2016: In another thread I used absolute execution time per frame to measure the framerate lowering effect from generic missions. This provided a more accurate picture of what is going on, and shows a greater level of consistency both when adding more instances of same generic mission type, as well as comparative effect between differing generic mission types.