[Bryan See]

While working on high-maneuverability mods such as Shattered Stars, I noticed that the fighters and bombers tend to crash into larger ships while escorting smaller ships that are docked on them. Also, larger ships tend to pass into each other while attacking. These show that the FreeSpace AI needs to be overhauled, refactored and improved, along with the capship AI system, into not only one which is flexible and computationally efficient as Star Citizen's, but also a parallel game AI system.

I believe that OpenCL is the solution that solves the problems aforementioned above. This not only solves performance problems on modern systems, but also opens up a whole opportunity for SCP programmers to improve the game.

While I express an intent of implementing OpenCL and overhauling the FreeSpace AI, others may be interested in doing so. So, I'm putting this up here as I am very sure this will end up - whether it should be implemented in future releases.

[z64555]

mkay.

OpenCL would cover the multi-threading aspect, but that alone won't make FSO's AI instantly better, and probably isn't necessary for most FSO mods and campaigns. Take a look at Star Fox: Event Horizon to see an example that pushes the AI to the edge in terms of entity volume.

With that aside, what are your suggestions for the AI system itself?

[headdie]

Bryan See, AI has been the subject of several lengthy discussions among the SCP both internally and publically with the result ultimately coming down to the fact that any overhaul is going to be a massive undertaking which will need a or several coder(s) willing to be dedicated to the project for a lengthy time frame to make it happen.  Beyond that you then have the question of what form the new AI code will take.

[The E]

OpenCL does not solve AI problems. OpenCL is absolute magic in terms of doing lots of small, parallel jobs, and AI isn't one of those. I'm not saying it can't be done, just that doing so on the severely limited budget we have in terms of personnel isn't going to work out well.

Now, there are areas where the AI could use improvement. Collision avoidance, for instance. But I believe that looking at that particular aspect of it and fixing it is much more likely to result in success than a complete rewrite.

[Bryan See]

To clarify my earlier post, collision avoidance is the thing that I would like to fix. Ships tend to collide it in high-speed, resulting in them exploding.

[z64555]

There was a recent mantis issue resolved concerning AI attackers vs. stationary targets. Try a nightly build after March 18th and see if that resolves it.

[Swifty]

OpenCL is not a good solution for a problem like this. The AI relies heavily on ray casting against mesh triangles. You're going to get killed by how small GPU caches are relative to CPU caches when traversing the BSP data structure.

[Bobboau]

also, last I checked, which was admittedly a few years ago so this might have been solved (please correct me if I'm now wrong on this as I'd love to play with OCL but this has always stopped me), openCL has different binarys depending on which hardware you have, so if you have a nvidia card, you will need to compile a different executable than if you have an ATI card, than if you have intel, than if you have something else like phyx or something, and you can't really mix and match hardwarde.

[Bryan See]

I tried a nightly build, but fighters/bombers still collide with larger ships while possessing high-maneuverability characteristics. I think collision avoidance needs to be improved.

[z64555]

I tried a nightly build, but fighters/bombers still collide with larger ships while possessing high-maneuverability characteristics. I think collision avoidance needs to be improved.

Oh well, it was worth a try.

Would you mind attaching an example of your ship.tbl? "High maneuverability" is too vague, and it would be nice if we had a clear idea of just how fast/agile your craft are. An example of a fighter, a bomber, and a capital ship should be sufficient. 

[pecenipicek]

I tried a nightly build, but fighters/bombers still collide with larger ships while possessing high-maneuverability characteristics. I think collision avoidance needs to be improved.

did you mess around with ship ai classes? If so, you might'be broken it that way too.

[niffiwan]

Eh, FSO is probably completely broken for high speed ships, I've seen too many hardcoded values in the AI behaviour from the little looks I've had at it. Things like "distance to start avoidance" is X metres, not "current speed * desired time to start avoidance". As has already been said, it'll require a lot of effort to implement changes like this including creating the flags to ensure that this behaviour is not on by default (see SCP rule #0). And with anything open source, the best way to get something done that requires a lot of effort is to do it yourself

[Cyborg17]

(see SCP rule #0)

'Tis part of the sacred array of SCP.

[jr2]

Put it in the table and have the table set to retail, and the engine use the retail value if the table value is missing.  Then mods can change it as they see fit.

[mjn.mixael]

Put it in the table and have the table set to retail, and the engine use the retail value if the table value is missing.  Then mods can change it as they see fit.

I suppose you'll be the one to convert each hard-coded value to a table reference, to add code to the parser for a new table and its new flags, and to make sure the table is orderly and makes sense to modders as well? Oh and test and document all your changes? Should be simple, right?

[Phantom Hoover]

There's absolutely no need to be so rude about that, unless of course you're just trying to vindictively scare him off rather than actually encourage him to contribute.

[z64555]

Ok, you guys completely lost me. 

[Spoon]

There's absolutely no need to be so rude about that, unless of course you're just trying to vindictively scare him off rather than actually encourage him to contribute.

That's pretty gold, coming from you.

[AdmiralRalwood]

We wouldn't make a new table, we'd add options to the existing AI tables (which, I'm pretty sure, is what jr2 meant). At its simplest, it could just be a single boolean flag: "uses speed scaling" or some such. Adding fields for every hardcoded value in the AI code would increase the amount of parsing boilerplate to write, but simplify the AI code changes.

[jr2]

Yes, that's what I meant.  And, if every value is configurable in the existing AI table, to simplify, as I said, let the engine basically treat hard coded values as if they were "in the VP" so to speak, in other words, unless overridden by a value in the table, they remain at default, which keeps the required values in the AI table down to a minimum, making it easy to navigate (unless your mod needs to change that many of them, of course -- perhaps have the hard coded value overrides in the last section of the table?).

And, no, I can't program, my apologies.  It's probably going to be at least 4-5 years (2 for my wife to get her RN degree while I continue working, then possibly a year to get into better financial situation, then I go to school, I'm guessing another 2 years before I can sort of contribute something code-wise, assuming I actually have any spare time).