[Home]History of Skilgannon/PreciseIntersect

Robo Home | Changes | Preferences | AllPages


Revision 7 . . July 2, 2008 18:46 EST by Rednaxela [Layering answer]
Revision 6 . . July 2, 2008 18:23 EST by Skilgannon [thanks! layering question...]
Revision 5 . . July 2, 2008 17:48 EST by Rednaxela [comment]
Revision 4 . . July 1, 2008 17:59 EST by Skilgannon [minor bugfix which could cause bad returned value]
Revision 3 . . (edit) July 1, 2008 14:34 EST by Skilgannon [bugfix]
Revision 2 . . (edit) July 1, 2008 13:23 EST by Skilgannon [caught a bug, speedup]
Revision 1 . . July 1, 2008 13:12 EST by Skilgannon
  

Difference (from prior major revision) (no other diffs)

Changed: 166c166,168
-- Skilgannon
-- Skilgannon

Well, the way I did it should be in effect similar to that. I use a class I call "MovementProfile" that stores overlayed ranges and has a variety of functions for adding/retrieving data from it. See the MovementProfile file in RougeDC's code or [here]. It's a bit messy and not all of the utility functions are actually used currently/anymore but I have them around in case I still need them. The utility functions besides getting the best GF that I am using are mostly there for the purpose of getting data about the profile for my CrowdTargeting weighting system to use (because I don't like VirtualBullets). Basically, it stores a sorted array where each element contains 1) an amount of increase/decrease and 2) The precise GF that increase/decrease occurs at. The reason I store amounts of increases/decreases instead of storing the overall value of an index, is that it makes incrementally adding to the profile far simpler and it's not as if searching for the highest point is much slower. -- Rednaxela

Robo Home | Changes | Preferences | AllPages
Search: