31 replies to this topic

[Phoenix Rising]

I think the crashes in galactic conquest have something to do with the AI as the AI doesn't seem to work on the mod after I redownloaded it.

No, it's definitely bombing runs. If the AI doesn't work, it's something you did - I've told people how to fix it about 20 times and it still happens.

[anakinskysolo]

I just had an exception during a bombardment, and every time they do it, it's the same. I know it because I saved it just before their bombardment. Maybe its related to the bombing runs somehow.

[A1Dasdfsdkli4r2]

Could you tell me which bombers you had in orbit? Also any carriers. Or rather, test it with different bombers and find out which one does it, because I've gotten runs to work fine, but I'm not sure if I tested them all.

For me the only problems arise when I have skipray blastboats up an no built Tie Bombers.

[AnesaH]

PR,

I've made the modifications, and it looks like bombing runs aren't the culprit for my crashes. This line of thinking is continued in another thread at the top of the bug forum now, I'll follow that from now on.

Thanks for continuing ^^

[kylekatarn288]

Could you tell me which bombers you had in orbit? Also any carriers. Or rather, test it with different bombers and find out which one does it, because I've gotten runs to work fine, but I'm not sure if I tested them all.

For me the only problems arise when I have skipray blastboats up an no built Tie Bombers.

okay, as Pheonix said, its the <Ship_Class> tag. We ran into this problem also, but only with the Skipray Blastboat. i dont know why, as when the B-Wing has no run, its classified as a bomber as well, but causes no crash. I think it may have something to do with the fact that in the vanilla game, its a bomber, because its the only one that didnt work. changing its class to a fighter should fiix the Skipray crash, though it changes its accuracy sets and targeting priorities.

[Phoenix Rising]

I thought accuracy and targeting priorities were controlled by <CategoryMask>... So any idea what that does exactly?

You logic with the Skipray makes sense, but I've renamed it from FoC, so I'm not sure how it would still know it's the same.

[kylekatarn288]

yeah, this confuses me greatly... i really dont know why this happens solely to the skipray.
i think <category_mask> may control similar functions, i really dont know either...
there needs to be acompiled database for EaW tags... that would really help coders clean up code, and think of new ideas.

[Phoenix Rising]

I've been pushing for a Wiki forever, but I don't really know where to turn to as far as a host.

[Zarkis]

Since you are on it, what exactly does <is_escort>yes/no</is_escort> do? I noticed in vanilla all fighters and fighting ships below the capital level have this tag set to yes. In the escortplan.lua only fighters and the Interdictor are specified as escorts, so I guess the script and the tag have nothing to do with each other. In PR even capital ships have the tag set to yes. I wonder if this has a detrimental effect on the tactical AI, and would advice to follow the vanilla settings and set capitals, bombers and non-fighting ships not to escort as long as we don't have a clue what it does.

[Dalmp]

Since you are on it, what exactly does <is_escort>yes/no</is_escort> do? I noticed in vanilla all fighters and fighting ships below the capital level have this tag set to yes. In the escortplan.lua only fighters and the Interdictor are specified as escorts, so I guess the script and the tag have nothing to do with each other. In PR even capital ships have the tag set to yes. I wonder if this has a detrimental effect on the tactical AI, and would advice to follow the vanilla settings and set capitals, bombers and non-fighting ships not to escort as long as we don't have a clue what it does.

I'm betting that is why fighters grouped with bombers will stay together when you move them as a unit (moving forward then stopping, then moving again, then waiting..), but when grouping two different kinds of fighters together with nothing else in the group, they move at different speeds and paces. Same deal with ships. They always fly all together at the same speed when grouped with a capship.

I'm guessing it's a flag that says 'when moved as a group, match the pace of the slowest <is_escort>no</is_escort> entity'.

Just a wild guess, but I don't know of any other tags that explain why fighters only stick together when there's bombers in the group, and ships only stick together when there's a capship present. I don't have a guess for why escortplan.lua is at odds with the tag. But if the guess is right, then certainly it should be set to no for capships and bombers, to keep the AI massing it's forces, instead of charging them in separately. Actually, that might explain why the AI does exactly that, knowing that capships in PR are set to 'yes'.

Edited by Dalmp, 28 January 2008 - 08:20 PM.

[Zarkis]

Very good observations. Makes sense.

[Phoenix Rising]

Yeah, I threw out all preconceptions I had about those three tags when I realized that <Is_Bomber> doesn't actually control bombing runs, hence the exceptions. So, yeah, good spot, Dalmp; I guess I've got some updating to do.