Quote: "I've used AIv2.0 in the past, but it is real speed killer and very buggy for me. The enemies do behave very odd at times."
Considering that the first AI I made I came up without ever using the program (I DID finally take out all the bugs I could find by agressive implementation and encisination of the code into the engine). Actually, I wrote the code on notebook paper durring school ;p. Either way, at the time, it was a good model to base AI structures on...
The bugs are mainly due to shere size and complexity of the code... inorder to compinsate for this the main loop should be the primary script, and others should be executed as external scripts. This insures that each and every state doesn't have to be run through the script executer only to be returned as false.
Finally, use of freestanding plrcanbeseen and settarget are two very bad things.
The code IS NOT optimized to any worthy extent... AI v 2.0 is AI v 1.0 with several bugs removed, several lines of code removed, and a bit of optimization that is ignored.
Quote: "for me it seemed to speed up my games."
Supprising. Ben A's assesment is right... the script undeniably, will cause slowdowns.
Sad to say, my strength never lied in optimization of sourcecode... I just am able to make it.
SideNotes:
Genrally speaking, AI v 2.0's use of activated for commonly used condition-action structures is a vast improvment that I ignored in a later release of the AI... Use of an activated structure can reduce code in complex script structures by 15%, at least.
Another improvement that I consitered, but never implemented, was multiple central command executers, for each programmed for different approachs to the current situation. I did say it is a bad idea to keep the AI stuck in a single state, but the reason for that is people often say (if player is seen, shoot and straft and forget everything else).
Separation of state sets into external FPI files. This will cause a massive increase in speed, proportional to the size of the final file, without the excised state sets, to the size of the inital file. With each script set to return to the main executer which can relay it back to it's inital state... you can do stuff.
Use of the plrcanbeseen command only if you have not rotated to the player recently. For one, linking it with plrdistwithin means it will only execute when the player really 'can' be seen. Further linking to plrhigher means that if the player is too high, it won't execute (unfortunatly there is no plrlower). Settarget is a less complicated algorithm, but it should only be set if the player is 'found', settarget is needed to get bullets to hit the player, so... there.
burnout.
AI v 2.0 might be listed under superenemy or super ai... but it is allways avaliable at my DEAD site.
FPSC Universe
Wisemen are hard to find, they are tarnished by sayings and quotes that are not of their true nature.