Inactive Candy Stuff

[overdhose]

yeah listen if I would make something like this, it will look a LOT worse then whatever you make from it, trust me ; ). Just something similar to attack but with a tool of your choice is more then enough to toy around with, even if it won't win beauty contest... if not, I'll use the attack anim

 

[glutamatkrieger]

Ok i have an Idea, i edit this post later on with Updates and hopefully a full working Modjar
Many Greets

 

[overdhose]

rolling out a red carpet also takes time, at this rate I won't even have enough carpet

 

[glutamatkrieger]

By the mighty hammer of Thor !

 

[glutamatkrieger]

The Standalone Oreo Modfile https://docs.google.com/folder/d/0B8Kq9XFiF6gxYjdMY2x1bXk2bXM/edit
Many Greets

 

[Cervator]

overdhose - Oooohhh so that's what you meant with pony. The little splotchy color blob icons ... right! Hehe

Definitely would like to see icons per-module. Probably not too hard, if it doesn't already work? Assets are supported for modules after all. Maybe we need to be able to splice the textures together at runtime for some graphic wizardry demands?

Maternal - still love the Oreos. The "shake" animation made me wonder what happens if an Oreo falls into water ...

The dance party makes me want to see Oreo spearmen in phalanx formation defending against heavy cavalry

 

[overdhose]

hey I resent that... i make fun if my own shortcomings, no need to throw some oil on that fire.

Anyway the oreos are easier to draw, and I plan to make a seperate book where you can try every animation as "emotes" for aselected oreo. Yes, the books fliter on a card component atm, but nothing stops me from filtering on an oreo component. And this is my modicons.java atm. Unfortunatly I caught a flu and have headache on another level now heh

 

[overdhose]

allright, I grabbed the mod and tested it. Will make an oreobook and show the results soon I hope.

 

[overdhose]

I added some components to your prefab, hope that's ok with you.

here's the example of the builder prefab : oreobuilder.prefab

 

[overdhose]

finally figured out how to do this properly... old people and youtube *grins*

 

[Skaldarnar]

Yeah, great, with animations and stuff Good work, overdhose!

 

[overdhose]

more like good work Maternal, merely providing an easy way to show what was made. More will come soon, still plenty of animations left to show of, but I need to figure out where / how to incorporate them.

Incidentally, the pony and the oreo have different walking animation files... maybe we have to decide on some kind of convention to name them so we can easily add models and switch between animations.

 

[glutamatkrieger]

overdhose, great work, jeah it would be great to have guidelines for animation and perhaps its also good to know which polycount would be the best.

Great i am really interested in seeing more

 

[Cervator]

Teehee - check out our Facebook profile picture. Had to

Changed for Google+ too ... although there part of it is hidden, but not like anybody will ever notice ...

Keep up the good work guys!

 

[glutamatkrieger]

Wow thanks !

 

[overdhose]

Allright, started to think a bit more clearly again, here's a new component I'm making:

public class AnimationComponent implements Component{
public MeshAnimation walkAnim; // Different speeds?
public MeshAnimation idleAnim; // combine with randomanims
public MeshAnimation attackAnim; // Different speeds?
public MeshAnimation dieAnim; // same as byebye, wrath of god (destroy all minions)
public MeshAnimation fadeInAnim; //Teleport at location, also spawnanimation
public MeshAnimation fadeOutAnim; //Teleport to location 
public MeshAnimation workAnim;
 
public List<MeshAnimation> randomAnim; // random animations while Idle
 
}

The idea is to define a template of what animations we might expect for minions. It is heavily based on the animations Maternal created for the Oreos. This is an initial draft, but you get the idea. I was thinking of combining this with either the existing SimpleMinionAISystem, or creating a seperate SimpleMinionAnimSystem.
My reasoning between reusing SMAIS is simply a performance consideration, As it already loops over quite a few components I require. Then again, Maybe looping over to many components is bad, and maybe I should combine all these bits and pieces in 1 big MinionComponent, maybe one of you great minds can guide me in the right direction concerning this (winks Immortius)

Maybe Cervator can run some kind of poll of what Animations would have to be included / excluded.

 

[Immortius]

Ok, a few things:

All of those Strings should be MeshAnimations.The nice thing about our asset system is when defining a prefab and filling in an asset field, you can use the asset's uri - for example

{
    "AnimationComponent" : {
        "walkAnim" : "core:blobWalk"
    }
}

And at runtime the asset will automatically be loaded and added to the entities created with the prefab.

ArrayList should be List<MeshAnimation> - best practice is not to use ArrayList (or other collection implementation classes) as a variable type, stick with the interface (so List<>). The entity serialization system will actually fail to handle ArrayList fields. Also, make sure to include the generic types, otherwise the serialization system won't know what the List contains - your IDE should complain about this anyway.

As for how animations should be applied... There's a few different approaches of varying complexity. Note that an AnimEndEvent is sent when an animation ends, so that can be hooked into. It would be a good idea to add a ChangeAnimationEvent to send to do the animation change.

There are basically two causes for animations - state (idle/walking/running/jumping/falling are based on the overall state of the character) and events (attack/die are triggered, play once and then stop). In theory you would actually combine animations (if you attack while walking, the character's legs should keep walking while the upper torso attacks) but we don't have support for this or tweening (fading between two animations) at the moment. Anyhow, you could certainly have a system that monitors state and changes animations as necessary, with events triggering the play of overriding animations.

There's no reason why animations would be specific to minions, as opposed to any character, but given the shakeup the character/player code is getting at the moment in the multiplayer branch it would probably be safest to do it that way at the moment.

 

[overdhose]

i had noticed the Arraylist mistake. Many thanks for the AnimEndEvent, was just looking for that, telepathy++.

Updated post to reflect changes

 

[overdhose]

just a small remark, not sure how to solve it, but as you might have noticed the oreos kind of float above the ground. I played around with the collision box height in CharacterMovementComponent to lower them to ground level, but if I lower the setting below 0.3f, they tend to disappear below the ground and get stuck there. Immortius told me the collision box gets calculated from the middle of the model, so lacking the technical terms, presuming the model was created at at 0.0 height, and is more or less 0.6 in height, the model should actually be created at -0.3 (I think), so I can let it touch the ground and not float in mid air. It's a small detail, just thought i'd mention it. I'm terrible at explaining this, so if anyone understands my gibberish, feel free to translate it in human language. I remember having a similar prob with an early turtle model... I miss that turtle

 

[glutamatkrieger]

I can understand you very well ! I placed a root bone for this but i do n ot know if you can actually use the root bone to place the Oreos. Most engines uses the Root bone, which is not animated and below the feet on x y z = 0 to get the right placement and animation orign. I was wondering why the Pony doesn´t have that one.