Fedora

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.

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.

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

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/)

bones, 155k

Imo, since we are modifying the server, we should aim for simple and efficient changes. I wouldn't worry to much about bots, they will be rewritten whatever protocol change we can decide. I'll go for a radical solution: whenever an item is sent, send the obj id together with the other data. The same for every request done by the client regarding an item. This way we can cache item description, cache the storage, add user-defined storage categories (just a list of obj ids), implement the inv snapshot, equip snapshot, bag snapshot or whatever else with very few client changes. Probably we'll need only a GET_OBJ_FROM_STO_BY_ID <id><quantity>. Or just modify the current message to avoid including the position. As pointed out by revi, this way we can greatly reduce server traffic and the cache (storage/description) can be flushed out and reconstructed only after a server update (by checking #stats for example) to be in synch. Hope this makes sense, it's late here

Sorry, I meant use it as it is now, and add new commands for the emotes. Ok, I added the following to client_serv.h: cast_spell = 80, //total of 32 commands reserved for spells. //Server sends cast_spell+spell_id or cast_summon cast_summon = 112 So you need to send "cast_spell+spell_id" or cast_summon. If 32 commands (so 11 more spells available) are not enough, just tell me how many to reserve If it's ok, I can submit the patch. From what I see, the current client should have no problem handling these new commands, so for the sake of better debugging, you can safely modify the test server.

bones, 135k

