Fedora

Posting here, not sure if a new thread is needed in programming section. I did a quick patch to test item ids and I think there's a server side bug. When sending a GET_NEW_INVENTORY_ITEM the size field of the packet is not correct in item_uid mode. It is always set to 11, while it should be 13. This causes a packet overrun for the next packet in the queue. Or maybe I need more sleep

I coded a couple of patches for the GUI. - Manu window with the possibility of saving recipes and recall them later. Here. Users can save up to 10 recipes. Manu window is 12 pixel taller to accomodate a status message, while len_x and buttons are untouched (maybe moved a little to the right, can't remember). Pipeline moved all to the left. Added a small control to switch between recipes and a button (+) to save a recipe without pressing the mix button. - Spell window with the same modifications. Can save up to 10 sigils combinations. Window is 12 pixel taller and buttons slightly nearer each other to accomodate the recipe handling control. Here Feel free to modify the GUI, I'm not very good with layouts

We have sslessars...not much used, but a good alternative when 8 acws are overkill. Also, they're the only summoned monster that wander. I think other changes (like multiple summons, more control over summons) are more beneficial to the skill. I agree. It would be nice to have some changes on special effects pets, like spiders for example. No one uses spider stones even if the paralyze feature is useful. In this regard, I slightly hijack the thread and suggest a new oldschool recipe to summon multiple spiders at once. Good reserve of mana (both for you and the opponent), better chance of paralyze. We have Gargoyles. Summoned a throng when I was short of wolf furs...*memories*

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)

240k

200k

200k

210k

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

250k

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 don't commit yet

445k

435k \o/

425k

410k ^^

This should fix local chat (and some hash.c things)

Try to limit fps: Ctrl+O -> video tab -> Limit Fps

230k ^^

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

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

250k

220k

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.

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

125k ^^