Jump to content

Question

Posted (edited)

Hi i am using fandc - mythras source and currently i have this movement bug issue

- i have geodata installed

- i tried to disable geodata but i still have the same issue

 

When i click somewhere to move for example i am getting camera relocation and backstep movements 

Also when i try to hit  a mob it stops on the first hit 

 

Here is a video explaining the issue! 

 

Edited by BloOdDiamOnD

8 answers to this question

Recommended Posts

  • 0
Posted (edited)

I can't tell you why it happens specifically on your own sources, since I got no available sources and no will to work on movement, but I can tell you why it happens : ValidatePosition sends you packet because the desync between client and server positions becomes too big.

 

About why desync becomes too big, I can't help you, and you probably won't get any answer in those forums until you accept to pay a talented developer to handle it.

 

On aCis, with the big emphasis about movement rework, some visual tools have been added in order to track such thing.

 

Shot00097.jpg

Edited by Tryskell
  • 0
Posted

If during the movement of the character he is periodically thrown back, then this means that there is a lot of desynchronization between the client and server speeds.

 

Now you knows the reason. Now try to fix it. Assume, what next question will "where i can find this problem place".

  • 0
Posted (edited)

@Tryskell @Rootware

No unfortunately i checked and changed the whole validate posititon code , tried the l2j's one, mobius one also but still nothing , this issue is very strange 

What could be another possibility for this?

Edited by BloOdDiamOnD
  • 0
Posted (edited)
9 minutes ago, BloOdDiamOnD said:

@Tryskell @Rootware

No unfortunately i checked and changed the whole validate posititon code , tried the l2j's one, mobius one also but still nothing , this issue is very strange 

What could be another possibility for this?

 

I told you, it's not about ValidatePosition. It's about how different your server<>client position desync is.

 

Since client position is, by default, not editable (and I don't speak about L2PHX and craftable thing), it means you got issues server side.

 

On the image I transfered, you can see green dots being client side location. If those points are too far from red, which is actual server side, then a "teleport" occurs to set back the Player on the track.

Edited by Tryskell
  • 0
Posted
59 minutes ago, BloOdDiamOnD said:

@Tryskell @Rootware

No unfortunately i checked and changed the whole validate posititon code , tried the l2j's one, mobius one also but still nothing , this issue is very strange 

What could be another possibility for this?

 

At first try compare speeds what uses server and what was sent to client in CharInfo packet. After check movement task.

  • 0
Posted

Ok solved, pack has nothing to do with  it after all it was Server related (hosted in france with high ping) 

I tried several packs on the domain server and still had the same issue.

 

I have tried the files on other pcs and works perfectly now.

lock it.

Guest
This topic is now closed to further replies.


  • Posts

    • UPDATE M63 Introduced the first major Party Logic system: Bots can join and operate under a real-player party leader. Party members: follow the real player, assist the leader in combat, coordinate around the party leader, support party combat instead of behaving purely as independent farmers. Added initial party formation/follow behavior. Added party-aware PvP assisting.   Expanded Party Support / Party Combat behavior: Improved party coordination across different bot classes. Added broader healer/support participation. Expanded combat equipment/ammunition support, including all six arrow grades. Party members became more coordinated in PvP and group combat. Added improved bot reaction to resurrection situations. Added compatible resurrection-answer handling. Refined party formation behavior. Party combat became more persistent when members were attacked. Party members maintain combat participation more reliably instead of immediately dropping engagement.     Major Party Logic expansion:   Changed party travel formation Added temporary main assister leadership: if the real-player leader dies, a random living damage dealer becomes combat leader, other bots assist that damage dealer, if the assister dies, another DD can take over. Added special Bishop/Cardinal real-player leader logic: bots continue following the real player, a damage-dealer bot becomes the party’s combat assister. Added 5-second idle Party Logic: if the real-player leader stops moving/actively controlling combat for 5 seconds, bots can resume autonomous farming around the leader. Temporary main assisters use the bot’s already configured PvP mode instead of a separate Party Logic PvP system. Existing modes remain authoritative: Idle AttackFlagged AttackEveryone Temporary main assister can independently acquire PvP targets according to its configured mode. Other party bots assist that selected combat leader. Made Party Logic target acquisition party-location aware. While operating in a party, autonomous PvE/PvP searches can be centered around the real player’s current location rather than only the bot’s original farming position. Existing bot farmRadius remains the effective acquisition radius. This allows parties to travel away from their original farming areas while continuing to operate dynamically.     Expanded Bishop/Cardinal Party Logic behavior:   Bishop/Cardinal parties now use the same 5-second activity/idle model as normal real-player-led parties. While the Bishop/Cardinal leader is moving or active: bots prioritize staying with the real player, maintain the ~70–100 unit random formation. After the Bishop/Cardinal remains idle for 5 seconds: party bots may return to autonomous farming around the leader. When the Bishop/Cardinal starts moving again: party members transition back to following the leader. PvP remains independent of the PvE idle condition: valid PvP targets can still trigger combat according to each bot’s configured PvP mode.     Optional Hero System: Added a new hero_enabled option for Autobots. Bot creation gained Hero appearance: No / Yes. Existing bots default to hero_enabled = 0. Bots with hero_enabled = 1 spawn with native Lucera Hero status/aura/appearance through Player.setHero(true). Hero weapons configured through the existing Autobots item system can be equipped normally. This is intentionally visual/status Hero only: no Hero skill injection, no automatic native Hero skills, no changes to combat AI or targeting. Hero state can also be changed directly in the database and takes effect after respawning the bot.     DOWNLOAD
    • Throw a free cloudflare SSL cert in there. 😄
    • Nextarget was a LT international clan in Dawn and  Evoke and other servers, playing most in Interlude, so dunno if you try use this name to atrack the players or smth.
    • Server Specs ChapterInterlude Classic EXP / SP Ratex50 Adena Ratex30 Drop Ratex20 Spoil Ratex15 Max Level78 Website https://l2nextarget.com/ Start On Today At 22:00
    • Since last forums fail, I decided to introduce a little website over PTS server holder - just to make basic informations more reachable. You can discover it over http://anothercrappyinterludeserver.com/   Discord channels ACCESS TO SOURCES and SERVER INSTALLATION were also reworked to be easier to handle.
  • Topics

×
×
  • Create New...

Important Information

This community uses essential cookies to function properly. Non-essential cookies and third-party services are used only with your consent. Read our Privacy Policy and We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue..