Fedora
-
Content count
547 -
Joined
-
Last visited
Posts posted by Fedora
-
-
bones, 155k
-
Here is my thought for a new protocol to enable the load/save of inventory items. I was hoping for something simple that would not require the current inventory/storage protocol to be modified. My major assumption is that the server already holds a unique id for each object in the game and that these IDs can be exchanged between the client and server. I think all we would need are three new client/server messages.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
-
Which one of the two proposed alternatives for ADD_ACTOR_COMMAND you want me to use? (or a third one?)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
-
The best way is to have new commands, otherwise it would be an ugly hack.Regarding the object id, that's not a problem, but probably should be done when closer to an update.
Which one of the two proposed alternatives for ADD_ACTOR_COMMAND you want me to use? (or a third one?)
May be we can chat about possible implementations. As I suggested in the thread fedora mentioned. If new commands were used, we could possibly maintain compatibility with the existing client.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
-
@Ent: due to my and Bluap's ongoing client patches, some minor server changes are needed.
ADD_ACTOR_COMMAND msg:
Roja agreed on having cast/summon animations implemented as emotes with the possibility of having different animations based on spell id. Atm this is not possible, the server does not send the corresponding actor commands.
I can link the animation to the SEND_SPECIAL_EFFECT msg, but it's not so clean and moreover not every spell/summon has a special effect.
Looking at the code, one possible way is to link animations to ADD_ACTOR_COMMAND. Since the command is one byte only, the spell id can be packed in the first 7 bits and the 8th set to 1. This way the current client will still work, adding spell animations will require only minor changes in the next_command() function and would also leave 50 or so available placeholders for new commands.
For the summon animation, I can link it to the local chat text...but if the ADD_ACTOR_COMMAND is going to be modified, why not use a specific command? Maybe reusing the "cast=10" to "summon=10" in client_serv.h
Or we can simply have 5 new commands: cast_summon, cast_heal, cast_defensive, cast_attack, cast_misc and play animations based on spell groups.
Object Ids
As stated in the corresponding thread, saving a snapshot of the current inv and restoring it from sto/bags requires object ids (well not, but would simplify the code a lot), while atm the client knows only image_id, position and flags (and description if requested). This would also simplify code for bots. I haven't any good idea on how this can be done nicely, maybe Bluap can add on the subject.
If you tell us how you want things done, we can finish the patches.
Ty
-
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):
pick = 6,drop = 7,
harvest = 9,
cast = 10,
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. -
-
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
-
Tried this hunny but I get an error message saying that the libgcc_s_dw2-1.dll file is not found. Might be possible for me to find it on the net but is there anyway you can include it in the zip file?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.
-
-
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
-
One easier, more reliable way might be for the server to do some of the clever stuff. May be the client could request some unique ids and quantities from the server when it stores an inventory list, then pass the same set of information back to the server to retrieve the same items. This would give control to the server, minimise the information exchange and allow the function to work reliably. I'd be happy to develop this idea or something similar further.....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
-
I also think it's a good idea, especially for new players that have a hard time remembering all the formulas and might find it frustrating. If someone wants to implement it, go ahead.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...
-
IMO is due to shortage of silver caused by:
- decreased player base and not enough new players
- mini events
- silver is quite far from storages
- no good "mix hes in place" spots (maybe add some crys out of MM mine?)
and for srs, I have no problem finding them for my needs (2k+ per day).
-
Ok, removed the eye_candy, the flickering and compiled
Emotions
in Programming
Posted · Report reply
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/)