Jump to content
Eternal Lands Official Forums
Torg

Emotions

Recommended Posts

Ok, this it?

 

-DWINDOWS -DELC -mwindows -DATTACHED_ACTORS

-mwindows -DWINDOWS -DELC -DWINVER=0x500 -DATTACHED_ACTORS

 

1) Makefile.win is not updated properly. It should contain the -DWINVER=0x500 flag

or 2) The Dev-Cpp project needs to be updated too.

 

I don't have a working Dev-Cpp project for elc so I can't test it right now.

Somewhere in the project options (Project->Project Options), most likely in the Parameters tab should already be the -DWINDOWS -DELC entry.

Add -DWINVER=0x500 to that line.

 

I'll try to setup a Dev-Cpp project and test later today when I get back home.

Edited by ago

Share this post


Link to post
Share on other sites

Anyone tested emotes under windows? Roja was having problem with animation loading (wrong file format :P) . I compiled for windows (under linux), tested with Wine and it works smoothly....I have no clue.

Share this post


Link to post
Share on other sites

I built a windows client which was tested by several players without any problems...

 

I found the problem: the animation files in CVS are all broken

Correction: the files in the CVS repository are correct, but it seems that (at least some) CVS clients download them as text-files and render them useless that way... :=((

these files are binary files but were handled as text files --> all 'line endings' were altered from '0D' to '0D0A'

 

If you download the animations from Fedora's post, everything should work fine...

Edited by Sir_Odie

Share this post


Link to post
Share on other sites

Ok, second patch ready:

 

- barehanded test changed: gloves and quivers count as barehanded (should we display some message if emote can't be played due to current frame/barehanded conditions?)

- emotes can have associated sounds, just add them to the corresponding frame in player_frames.xml

- added support for spell/summon actions, triggered by server cmds (waiting for them to be in test server). Instructions in emotes.xml (notice that emotes.xml as it is now is for testing only, gives some errors on logout due to double free())

- printfs are still there :wub:

- If fighting or ranging, emotes are removed from queu without waiting

- by Roja request, local chat lines containing emotes only are not displayed (can be disabled under the option chat tab as "Emote Filter")

- by Ent request health is now unsigned (this is the only change not #ifdef'ed with EMOTES)

 

Here are patch, emotes.xml and player_frame.xml. (Spell animations are already included in the client \o/)

Share this post


Link to post
Share on other sites
Ok, second patch ready:

I've commited the new patch and updated the xml files.

I've also (think I) fixed the problem with the caf files in CVS being interpreted as ascii rather than binary on windows systems.

Edited by bluap

Share this post


Link to post
Share on other sites

Yes, the caf files are now downloaded correctly under windows... :o

 

Edit:

 

It seems there is a bug in the cur_health/max_health patch: even NPC's have now a (veeeeery long) health bar over their head...

Edited by Sir_Odie

Share this post


Link to post
Share on other sites
Edit:

 

It seems there is a bug in the cur_health/max_health patch: even NPC's have now a (veeeeery long) health bar over their head...

 

ouch :/

looking where the culprit is hiding...

 

EDIT:

 

ok found. NPC's seems to have max_health set to -1 which as an unsigned is 65535:o

So...can the server just send a 0 as their max_health? with max_health=0 bars *should* not be drawn from what I see.

 

Alternatively, I can check if the bar belongs to a NPC (can I?) or just ignore max_health=65535 bars...

 

let me know :o

Edited by Fedora

Share this post


Link to post
Share on other sites
It seems there is a bug in the cur_health/max_health patch: even NPC's have now a (veeeeery long) health bar over their head...

Weird, I'm not seeing this problem. Edit. OK NCP have the problem... a good clue.

 

BTW fedora, I had to manually patch text.c again. May be, after you have double checked I patched it OK we should both delete our copies and re-download form CVS.

Edited by bluap

Share this post


Link to post
Share on other sites
Alternatively, I can check if the bar belongs to a NPC (can I?) or just ignore max_health=65535 bars...

I've added a check for NPC actor types which looks to have fixed it.

Share this post


Link to post
Share on other sites

While you guys are working on animations, I would like to suggest a relatively easy (I hope) feature to enliven our surroundings.

 

Basically, the idea is to (optionally) send out a command to set an animation frame for NPCs, possibly different than what is used for players. We already have something like that, with ADD_ACTOR used to add an NPC, and then ADD_ACTOR_COMMAND used to have the NPC sit if needed.

 

What I am proposing is to optionally send an animation command after the ADD_ACTOR (and possibly in place of the ADD_ACTOR_COMMAND), so that we could have NPCs stationary, but in different positions (such animations would only comprise a single frame). Then, Squint in MM could have his hand above his eyes, in the vigilant position; Raven could be leaning on the cart; Urania could be looking inside the telescope; etc.

 

The client support should be essentially there; as for server support, the setting of an animation frame could be added only to new NPCs, as they are added to the server, and then possibly retrofitted to old NPCs (animations could be pushed via remote updates).

 

Finally, the change is backward-compatible; old clients would just ignore any animation they are not prepared to handle, so bots would be unaffected and old clients would just show a standing NPC (as it is now, so there is no quality degradation).

 

What do you think?

Share this post


Link to post
Share on other sites
What I am proposing is to optionally send an animation command after the ADD_ACTOR (and possibly in place of the ADD_ACTOR_COMMAND), so that we could have NPCs stationary, but in different positions (such animations would only comprise a single frame).

 

<snip>

 

Finally, the change is backward-compatible; old clients would just ignore any animation they are not prepared to handle, so bots would be unaffected and old clients would just show a standing NPC (as it is now, so there is no quality degradation).

 

What do you think?

 

ADD_ACTOR_ANIM<actor_id><anim_id>

 

This would be perfect to implement the spell/summon actions instead of an actor command. A few flags in the related xml file can be used to decide if the animation is "static" (played once and not removed, for NPC) or "dynamic" (played and removed as needed, for spells).

And the client support is there, just a tweak of the emotes system.

 

Even more can be done with the current code. Some simple animations (not just static positions) can be added easily to some NPC. Imagine the Wraith raising an arm and casting a spell on his costumers (ADD_ACTOR_ANIM<wraith><cast1> SEND_SPECIAL_EFFECT<type><ip noob>) or the various shopkeepers at least nodding when you buy something and shaking head to antisocials...emotes could be reused for NPCs with no complications.

 

:)

Share this post


Link to post
Share on other sites

That's not a bad idea at all..

And possibly, to use USL's idea, also send a frame number and maybe a flag if we want the NPC to be fronzen in that position or not when idle.

Share this post


Link to post
Share on other sites
That's not a bad idea at all..

And possibly, to use USL's idea, also send a frame number and maybe a flag if we want the NPC to be fronzen in that position or not when idle.

 

One possible implementation with the current emotes system:

 

Server sends ADD_ACTOR_ANIMATION<actor_id><anim_id>

<actor_id> is the usual 16 bit int

<anim_id> is a 16 bit int representing the emote index to be played

 

I think it is better to send a emote id instead of a frame id for many reasons:

- an emote is an action animation and a face animation, so in the future, NPCs can wave and smile for example.

- an emote is a set of actions played taking into consideration the current frame of the actor. So, no need for the server to check if the actor is sitting,walking, running etc...just send the emote id and the client will play the right animation

- with an emote the server doesn't need to send flags, they are already in the emote definition. Just define static or dynamic emotes and the client will handle them.

 

Emotes will be defined in emotes.xml so the server can reuse player emotes for NPC, for example waving, nodding, shaking...etc. It is also easy to extend the current system to handle any actor_type...laughing giants, goblins fingering their noses...

 

When adding new NPCs the server can just push update new animations and related xml files. If a client can't update, no animation will be played (NPC will look as they are now).

 

And last, with this new server command, animations can be send based on the NPC status...finally Tankel's daughter will be sleeping or sitting depending on the quest status. Or Molgor could *stretch* from time to time...

 

 

If this message format/implementation is ok, I'll start code it right away.

Edited by Fedora

Share this post


Link to post
Share on other sites

And here it is the new emote patch and emotes.xml (player_frames.xml is not needed anymore, use the normal one).

 

I extended it a *bit* :P

 

- After a chat with Ent, Added a ADD_ACTOR_ANIMATION server message. It sends a <actor_id><emote_id>, both shorts (16 bit) and with the possibility of handling more actors in a single message (like ADD_ACTOR_COMMAND) through a list of <actor_id><emote_id>

- <emote_id> is the id specified in emotes.xml. id=0 is reserved and when the server sends it, all emotes are removed from the actor.

- emotes sent by the server have higher priority then emotes triggered by local text

- .caf animations can now be also defined inside a <frames> tag (with the possibility of specifying an actor_type), to make client updates easier.

- For each emote you can specify a <timeout>millisec</timeout> or leave the default 2 sec

- Emotes now accept "monster" as race, including all non playable races. This will be used to add emotes to the Wraith or to mobs.

- added a #add_emote <actor name> <emote_id> command for debugging purposes. Let Molgor *wave* finally :rolleyes:

- Emotes have sound, just define it in the <CAL_emote> tag for frames.

 

Emote system has changed. Now an emote is a list of frames each one containing animations played simoultaneously. For example, an emote defined as:

	<walking>
	<anim>2|7</anim>
	<anim>10|7</anim>
	<anim>5</anim>
</walking>

means that if the actor is walikng, animations with index 2 and 7 are played together. When they end, we start animations 10 and 7, then animation 5 and finally we revert to the idle state.

 

This system, apart from being more flexible, allows for less .caf file to be used (for example the emote \o/ can be defined as \o+o/, or \o+o/+*jump*). Allows also for custom emotes.xml of player-made emotes.

 

Inside the <anim> tag we can now put a cycle animation. It will be added to the Mixer, but, when the emote frames are all played, it won't be removed. This is a useful feature to implement NPC cycling animations different from the usual sitting/stading. (use emote with id=5 for testing)

 

I also added hash.c/hash.h, an implementation of a hash table with generic keys. It is used to store emotes commands and emotes frames, but will be useful to handle item caches when object ids will be introduced.

 

 

lasud1.jpg---lasud2.jpg

 

Pls test :)

 

EDIT:

 

Pls, wait to commit this patch, another is coming soon with some changes...

Edited by Fedora

Share this post


Link to post
Share on other sites

And here it is the 4th patch :) (patch, emotes)

 

Some major changes after a chat with Ent.

 

- We now have user selectable idles (poses). (details in emotes.xml)

- Player emotes are implemented as actor commands

- Non player emotes are implemented as actor animations

- We have a emotes window

 

Protocol

The client sends a DO_EMOTE<emote_id> (DO_EMOTE=70, <emote_id>=8 bit) every time an emote is triggered, both by local chat text or using the emotes window.

 

The server can send emotes to the client in two ways:

using an ADD_ACTOR_ANIMATION or an ADD_ACTOR_COMMAND.

 

*Player triggered action (waving, nodding, etc..)

CLIENT																	 SERVER
Sends DO_EMOTE<emote_id> 
with emote_id between 100 and 255
																			 Sends ADD_ACTOR_COMMAND<emote_id>
																			 to every actor who have to display the action.

Receives <emote_id> as a command
and queues it until it can be played.

 

*Player triggered pose (standing, sitting, walking, running poses)

CLIENT																	 SERVER
Sends DO_EMOTE<emote_id> 
with emote_id between 1 and 99
																			 Sends ADD_ACTOR_ANIMATION<actor_id><emote_id>
																			 to every actor who have to display the pose

Receives <emote_id> as an actor animation
and saves it in the actor struct to play it 
when the actor goes idle.

 

*Non-Player emote (NPC, monsters)

CLIENT																	 SERVER
																			Sends ADD_ACTOR_ANIMATION<actor_id><emote_id>
																			to every actor who have to display the emote

Receives <emote_id> as an actor animation 
and saves it in the actor struct to play it
when the actor goes idle if a pose, 
or queues it if an action.

 

Also, everytime the client receives an ADD_ACTOR, the current poses are reset to NULL (client plays the default ones). An ADD_ACTOR_ANIMATION is needed to inform the client of the current actor poses (Maybe this can be sent directly in the ADD_ACTOR message? Saves bandwith and avoids weird animations).

 

 

Debug

Waiting for the server messages to be implemented, I added:

- #add_emote <player_name> <emote_id>, to simulate an ADD_ACTOR_ANIMATION

- #send_cmd <player_name> <cmd_id> to simulate an ADD_ACTOR_COMMAND

 

open emotes.xml and play with the ids :)