Which one of the two proposed alternatives for ADD_ACTOR_COMMAND you want me to use? (or a third one?) So, to start the chat I'll suggest a possible implementation I think that object ids are not only an useful addition for GUI features or bot code, but can be used to introduce some desired but lacking game features. I'm referring to the many threads about Unique Objects Ids. Well almost unique So, if the obj id is a 32 bit integer we can use, for example, the first 24 bits as the id number and the remaining 8 bits as flags. These flags can store the "quality" of the object to reflect the skills of the mixer (together with useful additional info as the category and what skill are they mixed with). The quality (let's say 0 to 4, 0=no quality, 1..4=low,normal,high,outstanding) can be set at the time of the object creation, i.e. based on the mixer skill or on the selling NPC or the monster drop. Objects will stay in inv, trade win and bags based on their image_id and pos, so no big changes are needed in the client code. The only thing to change a bit is the storage code...but not that much. Indeed I think the current storage structure can be preserved. If the server code is something like: item storage[300]; it can be changed to: item storage[300][5]; where storage[x][0] is the storage as it is now with 300 slots and objects stacked regardless of quality, while storage[x][1..4] stores the quantities for each quality type of that object. By double clicking on a item, let's say a srs, the client could send a INSPECT_STO_OBJ(id,pos) and would get the content of storage[x][1..4] allowing the display of my oustanding,high,normal and low srs, which I can then move to inv. If I don't want to inspect, the server fills my inv with objects of the quality it wants. The coding should all amount to some bit masking here and there. Once quality is implemented it can be used in many different ways, from giving bonuses to better items, to higher NPC buy price, to increased durability... The client code would not require big changes, and I volunteer for the obj quality storage thing if it gets implemented. I also spoke with some bot owners/coders and I think they would be happy with object ids even without backward compatibility. If so, what is required is just to send the object id together with image_id and pos in the server messages about items. Last thing, when is the next update planned?

125k

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.

While we are testing emotes I'd like to suggest some enhancements. First, the barehanded test needs to be modified to take into account quivers and gloves which are not considered as barehanded atm. I'll do it soon. Second, the test to check if the current emote can be played assumes that an actor can change sex and/or race (via shapeshifting) and waits 2 secs before being removed. If the sex/race change feature is not planned in the shapeshifting, I will rewrite the test to avoid losing time for not playable emotes. Third, I noticed the client already has server commands for some actions not yet linked to animations (from client_serv.h): Apart from harvest (problems with resources, harvest area, orientation and so on), all the others can be easily and naturally implemented as emotes (using the emotes code triggered by a server command instead of a local chat string). If you want such animations playable I can easily change the code to handle server commands. Another animation which is not there but can be handled as an emote, is the summon one (yeah, I'm biased ), simply by reading local chat for the corresponding text.

I've committed the patch. BTW, the window makefile link is not correct and the file is not in CVS. sowwy link is now working

For bluap: here is the text.c file in case you still can't update the cvs

gimme sunflowers \o/ 3x20k as usual, ty

Patch reuploaded (with some code fixes too ) after a cvs up, and created with a cvs diff -Nau \o

oops, sorry, there's a bunch of dlls to download indeed...I'll post the link soon EDIT: here are the DLLs. Be warned, file is big (9Mb) and I suggest not to unpack it in your EL root dir, it will overwrite existing dlls with some that could be newer or older. Make a copy of your EL installation and use that for the mapediting.

For everyone who wants to try: - Windows Mapeditor - cvs patch - windows makefile (some things to change inside based on your library path) Enjoy. EDIT: The editor now searches for tiles inside ./3dobjects/ as .dds files.

I have hopefully completed the work on emotes. - here is the patch (with console debug msgs) - here are the xml files - here are the animations patch and compile the client, uncompress xml.tgz and emotes.tgz in the root dir (beware, player_frames.xml is overwritten!) and test it The rest of this long post is for programming details, skip as needed. How emotes work - Emotes are triggered when some text is typed in local. The text is specified inside a <command> tag in emotes.xml where all emotes are defined. An emote can have more than one triggering command. I removed the *emote* syntax to make it more flexible...you can always add the * in the xml. - Once triggered, emotes wait in a queue until they can be processed or until they expire (2 sec timeout). Conditions that can be specified are: * sex: played only if actor is of a certain sex * race: played only if actor is of a certain race * held: played only if actor is riding * barehanded: played only if actor has left, right, or both hands free * current idle position: sitting, walking, running, standing. Test for current position is done by looking at the current animation frame. (more details in emotes.xml) - A emote is made of a bone animation and/or of a facial expression (for future expansion). Basically a emote is made of two animations played simultaneously. - Animations files for emotes are under animations/emotes and are generated using calstripper (more later) - There is a #emotes command to display available emotes How cal3d works There is little documentation for this library on how to blend animations, so here it is what I learnt: - cal3d animations can be Cycles or Actions and they are blended together in the CalMixer - Cycles have a wight of 0, Actions of 1 so if an action is in the mixer the cycle is not played - animations are lists of traslations and rotations associated to bones. If a bone is not defined in an Action it gets the traslations and rotations of the Cycle. - once an Action is ended it must be removed from the CalMixer because the last keyframes are still used (the actor remains still on the position defined by them) - For these reasons emotes are not stored in the actor.cur_anim and also can't be played while ranging or fighiting. Indeed the idle ranging and idle fighting anims are Actions, not Cycles. - Actions can be blended together, but the result is weird. Maybe there is a way to set the relative weights but I didn't find anything about. How calstripper works Blender has an incorrect cal3d exporter. Indeed, even if a bone is not moving, keyframes are created for it. This makes impossible to export a "local" animation, i.e. an Action that can be blended with a Cycle. I coded a little program, calstripper (.exe and code inside), that takes: - a source animation (emote exported by blender) - a dest animation (our localized emote) - the skeleton file used by the animation (medium.csf for players) - an optional blending animation (b_anim) Then, for each bone in source, it asks if the bone should be placed in dest. For convenience it displays if the bone is moving or not. If the optional blending animation is given, you can also Blend or Force bones: - When you blend a bone, you basically take the b_anim corresponding bone and add to it the difference between each keyframe of the source. This is useful to generate, as an example, the wave_sit emote animation. Indeed *wave* is exported with the bones in standing position. Even if unmoving bones are removed the "back2" bone (which is used to move the torso slightly to the right) is still in a wrong position (not rotated toward the front). By blending it with player_sit_idle.caf as b_anim, it is moved to the front (as while sitting) but the rotations to the right are preserved. - When you force a bone, you set the first and last keyframes to the ones of the b_anim corresponding bone. This is useful to generate wave_sit once again. Indeed the arm bones start from the standing position, go up and down again. If you sit and wave, your arm goes underground. By forcing the arm to the player_sit_idle.caf starting position, this issue is solved. Should be all, please test and report bugs

I had a fast chat with Ent about this, and probably the best solution is to modify the server to send object ids together with image_id, pos, and quantity. Then there would be no more problems and also bots will be easier to code,test and mantain...maybe is time to start a thread in the programming forum? I'm busy with emotes, if Ent is willing to add obj ids, feel free to start implementing

126k

121k

hello 100k sunflowers pls (5 batches of 20k) ---> 75k gc

How would you like it implemented? I may code it as soon as I'm finished with emotes , if no one else volunteers. My idea is to add a <save> button to the inventory window. When pressed it stores the current inventory content (equipment excluded...or not?) to the storage "recipes" pool. When you open the storage you can then browse the saved inventory contents, and if items are in sto, be able to withdraw them all with a click. other ideas? EDIT: On a second thought, probably it is not possible to get things back from storage only with the data of the inventory win...