Jump to content
Eternal Lands Official Forums

Fedora

Members
 View Profile  See their activity

  • Content count

    547

  • Joined

  • Last visited

Posts posted by Fedora

  1. Posted · Report reply

    Gypsum is heavy, i know (harvested 200k+), but it has a meaning since exp from stones is very high (i get 420+ from a tiger stone...) and good money too. Imo weight of gypsum is there to make summoning the hard skill it was planned to be.

     

    As for being bagjumped, it happens (3 times to me at gypsum iirc, i know the feeling). Many ways exist to be safer: hyperbags, small gypsum bags, harv&mix, pay someone to bagsit...

  10. Posted · Report reply

    Dont know if this is related and i cant reproduce it at will, just happens sometimes: the mouse pointer seems to be shifted right with respect to the actual click point. You can check this by opening the storage window and passing the pointer over a row of items: you see the numbers changing when you are still over an item. Same problems with cursor change. However, exit and restart solves the issues most of the times.

     

    System: IBook G4, Tiger 10.4.11

  12. Posted · Report reply

    I noticed that, expecially on big monitors, a click on the visible terrain don't lead to character movement unless it's very close to the character. I searched through the code but cant find a check about clicked coords (something like an allowed walking area/radius). Instead it seems that after a click the coords are sent to the server that calculates a path only if the click it's not far away (just figuring things, not sure).

     

    On the other hand when we click on the 2d map the client calculates a path and follows it (in synch with the server).

     

    Now, why dont we use the pathfinder for 3d map too? This way all visible tiles would be reachable. Needed changes are easy (use pf_find_path instead of move_to).

     

     

    Second issue with pathfinder is that when you are walking and click on a door/npc/resource which is too far to be used, you stop walking. This is because in click_game_handler (gamewin.c, line 580) we call pf_destroy_path. Is there a reason or we can remove it and let the char keep walking? (or just stop it if the action is successful).

     

    I can provide a patch if you find the above issues meaningful.

  14. Posted · Edited by Fedora · Report reply 

    gamewin.c:828: error: 'struct <anonymous>' has no member named 'range_target'
gamewin.c:829: error: 'struct <anonymous>' has no member named 'range_target'

     

     

    I get this when compiling with MISSILES & DEBUG. It seems something related to the recent commit by Schmurk.

     

     

     

    EDIT: also the "cvs update" doesn't provide elglext.h...am i doing something wrong?

  20. Posted · Report reply

    The problem is that the bounding box is not calculated every frame now, for speed reasons.

    Ideally, we should use real collision detection for this purpose, the method we use now is very slow.

     

    Actually the latest commit by Xaphier calculate the bbox every frame (cal.c, line 455), and yes it is slow (and my hardware sucks too...)

     

     

    @bluap: you sure that banners are fixed? i still have too high banners for some mobs (cycs, armed orcs...) and still the "jumping" problem during combat. Not sure, but could this depend on the way bbox are calculated? In build_actor_bounding_box (actor_init.cpp, line 590) we calculate bbox with cal3d functions and then we enlarge it by 25%...is there a reason for this?

  21. Posted · Edited by Fedora · Report reply

    I noticed the same too. I think it depends on bboxes. In function get_actors_in_range (actors.c) bbox is translated according to actor position but not rotated. I added this:

     

    memcpy(&bbox, &actors_list->bbox, sizeof(AABBOX));

    rotate_aabb(&bbox, actors_list->tmp.x_rot, actors_list->tmp.y_rot, 180.0f-actors_list->tmp.z_rot);

     

    just before the VAdd(...) and it seems to work fine.

     

    However i think bbox should not be used to determine actor->max_z (line 709) because this way banners are displayed at the highest z and during animations (fight ones) they jump, following mobs weapons like this (white lines are bboxes)

     

     

    I'm not deep in this part of the client, however I suggest to use the zpos of "highest_bone" (defined in skeletons.c) to determine actor->max_z.

     

     

    Hope this helps.

  23. Posted · Report reply

    Highest_bone works nicely. You are right about the bounding box problem. I modified draw_actor to display the boundibox of monsters and it seems that for birds the height from ground is not added (the bounding box moves on the ground under them).

     

    I tried to figure out where the height is set and i saw a couple of lines like this:

     

     

    z_pos=actor->tmp.z_pos;

    .

    .

    .

    if(z_pos==0.0f)//actor is walking, as opposed to flying, get the height underneath

    z_pos=-2.2f+height_map[actor_id->tmp.y_tile_pos*tile_map_size_x*6+actor_id->tmp.x_tile_pos]*0.2f;

     

     

    however a printf before and after shows that z_pos is always 0 for every monster, even for birds. Maybe the bbox is calculated in a space before the height translation (cal3d functions are undocumented)? Any ideas?

     

    I noticed that my cal_get_maxz works on CalSkeleton and CalBone functions, while build_actor_bounding_box uses CalCoreSkeleton and CalCoreBone...what is the difference exactly?

     

    Still investigating...

×