Emotions

[Torg]

This is a thread to find out if anyone is already working on or thinking about coding support for "emotion" animations, and to act as a general discussion thread for the topic.

 

From my initial thoughts about this, it should be relatively straightforward to implement. The server protocol would need to be decided on, and animations need to be made but neither is important at this stage. For the code, there would be 2 parts to it.

 

Firstly triggering the animation command and sending it to the server, and secondly handling the animation command from the server to display the animation. The code for such things already exists so it should be pretty simple to get working and ready to be tied to a protocol implementation and some animations.

 

If there isn't anyone looking at this, then I'd be happy to take a look as I have some time over the next couple of months.

[bluap]

This is a thread to find out if anyone is already working on or thinking about coding support for "emotion" animations, and to act as a general discussion thread for the topic....

It crossed my mind to volunteer when I saw Roja's post the other day. Having not done anything like this before it was both an interesting thing to try and something I had to think twice about. I have not even started looking at the current code but was thinking along the same lines as you. If you think there is work enough for more than one dev then let me know, otherwise I'm sure I can find something else to occupy myself.

[Warlove_Bagpipe]

Hi

I was planing to code it as I wrote here but no one send feedback to this proposition so I leave it. Lately I have read here that emotions moves still waits for implementation. After little chat with Shmurk (I was thinking that he takes care about animation development after his ranged weapons implementation) I have much more clarified idea about possible implementation. My idea is not to create new packet kind but rather send emotion move as special local chat message (for example one special byte means that local chat message is emotion move and two next bytes means emotion id). In my opinion server not need to analyse emotion moves messages and it is of course thing to consider (I could miss something ).

 

Yesterday I looked at code and I think that few things "around" implementation of emotion moves should be clarified.

In file actors_scripts.c in function move_to_next_frame() idle animation should not be directly set but rather set_on_idle() should be used there. In same file function cal_actor_set_random_idle() should be rewritten and should use cal_actor_set_anim_delay() function form cal.c.

 

Anyway, Trog please fell free to code emotion moves because I used to code in high level languages and coding in c probably took me very long time.

[Torg]

I was planing to code it as I wrote here but no one send feedback to this proposition so I leave it.

Sorry, I missed that one.

 

After little chat with Shmurk (I was thinking that he takes care about animation development after his ranged weapons implementation) I have much more clarified idea about possible implementation. My idea is not to create new packet kind but rather send emotion move as special local chat message (for example one special byte means that local chat message is emotion move and two next bytes means emotion id). In my opinion server not need to analyse emotion moves messages and it is of course thing to consider (I could miss something ).

Actually, I like that implementation. It is simple and doesn't require any server coding.

 

Anyway, Trog please fell free to code emotion moves because I used to code in high level languages and coding in c probably took me very long time.

Oh ok. I'm happy to let you do it if you have already started thinking about it, but I shall take a look this afternoon.

 

Yesterday I looked at code and I think that few things "around" implementation of emotion moves should be clarified.

In file actors_scripts.c in function move_to_next_frame() idle animation should not be directly set but rather set_on_idle() should be used there. In same file function cal_actor_set_random_idle() should be rewritten and should use cal_actor_set_anim_delay() function form cal.c.

Thanks for that. I'll take a look at those.

[Torg]

My idea is not to create new packet kind but rather send emotion move as special local chat message (for example one special byte means that local chat message is emotion move and two next bytes means emotion id). In my opinion server not need to analyse emotion moves messages and it is of course thing to consider (I could miss something ).

 

Yesterday I looked at code and I think that few things "around" implementation of emotion moves should be clarified.

In file actors_scripts.c in function move_to_next_frame() idle animation should not be directly set but rather set_on_idle() should be used there. In same file function cal_actor_set_random_idle() should be rewritten and should use cal_actor_set_anim_delay() function form cal.c.

Hmmm, thinking about this a bit more, should the emotion moves only occur if the actor is idle (and any local chat emotion code ignored otherwise), or should it stop whatever the current action is?

 

