anyone who's ever played rising force online might attest to the dumbness of their AI   but the internals are actually pretty complex.  Setting all of their triggers for the dev is the bugger. 

Static AI is easier in the sense of stand in your spot and then react, don't necessarily act independentently.  Wont go into their full stats but its like...

Radius in which you spawn from your origin point.
Speed you walk when "idle", speed you walk in "agro" mode (move, WarMove)
Speed (im ms + or - some randomosity) at which you will agress an opponent (opponents are set via player flags per race, or flagged against all player races)
Will you help a fellow monster?
Will you call for help if you need it?
At what points are you "in trouble"? (based on hitpoints, ranges from "Goodtookay, okaytobad, badtoworse, wierd flags like that)
What will you cast/do to your primary target at each point at what percentage?
What will you cat/do to ANY opponent if they do any of the following (skills defined at 4 letter/number combos)
What will you SAY at certain points (helping a 'friend'? BadToWorse? A curse spell cast on you? Randomly during the fight? When you use a certain skill?)
... then plus your base stats (an F-ton of those too, as complex as the player, which doesn't even look so complex from the client UI).

I wanted to learn to program AI's in an existing system, did so...  and had to walk away burned out until I can finally crawl back weeping.    They're a pain   Specially when you need like 300 individual special complex ones in a month.  A programmers' head (dev-y types) can wrap around them easy enough but the mroe comlpex they are.. and even those are simple, the less of them you can have active on a map... (processing power serverside)...

----
I play MMOs. I need a signature which is deep, thought provoking, and devours bandwidth with the voracity of rabid weasels. It is also, by nature, vaguely sad with a tinge of my obvious internal, unfathomable loneliness. Like this,   , but at 1.3megs packed into 2 by 6 inches. ANIMATED.

I recall there being some mention about that.  AI can be remarkably inefficient, but planning and implementation of the design can hide a large number of processor efficient shortcuts that are scripted responses vs building a complex AI code.  Also, once done right, modularity makes it possible to reapply it elsewhere or sell it for profits.

Also, the PS3's processors are pocket calculators with tiny hidden monkies inside these days.  It's commonly known that their cell processors are a pain in the behind to use efficiently.  Nevermind the simple lack of raw horsepower relative to anything modern.

I know I'm opening a can of worms with that comment and someone will say "But look at how it runs modern games so well, you ***!"  To head that thought off at the pass consider how much money is at stake in the console market versus the PC gaming market and you'll see that modern games target current generation consoles with system requirements to allow greater sales.  Developers have little to no economical incentive to make use of modern PC hardware that has long since marched forward.

That's true for any code.  More lines = more complexity = more stupid bugs & unintended effects.  That's no reason not to bother writing it if budget constraints permit it to be so.

Speaking of idiot AI...Star Wars: Battlefront stands out in my mind as a massive failure.  Let's take an already stupid Battlefield 1942 AI and change the weapon/vehicle dynamics, add difficult (for the existing AI) terrain, and then do nothing to make the bots more aware of their own capabilities.

Of course. In the end it's about building and destroying sandcastles. In Perpetuum more literally than other sandboxes, apparently

This is always an interesting read (something to hold against the light after each patch):

http://www.perpetuum-online.com/Media:Manifesto

Oh gawd you were scripting weren't you. If you're using a classless scripting language you are in for a world of hurt. Blah blah blah includes; screw that, I'd rather create a class that handles the general case and set up constructors to initialize with defaults, then just generate that in each instance of the NPC. 

Problem solved and probably how problem is dealt with here. I don't want to hear about your effing structs you C freaks, it's not a class so stfu. 

The annoying part is teaching the AI to use a map. Some games do that by dynamically judging terrain and calculating los for a range of current and potential positions (this is where  stuff like "rays" is going to get tossed around, you do not want to know and it is not easy to implement) -- the faster things are changing position, the more expensive this gets, but it's never cheap in a real time game.

The other option is static scripting for locations, which is functionally impossible in an open environment like Perp's where the devs cannot predict the position of the player by map layout (but it's also generally a lot cheaper). It works great in games where you've got lots of static cover and a single entry point, but the greater the range of potential entry points the less utility this method will provide.

So the optimal solution for a dev that A) does not have a lot of time/cash to throw at the solution B) needs a cheap solution processor wise and C) is generally viable is ignoring terrain except when it comes between the NPC and the human, at which point the NPC calculates a shortest path to "remove" the obstacle and then goes back to the headlong charge (until a script gets triggered by a state change).

Which really brings you to the nut of the problem. The vast majority of player perceptions about the AI have to do with how well it navigates a given map, uses cover and works with its amigos. MMO AI will never (at least, never in a reasonable time frame) do any of those three things because they all depend on the map and require extensive calculation or a reduction in potential player entry points to PVE areas.

What the devs CAN do is create spawns built to look like a player gang. So high speed assaults with tackle and short range guns, long range mechs with RR support, etc etc. They sort of have this with roaming spawns. The other thing they can do is use a swarm model (note: a real swarm uses hordes of agents to generate a single solution, this is more of an overlord model, whatevskies) instead of a per bot script. So, a single script generates a solution that gets mild randomization when applies to each bot. That's create a perception that the bots are FFing players and moving (mostly) as a unit, with some of them not following primary or separating from the group. It'd also help if bots checked to switch targets if (enemySpeed > ownSpeed && enemyRange > ownRange && !(tackle == true)). Right now I build threat while range tanking against a hauler spawn, bugger off at high speed and then our green bots roll up with compacts and annihilate. 

The gist of it is that you won't get what you want wrt smarter bots and cover, but a couple things could be done to make the situation more entertaining.

There has got to be some simple(r) stuff you could do prior to any of the bots even spawning. Like what Aeon mentioned about giving the groups a more tactical squad composition. You could watch player traffic maybe, and have indies only spawn in low traffic spots (so they stop spawning there if they become a farm target) and maybe some attack spawns target high traffic areas (sometimes you'll need to shake them off at the terminal or on the highway).

I don't even really have a problem with how the AI actually fights. The little bots seem un-terrible at knowing their role and keeping distance or finding cover. I dislike that their tendency to just stand around in groups waiting to die screams "I'm a ***!" and tears apart anything the lore claims about their advanced society or whatever. Of course, if players would group up as predictably, we could get some serious pew going...

If they are shepard robots they do.

respawning defies any kind of explaination, but's a required game mechanic or the world would be empty quickly.

same supsension of disbelief for why they are there in the first place.

I've done this though exercise while working on another project. with suspended disbelief, we know it doesn't make sense but its ok because it doesn't have to, trying to make it persistant you end up creating a scenerio where it starts to feel forced. forced reasons to have npcs make worse game play then suspended disbelief.