Jump to content
Eternal Lands Official Forums

Fedora

Members
 View Profile  See their activity

  • Content count

    547

  • Joined

  • Last visited

Posts posted by Fedora

  4. Posted · Report reply

    lol, yes, I missed cal_types :P now should work

     

    EDIT:

    here are the source files for Roja to compile the client while waiting for the patch to be committed. EMOTES flag must be on, some code is shared.

     

    EDIT2:

    bugs found :pickaxe: don't commit yet

    While you're still working on this patch, is it work adding an additional #def, may be MORE_ATTACHED_ACTORS or something like that. Also, as ATTACHED_ACTORS had been in the client for a release it may be time to remove that one anyway.

     

    Ok, I rewrote the whole thing, this time without bugs hopefully :o

    The new code is #def'd with MORE_ATTACHED_ACTORS and should not break anything as long as EMOTES is defined too.

     

    For testing purposes I modified the #send_cmd <actor_name> <cmd> to accept a list of space separated command codes.

     

    test, test, test and report.

     

    For Roja, here is the code. You also need to add "FEATURES += MORE_ATTACHED_ACTORS" in make.defaults.

  5. Posted · Report reply

    Would be a nice to have a couple of movement related commands on the control summons popup

     

    * Stop

    * Follow

     

    Basic functionality

    The basic implementation should simply stop the pets in place, retaining their attack behaviour (as set with the popup) so they can still engage a fight with actors in their aggro zone.

    This would add some interesting strategy (guarding, ambushes...) and would also avoid the problem with summons at storages. Just stop them, restock and unfreeze them.

     

    Intermediate functionality

    I guess the client sends the actor_id of the "used" pet, having the actor_id means having the actor_type, so the commands in the popup (also attack ones) could be issued for creature type, not just for all pets (this if the server stores the summon mode for each pet and not for the summoner only). Even better strategies.

     

    Advanced functionality

    Would be wonderful if the stop/follow command, issued while a pet is fighting, caused it (well,all of them) to try to diss.

     

    Basic/intermediate/advanced are in order of my guess of server coding difficulty , but if implemented, they could be different behaviours of the stop/follow command at different skill levels (0,40,80).

     

    And last, a "spread/unspread" command would be also useful: when issued the walking algorithm of your pet is switched to the animal/monster one (going around randomly/standing still)

     

    :)

  7. Posted · Edited by Fedora · Report reply

    lol, yes, I missed cal_types :) now should work

     

    EDIT:

    here are the source files for Roja to compile the client while waiting for the patch to be committed. EMOTES flag must be on, some code is shared.

     

    EDIT2:

    bugs found :icon13: don't commit yet

  13. Posted · Edited by Fedora · Report reply

    Here is another patch (already discussed with Ent and Roja) about horses.

    We can now range and fight on them.

     

    Patch & actor defs (put them under actors_defs dir and make backups first)

     

    - there is a #horse command to get a client side horse (it disappears when your actor is sent again)

    - animations are not correct yet (apart from barehanded horse fighting). New .caf are needed.

    - you can range and fight and the horse *should* behave correctly

     

    <animation details>

    Each actor has a xxxxx_held_frame where xxxxx is one of the fighting involved frames (enter in combat, leave_combat, att_up, att_down).

    The _held_frames are used for actors on a horse instead of the normal ones. For horses (and mounts in general) they are played if they have a horseman. This way we can have orcs on horses, goblins on ferans and whatever nasty mount-mounter coupling you can think of.

     

    For each weapon animation there is the corresponding _held_frame used for the horseman. When the horseman is barehanded the horse does the attacking, when he is armed the weapon animation is played. However this needs server adjustments since when wielding weapons the horses should turn a bit to let the horsemen fight face to face (side to side from the point of view of the horses).

     

    The _held_frame are there for ranging animations too.

    </animation details>

     

    My assassin horse:

    horsefight.jpg

    horserange.jpg

     

     

    Please test this patch doing the nastier things you can think of (multi fight changing opponent fast, interrupt ranging in the worst moments, trigger resynchs and so on). Indeed I had to code some dirty tricks in order to make horses work, there might be some cases I did not cover. They usually are pretty evident, since you end up riding the air with the horse few tile behind you :P

    If you find bugs, please report the console output you get (a list of command codes) at the moment of the bug.

  16. Posted · Report reply

    Why don't you buy in 10k batches from the same person then? you'd get the same amount for less gcs ^^

     

    Because the same person knows (or feels) about time preferences. And making 10 different trades at 10 different points in time is more costly, due to the overhead of paying more attention to the game, moving to the meeting point etc...Buying 10 times from the market is even worse, because you have to compete with the other buyers and to be efficient you need to pay attention to @@3. Try to sell 10k @2 and see how many PMs you get, usually you have no more than 2 seconds before your PM is too late.

     

    This obviously does not exclude that the same thing can happen for the seller. You can find offers of 50k or even 100k silver @2.5, because they need money faster (their time preference) or because they are too lazy to post an auction.

     

    But seriously, when someone told me that you pay more for bulk I thought they were stupid. IMO if you want to get more than normal price for your hoards of silver, then auction it.

     

    Yes, that's a good way (if your time preference for gc vs silver is not high) because what you do with an auction is avoiding the "attention cost" of the buyers and allowing them to compete more fiercely for their time preferences.

     

    Another interesting strategy that avoids attention costs and allows for similar time preferences to meet, is the contract. I pay you 2.5 for x amount of silver harvested over t hours. If t and x suit both you and me, we have a contract which effectively satisfy my and your time preference without paying the overheads. I don't pay the 0.5 and don't look at @@3, whereas you don't have to post auctions and can be sure that after t hours you get your 2.5x money.

     

    As a side note is interesting to see that, whatever you put it and whatever whiners have to whine, a trade is always satisfactory for both parties at the very moment of trading (ex ante), so they both gain. You can only whine after (ex post).

  17. Posted · Report reply

    Time preference. I just pay more to have 100k silver @3 now in my sto, than buying in 10k batches @2.5, since the resource is scarce and I need a lot.

     

    And it differs from real life, because everyone can harvest silver at the same rate, we don't have specialized harvesters with noticeable faster harvest time. That's what a warehouse does, cutting the cost of production.

     

     

    ^^

  20. Posted · Edited by Fedora · Report reply

    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.

  21. Posted · Edited by Fedora · Report reply

    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...

  23. Posted · Edited by Fedora · Report reply

    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.

  24. Posted · Report reply

    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.

     

    :)

  25. Posted · Edited by Fedora · Report reply

    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

×