If it was to stop the current action (walking etc) then it would certainly need server interaction. Otherwise, your idea of using the idle functions would be fine.

 

/edit: Actually, thinking about it more, surely the emote should be treated as a command and handled by the server so if nothing else they can be queued. That is, if you send multiple "emotion move messages" (ie, another before the first has finished) then the second move isn't ignored (due to the actor not being idle at the time). That said, I guess it doesn't matter if you type too fast and messages get ignored as they aren't really a hugely important part of the game play.

... Still thinking... Ideas?

Edited September 3, 2008 by Torg

[Warlove_Bagpipe]

Hmm its not such simple as i was thinking. CAL library allows you to mix animations and plays two or more simultaneously. For example there could be emotion moves when character is walking (for example walking and waving hand), and other one when character is sitting and so on. I dont know how Roja is going to work with animation moves (is she prefers to create whole character animation or only part of character(only character hand for example) animation for mix with existing animation). So it must be decided that emotion animation should be separated state or current state addition.

 

Actually, thinking about it more, surely the emote should be treated as a command and handled by the server so if nothing else they can be queued. That is, if you send multiple "emotion move messages" (ie, another before the first has finished) then the second move isn't ignored (due to the actor not being idle at the time).

In my opinion it would be better to immediately blend emotion animation into next one when next one is sent. It could be more fun for players and allow them to create some "dance" moves .

 

--

Sorry for bad English

OnyXa

[Roja]

Well here's a short list of some simple animations, all of which (except the last 2), can be done while sitting OR standing..so ideally they would be "blended" with the current idles sit/stand animations.

 

wave

nod head

shake head

clap hands

shrug

scratch head

jump

stretch

[Acelon]

Can we add bow to that list too?

[Aislinn]

Can we try as well?

[Talixim]

Landes Eternelles (the French version of EL) has a command for bow, pretty simple you just type #salut and your character places their hand over their stomach and bends forward slightly.

 

If that's any help.

[bkc56]

Can we try as well?

Just be careful what you have equipped at the time.

 

Same for "scratch head".

[Roja]

Can we try as well?

 

probably should make this a permanent idle for some people

And good point bkc lol...although I think it's unavoidable as too many of these will interfere with the weapons.

[Mar(c)]

Oh! don't forget please!

[Schmurk]

And good point bkc lol...although I think it's unavoidable as too many of these will interfere with the weapons.

Hehe, it could be funny.

 

However, you can avoid it by using the left hand for the animation or rotate the hand in order the weapon is tangent to the head...

[LabRat]

Regarding emotions - at the moment the character's face is static (unblinking etc). Would it be practical for the face bitmaps to have a series and load each one at random times:

Blink: head_draegonimblue.bmp -> head_draegonimblue_blink.bmp -> delay .2 seconds -> head_draegonimblue.bmp

Local chat: head_draegonimblue.bmp -> head_draegonimblue_mouthopen.bmp -> delay .1 seconds per word -> head_draegonimblue.bmp

Damage: head_draegonimblue.bmp -> head_draegonimblue_pain.bmp -> delay .5 seconds -> head_draegonimblue.bmp

 

etc

 

This would be simple to code client side, requiring just a mesh update (the new frames) from Roja and hooks/timers in the client code to change and revert the images.

 

Comments?

[Kylara]

Oh! don't forget please!

 

I totally agree, we need them!

Edited September 4, 2008 by Kylara

[The_Piper]

However, you can avoid it by using the left hand for the animation or rotate the hand in order the weapon is tangent to the head...

 

Hitting a steel shield against your forehead doesnt sound very healthy either

 

Piper

[Roja]

I don't think changing the texture for the face would look good at all because there'd be no blending between them. Hugs, and other interactions between 2 players won't work because many are different sizes-sorry guys.

 

 

Anyway, please leave this thread for the programmers to discuss things-it's not a free-for-all suggestion thread(we can more than come up with the ideas for hugs and things like that on our own, don't worry )

