ago Report post Posted October 20, 2009 (edited) 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 October 20, 2009 by ago Share this post Link to post Share on other sites
Roja Report post Posted October 20, 2009 Ok it worked now, I was following the windows compile guide: http://www.eternal-lands.com/forum/index.php?showtopic=35624 And it said to change the options line in the make.win, so that's what I was doing that removed the -DWInver thing. Thank you Share this post Link to post Share on other sites
Fedora Report post Posted October 20, 2009 Anyone tested emotes under windows? Roja was having problem with animation loading (wrong file format ) . 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
Sir_Odie Report post Posted October 20, 2009 (edited) 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 October 20, 2009 by Sir_Odie Share this post Link to post Share on other sites
Light Lan Report post Posted October 21, 2009 compiled cvs with emotes works fine, no errors. however imo the animations look too fastpaced for me, please slow them down a little Share this post Link to post Share on other sites
Roja Report post Posted October 21, 2009 These animations are not final, just for testing purposes Share this post Link to post Share on other sites
Fedora Report post Posted October 25, 2009 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 - 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
bluap Report post Posted October 25, 2009 (edited) 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 October 25, 2009 by bluap Share this post Link to post Share on other sites
Sir_Odie Report post Posted October 25, 2009 (edited) Yes, the caf files are now downloaded correctly under windows... 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 October 25, 2009 by Sir_Odie Share this post Link to post Share on other sites
Fedora Report post Posted October 25, 2009 (edited) 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 Edited October 25, 2009 by Fedora Share this post Link to post Share on other sites
bluap Report post Posted October 25, 2009 (edited) 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 October 25, 2009 by bluap Share this post Link to post Share on other sites
bluap Report post Posted October 25, 2009 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
Usl Report post Posted October 26, 2009 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
Fedora Report post Posted October 26, 2009 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
Entropy Report post Posted October 26, 2009 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
Fedora Report post Posted October 27, 2009 (edited) 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 October 27, 2009 by Fedora Share this post Link to post Share on other sites
Fedora Report post Posted November 2, 2009 (edited) 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* - 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 - 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. --- Pls test EDIT: Pls, wait to commit this patch, another is coming soon with some changes... Edited November 6, 2009 by Fedora Share this post Link to post Share on other sites
Fedora Report post Posted November 10, 2009 (edited) 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 For poses, the active one is displayed in light blue. 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 November 10, 2009 by Fedora Share this post Link to post Share on other sites
bluap Report post Posted November 11, 2009 (edited) And here it is the 4th patch (patch, emotes)... OK, committed to CVS. Looking great! I hope we can keep the levitate animation. edit: BTW, I had to manually patch text.c again, even after we both refreshed from CVS. Weird! Edited November 11, 2009 by bluap Share this post Link to post Share on other sites
Alberich Report post Posted November 12, 2009 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
Ermabwed Report post Posted November 13, 2009 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
Fedora Report post Posted November 20, 2009 This should fix local chat (and some hash.c things) Share this post Link to post Share on other sites
bluap Report post Posted November 22, 2009 (edited) 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 November 22, 2009 by bluap Share this post Link to post Share on other sites
vinoveritas Report post Posted December 9, 2009 (edited) 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 December 9, 2009 by vinoveritas Share this post Link to post Share on other sites
Fedora Report post Posted December 19, 2009 As requested by Roja here is a patch for a smaller emote window. *removed the Do button, use double click to launch an emote *emote win icon moved Share this post Link to post Share on other sites