• Advertisement

Behavior Needing help understanding GOAP (Brent Owen article) - any pointers?

Recommended Posts

Hey all,

As the heading says I'm trying to get my head around Goal Objective Action Planning AI.  However I'm having some issues reverse engineering Brent Owens code line-by-line (mainly around the recursive graph building of the GOAPPlanner).  I'm assuming that reverse engineering this is the best way to get a comprehensive understanding... thoughts?

Does anyone know if an indepth explanation on this article (found here: https://gamedevelopment.tutsplus.com/tutorials/goal-oriented-action-planning-for-a-smarter-ai--cms-20793), or another article on this subject?

I'd gladly post my specific questions here (on this post, even), but not too sure how much I'm allowed to reference other sites... :|

Any pointers, help or comments would be greatly appreciated.

Sincerely,

Mike

Share this post


Link to post
Share on other sites
Advertisement

In general, understanding an algorithm from reverse engineering code is one of the worst ways. It contains an ocean floor full of details that are needed for the implementation, but they make you get totally lost in finding the one or two key ideas at the surface that bring you safely across the pond.

The other direction is much faster. From the key ideas that you read in articles / papers / presentations, you can see the entire structure and understand the idea at global level. With that understanding you can move code of an implementation into the right spot immediately, since its function in the algorithm is clear already. Code here serves as a reference in how exactly they did some sub-sub-sub step in the algorithm.

An alternative is to write your own implementation after reading the articles / papers, to check that your understanding is correct and complete.

 

 

As for GOAP, the first hit I got is http://alumni.media.mit.edu/~jorkin/goap.html which looks adequate in resources to get you started. I would suggest you read the various descriptions how it works. As usual with complicated algorithms, there is no single solution, but you can vary parts of the algorithm and tailor them to your specific problem.

Once you understand it, go to your own problem (assuming you have one), and try to find out what parts are relevant for your case, and study those in more detail, until you can write an implementation.

Share this post


Link to post
Share on other sites

You guys are brilliant! Many thanks!

Alberth - that link was one I came across as well... but mistakenly thought I should handle the Brent Owens "easy" implementation before looking at the more in depth F.E.A.R. examples (and yes, I did think that was ALL that site was showcasing - that'll teach me to skim read!)

IADaveMark - Jeff Orkin! Brilliant, now I have another name to scour for information regarding.  Many thanks for this.

Again, you're both life savers.  Many thanks.

Hopefully, the next post will be of my triumphing over this challenge - #thenoobknowsnothingofwhatstocome

Share this post


Link to post
Share on other sites
4 hours ago, Tset_Tsyung said:

IADaveMark - Jeff Orkin! Brilliant, now I have another name to scour for information regarding.  Many thanks for this.

What do you think "~jorkin" means in the url I linked? Ie you already have that resource.

I have been looking information too (in particular in robotic context, ie RGOAP), but found very little, much to my surprise. Not sure why that is the case. Perhaps competition from eg Prolog or other methods is too strong?

4 hours ago, Tset_Tsyung said:

#thenoobknowsnothingofwhatstocome

That's always the fun part, you may run into many nice and less nice surprises :)

 

Hope you figure it out.

 

 

Share this post


Link to post
Share on other sites

Just so you know. GOAP isn't all that great for many game AI applications. It suffers from having a harder time with complex environments with many verbs (plan time) and when the game state is very dynamic (frequent replanning). That is, most of the time your long, detailed plans get invalidated by the next think cycle and you have to replan entirely.

Share this post


Link to post
Share on other sites
7 hours ago, IADaveMark said:

Just so you know. GOAP isn't all that great for many game AI applications. It suffers from having a harder time with complex environments with many verbs (plan time) and when the game state is very dynamic (frequent replanning). That is, most of the time your long, detailed plans get invalidated by the next think cycle and you have to replan entirely.

I can see why it doesn't quite work in games. In robotics, time is not that relevant at planning level, state doesn't change often either, while robustness (ie adapting to the environment) is a major problem.

Thanks for the information.

Edited by Alberth

Share this post


Link to post
Share on other sites

Ah, so are you saying that GOAP isn't so great for games?  If that's the case, what would you peeps recommend?

In case you haven't noticed, I'm a noob when it comes to AI... :(

I started reading "Programming Game AI by Example" and in there it mentions the 'State Design Pattern' system. (I stopped reading as I realised that the 'free pdf' was actually a pirate and shouldn't have been free... I'll save up and buy a book instead - recommendations would be appreciated).

Again, many thanks for your replies.

Share this post


Link to post
Share on other sites

What are you trying to implement? AI is not about picking a nifty-sounding algorithm and throwing it at anything and everything under the sun; starting with a solid understanding of the problem you want to solve is key.

Share this post


Link to post
Share on other sites
33 minutes ago, Tset_Tsyung said:

Ah, so are you saying that GOAP isn't so great for games?

We were just discussing some disadvantages of the GOAP algorithm. All algorithms have strong and weak points. As ApochPiQ says, there is no golden bullet that will solve any AI problem you throw at it (if such an algorithm existed, it would be one and only algorithm in the entire AI field).

You normally select an algorithm that has the strong points you need for solving your problem, while at the same time its weak points don't affect you (much).

 

In the end, the proof is in implementing the algorithm, and seeing it in action. Implementing it is also great for educational purposes, hands-on learning works best.

 

Share this post


Link to post
Share on other sites

@ApochPiQ I don't have a major 'project' at the moment.  I was gonna to try to build a basic 'scene' where a blue cube mines for a resource top buy his escape whilst shooting green cubes that come at him (with grabbing better weapons on occasion) just so I could get used to it.  I would like to try a SMALL horror game in the future where the player is hunted by a monster in the woods (listen to player and watches for flashlight).  I was going to use the first 'scene' to practice GOAP with.

Following on from Alberth's latest comment I suppose I could use this simple scene to practice different styles (FSM, State Design Pattern, GOAP, custom-frankensteins-monster-hybrid, whatever.)

Many thanks for all your replies all.  I think I'm gonna just go and experiment/play with different concepts for a bit.  If I get stuck on something more specific you will probably hear from me... but not after extensive google searches first ;)

 

Again, thanks all.

Share this post


Link to post
Share on other sites

Start here:

http://intrinsicalgorithm.com/IAonAI/2012/11/ai-architectures-a-culinary-guide-gdmag-article/

As for a pirated copy of Mat's book, I don't think he cares. We make about a buck (or less) off these books. His publisher may care, though. Anyway, that's the book we recommend first anyway. That or Millington's. 

Share this post


Link to post
Share on other sites
On 7/23/2017 at 11:37 PM, IADaveMark said:

Just so you know. GOAP isn't all that great for many game AI applications. It suffers from having a harder time with complex environments with many verbs (plan time) and when the game state is very dynamic (frequent replanning). That is, most of the time your long, detailed plans get invalidated by the next think cycle and you have to replan entirely.

Why not use GOAP for longer term planning or strategies, and supplement with a different system (like a utility system) for shorter term actions/reactions?

Share this post


Link to post
Share on other sites

Merging architectures based on "time into the future" can sound appealing on paper, but often degenerates into really difficult sub-problems that end up making the whole thing less than ideal.

For example, in your suggested scenario, what happens if I find the utility of an already-formulated plan to be zero? What happens if I plan to do something but ignore its utility? Obviously that's not going to fly, so we have to compromise and integrate utility into the planning heuristics somehow. But now we need to know the utility of future hypothetical gamestates, so all we've really done is complicate both algorithms substantially. The handoff between the two designs is not clear or well defined, meaning that it will be hard to keep the two from polluting each other.

 

This is of course just an off-the-cuff example. When you get into the weeds of blending architectures, it often turns nasty because of this kind of thing. It is actually pretty hard to find disparate architectures that "hand off" well between them in the general case, when you're talking about time into the future blending. If you're lucky and your particular case doesn't have those thorny edges, cool; but otherwise you end up just writing a lot of special case hacks and workarounds that don't really suit the goal of getting the game done.

Layered architectures are a different thing. That's where you have a system that controls the fine-grained details and one or more additional systems that control the big picture stuff. They are designed to feed data back and forth, and to cooperate. Layering is a good thing and used all the time for things like strategy-vs-tactics distinctions, for example.

 

Occasionally there are architectures that work well across the "time into the future" spectrum. For example, utility architectures can be set up to do partial planning with some careful forethought. When you have a single solution for a wide range of problems, it's much more appealing to use that solution generally than to try and wire together a bunch of special cases.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Advertisement
  • Advertisement
  • Popular Tags

  • Advertisement
  • Popular Now

  • Similar Content

    • By ChaosEngine
      I've been interviewing a few job candidates recently. I wrote a short list of what I could consider pretty basic C# questions for them. My intention with these questions was to use them as a jumping off point for more interesting discussions, but so far, people have struggled to answer them. So I thought I'd post them here to get some feedback from people.
      Basically, am I expecting too much? These are pitched at mid-senior developer level.
       
      All feedback much appreciated.
      Technical Interview questions.pdf
    • By 3dmodelerguy
      So I am building a turn based rogue-like (think CDDA). The game is going to have a very large map (up to 1000's x 1000's) however to alleviate most of that I obviously can't render everything so there will just be render a certain radius around the player and just load in and out data as the player moves.
      The next major system I am prototyping is making interactive tiles destructible and pretty much everything will be destructible besides basic landscape (cars, doors, windows, structures, etc. will be destructible)
      While I am only rendering a certain amount of tiles around the player, I want to keep the amount of colliders active at one time to be as small as possible for performance and currently the tilemap tool I use automatically merges colliders together.
      So instead of creating a separate colliders for each of these tiles and having the destructible behavior tied to that object (which my tilemap tool would allow me to do) I was thinking that I would store an array of all the X and Y locations for the interactive tilemap layer and let the tilemap manage the colliders. 
      Then when I hit a collider on the interactive tilemap layer, instead of of getting the behavior for how to deal with the destruction for that tile from that game object, I would pull it from the array I mentioned earlier based on the tile I attempt to interact with which I already have.
      Does this sound like a good approach? Any other recommendations would be welcomed.
    • By B. /
      Hello Everyone,
      I write COLLADA Importer and my next goal was to import rigged Characters, so check up the file ,but don't understand one step. I see where the joints and the weigts are, but not where the file say which vertex has which weight. So maybe you guys can help me and explain it?
      <vertex_weights> has only the indices of the joints and weights
      Here's a part of my COLLADA file:
      <library_controllers> <controller id="pCube1Controller"> <skin source="#pCube1-lib"> <bind_shape_matrix>1.000000 -0.000000 0.000000 0.000000 0.000000 1.000000 -0.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 0.000000 1.000000 </bind_shape_matrix> <source id="pCube1Controller-Joints"> <Name_array id="pCube1Controller-Joints-array" count="18"> Hip LegL FootL ToeL LegR FootR ToeR Belly ShoulderR ArmR HandR FingerR ShoulderL ArmL HandL FingerL Neck Head</Name_array> <technique_common> <accessor source="#pCube1Controller-Joints-array" count="18"> <param type="name"/> </accessor> </technique_common> </source> <source id="pCube1Controller-Matrices"> <float_array id="pCube1Controller-Matrices-array" count="288"> -0.941340 -0.337461 -0.000000 -0.139955 -0.337461 0.941340 -0.000000 0.371721 0.000000 -0.000000 -1.000000 -0.000000 0.000000 0.000000 0.000000 1.000000 -0.248803 -0.968554 -0.000000 -0.585359 -0.968554 0.248803 -0.000000 -0.201095 0.000000 0.000000 -1.000000 0.000000 0.000000 0.000000 0.000000 1.000000 -0.034984 -0.999388 -0.000000 -1.221391 -0.999388 0.034984 -0.000000 -0.474481 0.000000 0.000000 -1.000000 0.000000 0.000000 0.000000 0.000000 1.000000 1.000000 -0.000000 0.000000 0.541746 0.000000 1.000000 0.000000 1.913253 -0.000000 -0.000000 1.000000 -0.000000 0.000000 0.000000 0.000000 1.000000 -0.248802 0.968554 0.000000 0.585358 -0.968554 -0.248802 -0.000000 0.201094 -0.000000 -0.000000 1.000000 0.000000 0.000000 0.000000 0.000000 1.000000 -0.034983 0.999388 0.000000 1.221387 -0.999388 -0.034983 -0.000000 0.474481 -0.000000 -0.000000 1.000000 0.000000 0.000000 0.000000 0.000000 1.000000 1.000000 -0.000001 0.000000 -0.541746 -0.000001 -1.000000 -0.000000 -1.913249 0.000000 0.000000 -1.000000 0.000000 0.000000 0.000000 0.000000 1.000000 0.043672 0.999046 0.000000 -0.000137 -0.999046 0.043672 -0.000000 0.003133 -0.000000 -0.000000 1.000000 -0.000000 0.000000 0.000000 0.000000 1.000000 -0.995861 0.090881 -0.000000 -0.021829 -0.090881 -0.995861 -0.000000 0.184414 -0.000000 -0.000000 1.000000 -0.000000 0.000000 0.000000 0.000000 1.000000 -0.987330 0.158679 -0.000000 0.470613 -0.158679 -0.987330 -0.000000 0.217060 -0.000000 -0.000000 1.000000 -0.000000 0.000000 0.000000 0.000000 1.000000 -1.000000 0.000001 -0.000000 1.419031 -0.000001 -1.000000 -0.000000 -0.008213 -0.000000 -0.000000 1.000000 -0.000000 0.000000 0.000000 0.000000 1.000000 -0.941340 0.337462 -0.000000 1.988030 -0.337462 -0.941340 -0.000000 0.703965 -0.000000 -0.000000 1.000000 -0.000000 0.000000 0.000000 0.000000 1.000000 -0.995861 -0.090881 -0.000000 0.028074 -0.090881 0.995861 0.000000 -0.183843 0.000000 0.000000 -1.000000 -0.000000 0.000000 0.000000 0.000000 1.000000 -0.987330 -0.158678 -0.000000 -0.464421 -0.158678 0.987330 0.000000 -0.216064 0.000000 0.000000 -1.000000 -0.000000 0.000000 0.000000 0.000000 1.000000 -1.000000 -0.000000 -0.000000 -1.412754 -0.000000 1.000000 0.000000 0.008213 0.000000 0.000000 -1.000000 -0.000000 0.000000 0.000000 0.000000 1.000000 -0.941340 -0.337462 -0.000000 -1.982131 -0.337462 0.941340 0.000000 -0.701850 0.000000 0.000000 -1.000000 -0.000000 0.000000 0.000000 0.000000 1.000000 0.043673 0.999046 0.000000 -0.483504 -0.999046 0.043673 -0.000000 -0.018032 -0.000000 -0.000000 1.000000 0.000000 0.000000 0.000000 0.000000 1.000000 0.043673 0.999046 0.000000 -0.963774 -0.999046 0.043673 -0.000000 -0.039026 -0.000000 -0.000000 1.000000 0.000000 0.000000 0.000000 0.000000 1.000000</float_array> <technique_common> <accessor source="#pCube1Controller-Matrices-array" count="18" stride="16"> <param type="float4x4"/> </accessor> </technique_common> </source> <source id="pCube1Controller-Weights"> <float_array id="pCube1Controller-Weights-array" count="534"> 1.000000 0.446680 0.448446 0.061039 0.006715 0.037120 0.423137 0.341108 0.035586 0.104220 0.095948 0.430593 0.105918 0.018535 0.346667 0.098287 0.446679 0.037120 0.448446 0.061040 0.006715 0.163148 0.388913 0.396025 0.037444 0.014469 0.396151 0.187946 0.014532 0.076902 0.324469 0.394204 0.076828 0.187766 0.328622 0.012580 0.166741 0.388259 0.393852 0.036607 0.014542 0.108793 0.424549 0.424576 0.021527 0.020555 0.255692 0.255431 0.312440 0.153135 0.023302 0.258375 0.311167 0.149047 0.258097 0.023313 0.102002 0.388360 0.388353 0.019283 0.102002 0.174648 0.125476 0.307658 0.306598 0.085620 0.287311 0.159158 0.174218 0.287850 0.091463 0.288312 0.172606 0.159037 0.288857 0.091188 0.177388 0.305490 0.303861 0.126946 0.086316 0.120822 0.069144 0.387268 0.384055 0.038711 0.422697 0.058575 0.073700 0.426612 0.018416 0.426332 0.069409 0.056317 0.430430 0.017513 0.124944 0.385012 0.380074 0.070711 0.039259 0.120822 0.069144 0.387268 0.384055 0.038711 0.422697 0.058575 0.073700 0.426612 0.018416 0.426332 0.069409 0.056317 0.430430 0.017513 0.124944 0.385012 0.380074 0.070711 0.039259 0.174648 0.125476 0.307658 0.306598 0.085620 0.287311 0.159158 0.174218 0.287850 0.091463 0.288312 0.172606 0.159037 0.288857 0.091188 0.177388 0.305490 0.303861 0.126946 0.086316 0.108793 0.424549 0.424576 0.021527 0.020555 0.255692 0.255431 0.312440 0.153135 0.023302 0.258375 0.311167 0.149047 0.258097 0.023313 0.102002 0.388360 0.388353 0.019283 0.102002 0.163148 0.388913 0.396025 0.037444 0.014469 0.396151 0.187946 0.014532 0.076902 0.324469 0.394204 0.076828 0.187766 0.328622 0.012580 0.166741 0.388259 0.393852 0.036607 0.014542 0.446680 0.448446 0.061039 0.006715 0.037120 0.423137 0.341108 0.035586 0.104220 0.095948 0.430593 0.105918 0.018535 0.346667 0.098287 0.446679 0.037120 0.448446 0.061040 0.006715 0.490897 0.501024 0.005129 0.002609 0.780985 0.201682 0.001639 0.008414 0.007279 0.783532 0.008348 0.200106 0.007322 0.490896 0.002609 0.501024 0.005129 0.490897 0.501024 0.005129 0.002609 0.780985 0.201682 0.001639 0.008414 0.007279 0.783532 0.008348 0.200106 0.007322 0.490896 0.002609 0.501024 0.005129 0.072569 0.448896 0.467547 0.008240 0.002747 0.072569 0.448896 0.467547 0.008240 0.002747 0.005633 0.494163 0.494079 0.005633 0.005633 0.494163 0.494079 0.005633 0.069536 0.447783 0.471519 0.008441 0.002721 0.069536 0.447783 0.471519 0.008441 0.002721 0.005428 0.496654 0.496927 0.005428 0.496654 0.496927 0.027277 0.465805 0.466166 0.034322 0.006429 0.032529 0.465155 0.458960 0.027694 0.015662 0.001002 0.524597 0.473182 0.002078 0.496491 0.498270 0.002770 0.015604 0.487493 0.476849 0.013049 0.007005 0.014109 0.482061 0.482639 0.018164 0.003027 0.086141 0.395004 0.392832 0.076562 0.049460 0.072924 0.408978 0.409117 0.086668 0.022313 0.025344 0.009121 0.470943 0.470334 0.024259 0.034082 0.007470 0.455706 0.456255 0.046487 0.007387 0.001314 0.489449 0.491035 0.010816 0.510801 0.489110 0.021297 0.004277 0.471874 0.472667 0.029885 0.010295 0.003391 0.488816 0.487692 0.009806 0.075808 0.021321 0.403240 0.403478 0.096154 0.078335 0.035448 0.405277 0.405075 0.075866 0.101905 0.429125 0.429095 0.016145 0.023730 0.099890 0.407814 0.407384 0.030245 0.054666 0.023975 0.481476 0.479747 0.004706 0.010096 0.023316 0.485651 0.485533 0.002137 0.003363 0.001426 0.503487 0.494347 0.001458 0.499436 0.498840 0.023912 0.481531 0.479799 0.004692 0.010066 0.023254 0.485691 0.485573 0.002130 0.003352 0.023299 0.039289 0.097061 0.420322 0.420031 0.016873 0.022080 0.108912 0.426068 0.426067 0.003085 0.004216 0.033460 0.479621 0.479618 0.002649 0.005089 0.018149 0.487709 0.486404 0.007248 0.495761 0.495752 0.515491 0.484439 0.003078 0.004206 0.033395 0.479662 0.479659 0.002639 0.005071 0.018089 0.487755 0.486447 0.001437 0.495838 0.497206 0.005199 0.001437 0.495838 0.497206 0.005199 0.002118 0.498222 0.493106 0.006148 0.002118 0.498222 0.493106 0.006148 0.001407 0.494389 0.498501 0.005388 0.001407 0.494389 0.498501 0.005388 0.002075 0.495166 0.495968 0.006390 0.002075 0.495166 0.495968 0.006390 0.001348 0.499290 0.499290 0.001654 0.029342 0.484184 0.484184 0.001867 0.499012 0.499012 0.001874 0.030698 0.483368 0.483368 0.001352 0.499287 0.499287 0.001642 0.028780 0.484473 0.484473 0.001859 0.030111 0.483671 0.483671 0.001863 0.499013 0.499013 0.017793 0.003436 0.003494 0.487638 0.487638 0.016776 0.003258 0.003214 0.488376 0.488376 0.016776 0.003258 0.003214 0.488376 0.488376 0.017793 0.003436 0.003494 0.487638 0.487638 0.080146 0.034481 0.036694 0.424340 0.424340 0.079527 0.036205 0.034127 0.425070 0.425070 0.079527 0.036205 0.034127 0.425070 0.425070 0.080146 0.034481 0.036694 0.424340 0.424340 0.106011 0.033886 0.040327 0.409888 0.409888 0.104594 0.039175 0.033170 0.411531 0.411531 0.104594 0.039175 0.033170 0.411531 0.411531 0.106011 0.033886 0.040327 0.409888 0.409888</float_array> <technique_common> <accessor source="#pCube1Controller-Weights-array" count="534"> <param type="float"/> </accessor> </technique_common> </source> <joints> <input semantic="JOINT" source="#pCube1Controller-Joints"/> <input semantic="INV_BIND_MATRIX" source="#pCube1Controller-Matrices"/> </joints> <vertex_weights count="116"> <input semantic="JOINT" offset="0" source="#pCube1Controller-Joints"/> <input semantic="WEIGHT" offset="1" source="#pCube1Controller-Weights"/> <vcount>5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 4 5 4 4 4 5 4 4 5 5 4 4 5 5 3 3 5 5 3 4 5 5 5 5 5 5 5 2 5 5 5 5 5 5 5 5 3 3 5 5 5 5 5 5 3 2 5 5 4 4 4 4 4 4 4 4 3 4 3 4 3 4 4 3 5 5 5 5 5 5 5 5 5 5 5 5</vcount> <v>0 1 1 2 2 3 3 4 4 5 0 6 1 7 2 8 4 9 7 10 0 11 1 12 2 13 4 14 7 15 0 16 1 17 4 18 5 19 6 20 7 21 12 22 13 23 14 24 17 25 0 26 1 27 2 28 4 29 7 30 0 31 1 32 4 33 7 34 17 35 7 36 8 37 9 38 10 39 17 40 7 41 12 42 13 43 14 44 17 45 7 46 8 47 12 48 13 49 17 50 7 51 8 52 9 53 12 54 17 55 7 56 8 57 9 58 10 59 12 60 7 61 8 62 12 63 13 64 17 65 7 66 8 67 12 68 16 69 17 70 7 71 8 72 12 73 16 74 17 75 7 76 8 77 9 78 12 79 17 80 7 81 8 82 12 83 13 84 17 85 7 86 8 87 12 88 16 89 17 90 7 91 8 92 12 93 16 94 17 95 7 96 8 97 9 98 12 99 17 100 7 101 8 102 12 103 13 104 17 105 7 106 8 107 12 108 16 109 17 110 7 111 8 112 12 113 16 114 17 115 7 116 8 117 9 118 12 119 17 120 7 121 8 122 12 123 13 124 17 125 7 126 8 127 12 128 16 129 17 130 7 131 8 132 12 133 16 134 17 135 7 136 8 137 9 138 12 139 17 140 7 141 12 142 13 143 14 144 17 145 7 146 8 147 12 148 13 149 17 150 7 151 8 152 9 153 12 154 17 155 7 156 8 157 9 158 10 159 12 160 7 161 12 162 13 163 14 164 17 165 0 166 1 167 2 168 4 169 7 170 0 171 1 172 4 173 7 174 17 175 7 176 8 177 9 178 10 179 17 180 0 181 1 182 2 183 3 184 4 185 0 186 1 187 2 188 4 189 7 190 0 191 1 192 2 193 4 194 7 195 0 196 1 197 4 198 5 199 6 200 0 201 1 202 2 203 4 204 0 205 1 206 2 207 4 208 7 209 0 210 1 211 4 212 7 213 0 214 1 215 4 216 5 217 0 218 1 219 2 220 4 221 0 222 1 223 2 224 4 225 7 226 0 227 1 228 4 229 7 230 0 231 1 232 4 233 5 234 7 235 8 236 9 237 10 238 17 239 7 240 8 241 9 242 10 243 17 244 7 245 8 246 9 247 12 248 7 249 8 250 9 251 12 252 7 253 12 254 13 255 14 256 17 257 7 258 12 259 13 260 14 261 17 262 7 263 12 264 13 265 7 266 12 267 13 268 0 269 1 270 2 271 3 272 4 273 0 274 1 275 2 276 3 277 4 278 0 279 1 280 2 281 0 282 1 283 2 284 3 285 0 286 1 287 2 288 3 289 4 290 0 291 1 292 2 293 3 294 4 295 0 296 1 297 2 298 3 299 4 300 0 301 1 302 2 303 3 304 4 305 0 306 1 307 4 308 5 309 6 310 0 311 1 312 4 313 5 314 6 315 0 316 1 317 4 318 5 319 6 320 4 321 5 322 0 323 1 324 4 325 5 326 6 327 0 328 1 329 4 330 5 331 6 332 0 333 1 334 4 335 5 336 6 337 0 338 1 339 4 340 5 341 6 342 1 343 2 344 3 345 4 346 6 347 1 348 2 349 3 350 4 351 6 352 1 353 2 354 3 355 4 356 6 357 1 358 2 359 3 360 4 361 6 362 1 363 2 364 3 365 1 366 2 367 3 368 1 369 2 370 3 371 4 372 6 373 1 374 2 375 3 376 4 377 6 378 1 379 3 380 4 381 5 382 6 383 0 384 3 385 4 386 5 387 6 388 0 389 3 390 4 391 5 392 6 393 1 394 3 395 4 396 5 397 6 398 4 399 5 400 6 401 5 402 6 403 0 404 3 405 4 406 5 407 6 408 1 409 3 410 4 411 5 412 6 413 8 414 9 415 10 416 11 417 8 418 9 419 10 420 11 421 8 422 9 423 10 424 11 425 8 426 9 427 10 428 11 429 12 430 13 431 14 432 15 433 12 434 13 435 14 436 15 437 12 438 13 439 14 440 15 441 12 442 13 443 14 444 15 445 9 446 10 447 11 448 8 449 9 450 10 451 11 452 9 453 10 454 11 455 8 456 9 457 10 458 11 459 13 460 14 461 15 462 12 463 13 464 14 465 15 466 12 467 13 468 14 469 15 470 13 471 14 472 15 473 7 474 8 475 12 476 16 477 17 478 7 479 8 480 12 481 16 482 17 483 7 484 8 485 12 486 16 487 17 488 7 489 8 490 12 491 16 492 17 493 7 494 8 495 12 496 16 497 17 498 7 499 8 500 12 501 16 502 17 503 7 504 8 505 12 506 16 507 17 508 7 509 8 510 12 511 16 512 17 513 7 514 8 515 12 516 16 517 17 518 7 519 8 520 12 521 16 522 17 523 7 524 8 525 12 526 16 527 17 528 7 529 8 530 12 531 16 532 17 533</v> </vertex_weights> </skin> </controller> </library_controllers> Greets
      Benjamin
  • Advertisement