(Warning: emotes triggered with local chat or emotes window cause client disconnection since DO_EMOTE is not yet recognized)

 

 

Emotes window

Open it with CRTL+J or hud button (I used the only unused icon I found).

Quite self explaining:

 

Choose categories, select and "Do!" or double click to play.

Name, Desc and Trigger (local chat text to trigger) are displayed

emotes1.jpg

 

For poses, the active one is displayed in light blue.

emotes2.jpg

 

Test pls :)

 

EDIT

 

TODO:

- adding support for facial expressions by mesh morphing. Not documented, but seems to be supported by the last version of cal3d.

- adding support for parametric emotes (harvest <map_object>, hug <actor_id>). Don't know if feasible yet.

Edited by Fedora

Share this post


Link to post
Share on other sites
And here it is the 4th patch :) (patch, emotes)

...

OK, committed to CVS. Looking great! I hope we can keep the levitate animation. :icon4:

 

edit: BTW, I had to manually patch text.c again, even after we both refreshed from CVS. Weird!

Edited by bluap

Share this post


Link to post
Share on other sites

couldn't compile it yet but i think your changes to the makefiles break the clean build

please use this for optional includes

EMOTES_COBJ = hash.o emotes.o

Share this post


Link to post
Share on other sites

Enabling the emotes make option suppresses the orange part of "regular" harvest event messages from being displayed in the client (and using the emotes window (i.e. the "do!" button) disconnects the client, though I suppose that's a protocol thingy).

Share this post


Link to post
Share on other sites
This should fix local chat (and some hash.c things)

OK, commited to CVS.

 

I've also done a doe2unix on that pesky text.c in the hope it fixed the patch issues. Sir_Odie spotted that the file was CRLF terminated, unlike all the other source modules.

Edited by bluap

Share this post


Link to post
Share on other sites

FORGET WHAT I WROTE BELOW

as i should be reading the posts more carefully i would have seen that the server can not do anything yet

 

 

 

Hi, i compiled me an cvs version at the stand of todays cvs sources, and tried to use the emotions menu, if i click on any of the commands which the window offers, i get disconnected from the game, is there something special i need to look for if i want to test this feature?

Actually i get allways disconnected when i try an command, and before i uses an command i uses #add_emote VinoVeritas commandid

Edited by vinoveritas

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

  • Recently Browsing   0 members

    No registered users viewing this page.

×