Deprecated Darkstar fourms

I kinda screwed up my usual character on DS so I started another non-GM character. I started in San d'Oria. I was hitting very low level mobs in West Ronfaure and I noticed something; the rabbits hop. They don't go very far, just one or two hops, but they DO hop I know that I'm not really qualified to be giving design advice. I have an associates degree in Computer Science, which amounts to almost nothing in real world, but consider this:

Option 1:

Define a range that a mob can move in. It can cross the paths of other mobs, it just can't move out of it's range.

Option 2: (Which I actually prefer)
Pick a random direction
Pick a random number of movements in that direction
Execute move. If moving mob encouters and obstacle (a tree, a building, etc. etc) stop immediately.
Stop (for a predetermined amount of time.)

Now, there's probably some packet magic that makes what I've suggested impossible, otherwise you devs would have thought of it and implemented it before now. I'm thinking that you're just overthinking this solution. Like Edgar Allan Poe's famous detective Dupan always said, "The hardest place to find anything is in plain sight...".

When I first found this project in July, 2012, there were three main problems that I saw:

1. Mobs didn't move.
2. Mobs don't cast magic
3. No weather.

The weather problem has been dealt with AFAIK. The mob magic problem shouldn't be too hard to deal with. I think most of what you need is already in the DB. Some animation IDs might need to be found, but otherwise, you know what job class most mobs resemble, and you know what spells that job can cast at a particular mob's level.

Both options are limited by the fact that the server side has zero terrain awareness. There is no way for a mob to know it hit a rock/wall/tree at all. There is a plan for adding in terrain awareness, but it is not as simple as you may think.

Mob magic is also not quite so simple. Mob AI has to be reprogrammed to allow for casting. Sure telling the mobs what spells are available to them, how much mp they have left etc...is easy, but telling them WHEN it is appropriate to cast and when they should just beat on you with a stick is a lot more complicated. Especially when you take the plethora of status effects into account.

Generate a random number; either 0 or 1.
If the number is 0, use normal melee attacks.
If the number is 1, call a subroutine that chooses a spell.

Just make sure that the number 1 also starts a timer that number 1 can't be chosen again until the time goes off...

ehh...that's not very accurate to retail. Also you need to take the timer cycle into effect, whether they can legitimately use any spells (not silenced, out of mp, or all recast times still active) and such. Your oversimplification of the problem would never make it into the svn.

Some mobs spam spells under certain circumstances, most mobs with buffs will buff themselves/friendlies right after spawning, etc.

And I know the project is aiming for retail, but please, PLEASE, don't include the silly crap like a mob casting Silena on itself right after Silence wears lol

I think the goal should be better than retail. Ever since I started playing FFXI in 2008, my opinion of SE has been falling. At this point, they're status with me is barely above Microsoft. I decided long ago that while Squresoft was decent at designing games, Square Enix couldn't design a good game to save their lives.

It is open source, if you want to program in a snippet that allows for mobs to randomly move around and clip through the terrain, the resources are available to you.

I can't speak for the developers of this project but I think bluekirby0 makes it clear that the goals are centered around emulating retail. I see the issue with having svn's that include updates that aren't actually updates, too many "works for now" features can discourage looking for and implementing real solutions on both testing and development sides.

Exactly. If we don't take a stance and stick to it, the code can easily become a chaotic mess of patches people implement of "close, but not quite" features. I'd rather keep things like that to external patches and out of the svn to save us headaches later when it comes time to get something working correctly. That said, things that are "partially working" and can be extended to full functionality are candidates, but not things that have a basic inherent design flaw that prevents it from being extended to work properly.