Fedora
-
Content count
547 -
Joined
-
Last visited
Posts posted by Fedora
-
-
Crossbows are not allowed on horses, due to the way they are reloaded.
Ok
Does the second issue happen for everyone in the area, or just for you? Also, do you fire multiple shots?
I was testing alone in the ranging arena. And no, I fire just one shot, for the last click I guess.
These are the queues just before the resynch:
Actor Fedora queue: -->52|R40|52|R40|52|R40|52|R40|52| 0| 0| 0| 0| 0| 0| Horse Fedora queue: -->256|R40|256|R40|256|R40|256|R40|256| 0| 0| 0| 0| 0| 0|
52=enter_aim_mode
R40=turn_e
256=wait
-
Just noticed a couple of things:
* range animations for crossbows on horse are missing
* if I enter aim mode and repeatedly click on a target, I get a ton of resynchs. The command queues are flooded with "rotation" and "enter aim mode" commands. I tested both without a horse and without MORE_ATTACHED_ACTORS and the resynchs are still there. Maybe a server issue?
EDIT:
Another thing: everytime a "enter aim mode" command is received the horse idle is changed. It's a bit weird because a sequence of neighing can overlap
. I'll fix the ranging idle for horses tomorrow. -
Great! (and thanks)
CVS updated again:
* Corrected a synch issue when you shoot the last arrow
* Added horse rotations while ranging (same as fighting): it needs the correct animation files, I think they will be released in the next RC.
* Debug messages still on
-
Wonderful!
I mean...missiles.c related messages appear in the log.
Moreover from what I can see you always get out of synch only after such messages.
This means that by unfreezing the horse when it happens we should not lose synch
CVS updated again.
-
sorry to say, it took only 10 minutes to check out, compile and fly again, on the notebook
you will find a recent console log and a corresponding screenshot in the notebook directory.
I'm quite out of ideas, tbh...I've just updated the CVS again with a little patch.
From the logs it seems the actor "forgets" to unfreeze the horse, but this shouldn't happen...unless some code from missiles.c or cal.c interferes with the horse.
I added debug messages to see if this is the case.
*cross fingers* pls, test this again
@Greypal
What do you exactly do to cause the unsynch? From the logs, it seems you walk, click once on a monster, click again and then shoot...but this sequence works for me
-
Well, I wasn't able to reproduce the unsynch on arrow shots.
However I corrected every piece of code I found where the horse and actor animations could get out of synch.
I even added some code where the horse and the actor check their respective animations to see if one of the two is stuck...
CVS is updated, even more debug messages added...let me know if it now works
@Greypal: very useful logs, if you could check this CVS update the same way, I'd be a happy elf
-
Damn...Thank you very much
-
Ok, I should have patched the (hopefully) last synch problem. CVS updated, debug messages still on.
For the _held bows animations...I must admit I don't remember what we decided, but surely I wrote no special code to handle them. I play _held animations if actor has a horse, and the frames are specified in the xml.
So yes, I guess adding the blended animations shoudl do the trick
-
Did you download our data files? Can you reproduce the problem?
Schmurk modified some ranging stuff to prevent the "get stuck in aiming position" bug, maybe his fix affected it?
I'm using files from http://www.eternal-lands.com/el_update_191_rc1.zip. There are no player_bow_*_held.caf animations in animations/ nor in anim_bow*.xml...can someone else confirm this?
I can't reproduce the disappearing horse bug (can I have the command queues from someone with this bug?), but I found another damned synch issue which I will correct tonight
Other than this, I ranged to death every single moving animal in votd while changing weapons and no "get stuck" bug happened.
-
However, a bigger problem is that now when you are ranging and aiming from a horse you will be standing inside the horse, as was reported here: http://www.eternal-lands.com/forum/index.php?showtopic=54283&view=findpost&p=543209 Now it seems that it always happens though.
Mmm...my anim_boe1.xml and anim_bow2.xml have the following lines:
<CAL_range_in duration="1000" sound="Bow In">./animations/player_bow_in.caf 1</CAL_range_in> <CAL_range_out duration="1000" sound="Bow Out">./animations/player_bow_out.caf 1</CAL_range_out> <CAL_range_idle duration="500">./animations/player_bow_idle.caf 1</CAL_range_idle> <CAL_range_fire duration="1000" sound="Bow Fire">./animations/player_bow_fire.caf 1</CAL_range_fire> <CAL_range_fire_out duration="1000" sound="Bow Fire Out">./animations/player_bow_fire_out.caf 1</CAL_range_fire_out> <CAL_range_in_held duration="1000" sound="Bow In">./animations/player_bow_in.caf 1</CAL_range_in_held> <CAL_range_out_held duration="1000" sound="Bow Out">./animations/player_bow_out.caf 1</CAL_range_out_held> <CAL_range_idle_held duration="500">./animations/player_bow_idle.caf 1</CAL_range_idle_held> <CAL_range_fire_held duration="1000" sound="Bow Fire">./animations/player_bow_fire.caf 1</CAL_range_fire_held> <CAL_range_fire_out_held duration="1000" sound="Bow Fire Out">./animations/player_bow_fire_out.caf 1</CAL_range_fire_out_held>
So the same animation is played if you are standing or sitting on a horse. Either I messed up badly with my defs files or some animations are missing.
For the disappearing horses, I'll look into it. It would be helpful if someone can find how to reproduce it
.The synch issues are gone?
-
Ok, patched. CVS is updated and debug messages are still on.
There were two sources of errors:
- horse2/horse3...horse7.xml inside /actor_defs contain wrong info. The lines:
<CAL_in_combat duration="500">./animations/horse_idle1.caf 1</CAL_in_combat> <CAL_out_combat duration="500">./animations/horse_idle1.caf 1</CAL_out_combat> <CAL_combat_idle duration="500">./animations/horse_idle1.caf 0</CAL_combat_idle>
need to be changed to:
<CAL_in_combat duration="500">./animations/horse_fight_in.caf 1</CAL_in_combat> <CAL_out_combat duration="500">./animations/horse_fight_out.caf 1</CAL_out_combat> <CAL_combat_idle duration="500">./animations/horse_fight_idle.caf 0</CAL_combat_idle>
- I patched (well, I hope
) a bug during on site rotations sent by the server. FYI, it was due to different durations between standing idles of the actor and the horse. It was already there in the old horse code but since no fighting or aiming was possible, it was never observed (so technically, it wasn't a bug, just a feature ).I also corrected the low camera height while on horse.
Pls post if you still find synch issues.
Cya \o
-
it took me a while to reproduce it and record it as well.
But now i've uploaded 2 files to http://greypal.el-fd.org/screenshots/test/ named
actor_queue.txt and actor_queue.ogg
where u can see how the queue for the horse filled up and see the corresponding shot in the video.
Thanks! I'll look into it.
If you still have them, can you post some more of the queues you get before the unsynch? Just to know what you were doing before.
EDIT:
Ok, I can reproduce it...and it is not caused by ranging/fighting queue asynch. Something goes wrong during in place rotations
. I'll try to patch it tomorrow \o -
Mmm...I've tried to generate every missile message (too far, miss...etc), get attacked by monsters while ranging but can't reproduce any synch issue.
I've just committed a modified actor_scripts.c that outputs some debug messages. It prints your and your horse command queue in the terminal.
Something like this:
11174---------> DOING: 43 ----------- Actor Fedora >FA< queue: -->R43|IC18|LC19|M25| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| Horse Fedora >FA< queue: -->R43|256|256|M25| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 11174---------> DOING (horse): 43 --- Actor Fedora >FA< queue: -->IC18|LC19|M25| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| Horse Fedora >FA< queue: -->R43|256|256|M25| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 11175---------> DOING: 18 ----------- Actor Fedora >FA< queue: -->IC18|LC19|M25| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| Horse Fedora >FA< queue: -->256|256|M25| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 11187---------> DOING: 19 ----------- Actor Fedora >FA< queue: -->LC19|M25| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| Horse Fedora >FA< queue: -->256|M25| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 11200---------> DOING: 25 ----------- Actor Fedora >FA< queue: -->M25| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| Horse Fedora >FA< queue: -->M25| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 11200---------> DOING (horse): 25 --- Actor Fedora >FA< queue: --> 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| Horse Fedora >FA< queue: -->M25| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0|
It can be useful if you could post the queues you have a little before and a little after you get the synch problems.
In the meanwhile I'll keep testing.
EDIT:
oh...yes...those debug msgs can be quite confusing
If you are unsure what to post, just search a line where the horse queue starts with a 256 and it contains a lot more commands than the actor's. -
I've fixed one of the crashes: #horse player1, #horse player2, #horse player1 -> crash. However, this would only happy with the #horse command not if they were "real" horses. The crash while fighting creatures (I tried spiders) is because they don't have weapons and the weapon structure is being accessed. We could fix this by adding lots of checks to the code (OK the proper way) but I guess it will never happen in "real" play. We could also hide the problem by limiting the #horse command to players. I presume if two mounted players were fighting, it would be fine (I'm off to try PK....). Judging by what I've seen, the actor code is little fragile in many places if we start to do unexpected things.....
Edit: Two mounted players fighting is fine.
The #horse command was initially there for players only, then I briefly extended it for monsters for the pleasure to see a riding orc
. However at present, the horse code is meant to function for players only, with some synch assumptions: while on horse you can't sit, when you get an horse you must be standing still. These must be enforced by the server when sending the mount (which happens by resending the enhanced actor). The actor code isn't little fragile, it's very fragile
It mantains two command queues, one for the actor and one for the horse, that are in synch only when walking. When fighting, the horse queue is frozen with a "wait" command and the synching is made "by hand" in the various code branches for fight actions. If a "sit" or "stand" ends up in the horse queue it is processed without a corresponding animation = no synching.For the camera issue, I'll look into it asap. I think the horse shift is simply not added to the position of the actors' head...
Cya ^^
-
*CVS updated*
Please test the following things:
- The warning in error_log about missing "255" attachment should be gone
- When resynching or logging near fighting players (on horse or not) the crash reported by Thery should not happen
Also, try some emotes before and after starting to walk while on a horse, they should be synch'd, but you never can tell
@Entropy
What are you sending as default code for neck items? I'm getting a value of 100.
It does not cause a crash, but some memory issues when trying to copy the corresponding and not existing actor def (tnx Bluap). Should I add a check?
-
Ok, I think I patched Thery crash. When a new enhanced actor is added and he is fighting, I forgot to check if he is mounting a horse before updating the (possibily not existing) horse status.
I can't test this patch right now, but it is on cvs, so if you want to try it out, cvs up and recompile.
The "255" warning is weird. I think it is related to the server sending a "-1" (255 if unsigned) to signal a null mount and some missing cast somewhere. I'll see what I can do tomorrow on my pc at home
-
I'll look into Thery crash and the "255" warning asap.
All the horse "bugs" happening while sitting or using #horse while not standing still are there because you are using a "client" horse. This means the server has no idea you are mounting it and also the players can't see it. When the #horse command will be removed, the server will ignore sitting commands for horses...I hope
No idea about the invisible legs bug.
-
Found this in my error log
unable to add an attached actor: illegal/missing actor definition 255It seem to get added every time an new player gets into view.
Asked a guildie and he has the same messages in his logs.
Are you using the latest cvs? It seems to be the protocol change needed for the next client update...
-
As Korrode said, the client is quite actively developed, but there is no place with long/mid-term projects info because they are usually decided by Radu with the programmer who codes them.
For what I know there are the following mid-term projects (mid-term as in "probably next update"):
- fight & ranging on horses
- larger textures and more character details
- new emotes and a pose system (many different stand/sit/walk animations)
For long-term (a.k.a "probably the update next to the next one"
)- dynamic map loading
- terrain engine
- city building
Mid-term projects are already quite advanced, most of them are in the cvs. I will start coding map loading and city building as soon as the new engine is ready.
-
ooops, it is a debug line that should have been removed
Cvs updated and thanks.
[During a resynch get_our_actor() can return null]
-
210k
-
Yes, it should work by simply adding lines like: <command>text</command>
(warning: no spaces allowed in "text")
-
Patch updated:
* Download again the actors definitions from the link above *
- in player_weapons.xml there is a new parameter "turn_horse" used to specify if the weapon requires the horse to rotate duting a fight (1=yes, 0=no)
- when a weapon is equipped the horse now turns (60 degrees) and lets the knight fight, if unequipped the horse turns back and fights directly
- a horse/knight synchronization has been corrected (may be some others around)
To test single actor commands or sequences of them you can use #send_cmd your_name x1 x2 x3... where x is a command code.
For reference, 18 is enter combat, 19 is leave combat, 38 to 45 are rotations, 5 is pain, 46 to 51 and 60 to 73 are attack frames.
Pls test
-
I commited some new code related to horse fighting. It's almost done, unless huge bugs pop out
To use it:
- enable MORE_ATTACHED_ACTORS & compile
- unzip the animations in your EL *test* directory under /animations
- unzip the actor definitions in your EL *test* directory under /actor_defs (crossbows not included, only bows)
- run the client and get/remove a horse by typing: #horse <your_name> 200
- only the horse with id=200 works, the other are missing frames in thei def files (I'm lazy)
Currently, when a fight starts while on horse a 45 degrees counterclockwise rotation is performed to put fighters face to face. I'm not sure if 45 is nice looking..I tried 90 and it is too much, maybe 60 is ok...however it can be changed in actors.h at line 450.
I tried fighting on horse against hordes of invaded rats and horse/actor animations never went out of timing...it's a good start, but please test this more, it's subtle code
*warning
the whole commit should be #ifdef'd, but while coding it I found something weird. At line 1086 of actor_scripts.c there were a "index+=18" used to get the frame corresponding to the current attack command for non enhanced actors. Looking at cal_types.h (line 44), since index starts from 0, the selected frame for attack_up_1 ends up to be cal_actor_combat_idle_frame, which is wrong. I changed the line to "index+=19" and it seems to work...either this is a bug or I deeply misunderstood some code
*warning 2
There is a massive amount of debug messages (may slow things down)
Idle Animations
in Programming
Posted · Report reply
I don't have time for this task, however I left some code here and there (under MORE_EMOTES) to handle animation blending programatically....good luck!