[LabRat]

Thanks to kirianthis for the blending and creation of the gif animation.

 

As for the coding side, adding this is trivial and would require no server support.

[Roja]

Ah ok, I thought you meant just 1 frame for a different expression.

[Schmurk]

Yesterday I looked at code and I think that few things "around" implementation of emotion moves should be clarified.

In file actors_scripts.c in function move_to_next_frame() idle animation should not be directly set but rather set_on_idle() should be used there. In same file function cal_actor_set_random_idle() should be rewritten and should use cal_actor_set_anim_delay() function form cal.c.

I've worked again a bit on animations recently for another feature and I have some precisions to bring about all these functions.

The use of the set_on_idle() function is to pass from a non idle state to an idle state and the supposed use of the idle code in the move_to_next_frame() function is to change the idle animation to another one after 5 secs so the set_on_idle() function can't be used here.

However the code to change the idle frame in move_to_next_frame() is not working AFAIK so I've replaced it by something else in the feature I was working on.

 

About the cal_actor_set_random_idle(), like we've looked at it together the other day, it is not used actually and I don't know if it'll ever be because I don't know who has coded it and what was exactly the idea behind it... So I think we should just ignore it for the moment.

 

To be back on topic, I also think that emotes should be handled only on client side. However, I think that it would be good to push them in a separated queue in order to play them one after the other. This way, the user can easily specify a list of emotes to play and be sure that they'll play correctly. Then, in the code, you can play them as long as you're in idle state but as soon as you leave this state, you clear the queue.

 

For the protocol, I think it would be good to keep a way for users to type an easy to understand text code to trigger an emote rather than using special chars. The code can be something like :emote name: or <emote name> or [emote name] or whatever...

But in a second time, we can also have a window with all the possible emotes and when you click on one, it only adds the text code in the currently typed message.

 

Anyway, if I can be of any help for the code, let me know...

[Roja]

So is anyone working on this?

[LabRat]

I am just working out how I can change the face bitmap so it updates. I haven't looked too closely in the code but my first guess would be to treat the face as you treat clothing (unequip the face followed by immediate equip of the new face)..

[Torg]

So is anyone working on this?

I was thinking about this but I wasn't sure about the implementation. I guess I let it drop because I got too busy but I was hoping for more discussion about it. I am about to finish work (in a week) so I'll (more or less) have 2 months to play with this around any odd jobs I pick up before heading back OS.

 

Schmurk's idea of a second queue for the actions which could be used when the character is idle I think is a good idea, but I'm still not sure whether we need to be able to handle emotions during another animation (possibly merge 2 anims), especially if they are mostly going to be restricted to the upper body (waving a hand, etc).

 

I am a bit worried about actions being dropped when the character isn't quite in an idle state yet or just come out of it (due to lag, etc).

 

I know these aren't necessary, but I think people will come to rely on them (as they did with the counters and other client-side features) so it would be good to "get them right", and hence I'm trying to come up with a better way to deal with them if possible.

 

If the general consensus is to create a seperate queue and play the queue when the actor is in an idle state then I will look at that. My question at that point would be when should you start adding things to the queue? (ie, wait until the actor is in an idle state, or pre-empt them and just clear the queue after a second or so if the actor doesn't go idle).

 

I'm sorry if this doesn't make any sense... my brain isn't here at the moment.

[Schmurk]

If the general consensus is to create a seperate queue and play the queue when the actor is in an idle state then I will look at that. My question at that point would be when should you start adding things to the queue? (ie, wait until the actor is in an idle state, or pre-empt them and just clear the queue after a second or so if the actor doesn't go idle).

I think the idea of queuing the emotes until the actor gets in idle state is good. Instead of using a timeout of 1 sec which is generally low for big lags, you can maybe also decide if you have to queue an emote by testing the last action in the queue of the concerned actor. This way, you can see if the actor is fighting, moving or something else...

 

BTW, if only arms are going to move, we can also maybe authorize the emotes when an actor is walking?