With pathfinding done, I've moved on to adding more features. I'm trying to pace myself until I see what direction the Blender developers are going to take the character animation code.
New stuff done over the last couple of days:
1. Select Commanders and Subs buttons now work. So, you can select an Actor, hit the Get Stats button to load their info, then hit the Select Cmndr button to have Blender select it's commander in the 3D window. This makes it a piece of cake to move up the command heirarchy. Also, Select Subs works now, too, which makes it easy to identify all the troops under a given commander. I'm including a shortcut button that sets an Actor to be it's own commander, giving it autonomy from orders from up the chain of command. Previously, you had to look up with Actors database ID, then set its CommandID to equal this and hit Set Stats. Now, you just hit the CommandSelf button.
2. Effectors. Objects (best used the empties) can be set up as Effectors, which effect (duh) any Actors that come within their radius of influence, as defined by the object's uniform scale. Effectors can be set on all Actors, on a specified team, or on a specified Actor Type. They can be set to change any Actor attribute (health, speed, etc.) by either setting them to a specified value or by performing arithmetic on them (eg. health*.1). Effectors can also make an entry in the Action log for later character animation.
What good are these? Keyframe (or use a script) a boulder flying from a catapult and landing in the middle of an army. Attach an appropriately-sized empty to the boulder and register it as an Effector that reduces any Actor's health to 0 and logs a "Flying Death" action. Wherever the boulder (and empty) hits, it will "kill" the Actors within the empty's radius, and set them up to flail through the air when the "Flying Death" actions you create later are applied.
Or, create an Effector for a "muddy" portion of the battlefield. Set it up to reduce speed to 25% of normal, and log actions for a different bogged down type of walk cycle.
You could even put an Order-changing Effector on an object so Actors retreat when they get near it.
Effectors let the environment have an affect on Actors. Simple, but powerful.
Pathfinding seems to be working correctly now. I've done a little reading and optimizing, and switched the pathfinding list maintanence from the db to internal Python structures. As the algorithm involves a LOT of teeny, rapid transactions, using the db was just way too slow. Calc times dropped by about 80% during the last few rounds of optimizations, so my earlier complaints of SLOOWWWWW are gone. It's not fast now, but it's tolerable.
I wrote the A* pathfinding code today. It's slow. Realllly slow. And it doesn't work right. But it's all in, the basics are sound, and I squashed all the bugs that were making it crash.
Now I just have to troubleshoot my implementation so the thing actually, you know, works correctly. After that, I'll start on optimization.
Wow, it's great to be working with Blenderpeople again.
Tonight, I put in the hooks for A* pathfinding for commanders and selected actors. I also wrote the algorithms and pseudocode for the actual implementation, and I'll code them in tomorrow, if I don't forget my notes in the wrong coat pocket. While doing that, I made a couple of enhancements, including preliminary support for actors who may not be affected by the terrain (flying creatures, ghosts, etc.) It's not full 3D actor support, but it just might look like it. Right now, actors consider themselves only part of a 2D playing field even though they act in 3D space.
I'm also working on fixing the problems people have had with the new MySQL installer that requires a little more involved MySQL configuration. I'll also be doing some speed tests with different configurations - DB hosted on a seperate machine over a fast network - DB and BlenderPeople running on a dual processor machine (I have access to several) - stuff like that so I can make some speed and config recommendations for future users.
Grrrrrr. The MySQL spatial functions like Distance seem to still be placeholders. Nothing really going on there.
But the good news is that I've pulled out BlenderPeople, did updated installations of the supporting packages on my working machines, and have begun to refamiliarize myself with the code in anticipation of Blender's upcoming Character Animation work.
Already, I cut cycle time to less than half, with the SQL experience I've gained since starting this project. So, a turn that was taking 20 seconds to evaluate comes down in something like 8 seconds now. Faster and faster! I'm going to work on optimization (and maybe better pathfinding for commanders) until the character animation hits the runway. I'm also fixing some things that have nagged me from the previous version.
Oooooooo baby. MySQL 4.1 includes Geometry functions. Right now, BlenderPeople is pumping MySQL with all kinds of math to determine Actor spatial relations. This new version of MySQL has optimized functions for just such things. That means extra speed!
The Character Animation proposal I talked about previously is written. You can see it at:
http://www.harkyman.com/animprop/caproposal.htmlIf they can make this stuff happen, I'll be able to write the code for the second pass of BlenderPeople animation. Then we'll see some really cool stuff.
