Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ships display lags behind real position or is totally wrong (master branch) #2859

Open
yhoyhoj opened this Issue Jul 2, 2018 · 15 comments

Comments

Projects
None yet
4 participants
@yhoyhoj
Copy link

yhoyhoj commented Jul 2, 2018

Master branch on Archlinux.
After ordering a ship to move, it will often stay in place on the display while its position on the map changes.
The ship can then apparently keep an offset for some time. It can end up being displayed on the islands.

How to reproduce: start a game, move ship.

Screenshot 1: Ship position on the display is not the same as on the minimap. I believe the minimap is right and that it is the main display that is wrong.
2018-07-02 18-48-33 120988
Screenshot 2: AI ship is on the island. It is not clear but I think the minimap shows it right next to the island.
2018-07-02 18-52-49 651280

@LinuxDonald

This comment has been minimized.

Copy link
Member

LinuxDonald commented Jul 2, 2018

yeah the minimap needs to be fixed.

@LinuxDonald LinuxDonald added this to the 2018.1 milestone Jul 2, 2018

@jmdejong

This comment has been minimized.

Copy link
Contributor

jmdejong commented Jul 2, 2018

Weird, I've never seen this and I can't reproduce it (with the same setup).

Does anything change when you rotate, move or zoom the main map view?
Are atlases enabled?
Does UH print anything to the console when you start a game?
Does it happen in all maps you play? If not, could you share your save?
Does it also happen when you start uh with the command line option --start-random-map?

@LinuxDonald What should be fixed about the minimap? Maybe the ship icons could be drawn a little higher, but I don't think that's the problem here.

@LinuxDonald

This comment has been minimized.

Copy link
Member

LinuxDonald commented Jul 2, 2018

Could we not scale down all the information from the main map and load the information on the minimap?

@yhoyhoj

This comment has been minimized.

Copy link
Author

yhoyhoj commented Jul 3, 2018

No output, except : "Ship created and weapons loaded." when the game starts.
After some further investigation, it doesn't happen all the time.
It doesn't with --start-random-map but it does when starting a random map from the menu.
It doesn't when playing a scenario (the_Unknown or tutorial).
It does in Free Play.

Zooming or moving the ship out of view and then in will not change anything. The ship keeps its glitched position until it is moved.
I am not sure but it looks like the ship sprite will sometimes play catch-up with the real position and the offset will vary during a move (the ship trajectory on the minimap and the sprite trajectory will not be the same, in this case, but they meet. Not always when the ship reach the position it is supposed to move to, though).

All ships are affected : player, AI player, free trader and I suppose pirate, but I could not verify.

@jmdejong

This comment has been minimized.

Copy link
Contributor

jmdejong commented Jul 3, 2018

Does the ship also do normal movement when it's in the wrong position? Or does it just stand still and sometimes jump ahead?

What happens when you rotate the view? Does the ship stay on the same place on the map or does it rotate around the place where it should be?

Have you changed any settings? You can find your settings in $HOME/.config/unknown-horizons/settings.xml. Is anything different than in the default settings?

Does this only apply to ships? Or have you seen this with other units as well (the inhabitants that walk on the roads, the collectors etc.)?

Did you install the game through git? If so, could you try if the problem also exists in older versions?

@yhoyhoj

This comment has been minimized.

Copy link
Author

yhoyhoj commented Jul 3, 2018

When instructing a ship to move, it will stay stuck for a certain amount of time (a split second to several seconds) then start moving. When stuck the ship rotates, I think it is the rotation it should have if it was displayed at the right position.
During a movement, the ship will move normally (but with an offset) or it can get stuck again, increasing the offset to the real position. It sometimes start moving normally after a right click and then get stuck for some time during the movement.

Rotating the map doesn't change the glitched position, the ship sprite rotates normally (stay at the same glitched position).

My settings are slightly changed but it was all done from the menus (diff : https://gist.github.com/yhoyhoj/6f9367e2d74c534a8542dfc3691661bb).

It also applies to fishing boats and resource collectors, maybe normal settlers too but it is difficult so see. Also it is confirmed for pirate ships.
Concerning the resource collectors, it has made clear that the sprite tries to catches up to the real position by taking a shorter path : I have seen a collector move diagonally instead of following a "diagonal with angles" road.

I cannot easily install an older version because the older version of fife and fifechan required for 2017.2 conflict with the new versions. I can test check out an older commit with git.
By the way, I also use the master branch of fife, is that your case ?

Additional info :
I have checked that range is calculated with the real position and not the glitched sprite position by building a settlement with a glitched ship that appeared far away from the island.

@yhoyhoj

This comment has been minimized.

Copy link
Author

yhoyhoj commented Jul 3, 2018

The problem exists also with HEAD at 0280e7a which is the older I can go with my current setup.

@yhoyhoj

This comment has been minimized.

Copy link
Author

yhoyhoj commented Jul 10, 2018

Nobody is able to reproduce that with the master branch of fife ?

@LinuxDonald

This comment has been minimized.

Copy link
Member

LinuxDonald commented Jul 10, 2018

Not yet tested

@yhoyhoj

This comment has been minimized.

Copy link
Author

yhoyhoj commented Jul 18, 2018

It would be interesting to have the version of fife used by people that can't reproduce this bug.
Would you mind telling us @jmdejong ?

@jmdejong

This comment has been minimized.

Copy link
Contributor

jmdejong commented Jul 23, 2018

I have tried to reproduce this with the latest version of UH, Fife, and Fifechan (or at least what was the latest version at that moment 20 days ago).
I have also tried a few older versions.

I have been unable to reproduce the bug or to find a likely explanations for this so far

@Rootyjr

This comment has been minimized.

Copy link
Contributor

Rootyjr commented Jul 28, 2018

I got some photos and a savefile for this bug when it occurred on my machine running Arch Linux. I am running fife and fifechan from git. When I encountered this I did a search and found an old issue that I thought might be worth mentioning: #1203

I was also playing a randomly generated map.

Notes regarding save: Ships don't float through land immediately. Just speed up the game and move your ship around a bit and after a little while a ship will clip through the island. The trader ship is more likely to clip farther through land.
fssave.sqlite.zip

Photos:
bug1
bug2
bug3
bug4

@jmdejong

This comment has been minimized.

Copy link
Contributor

jmdejong commented Jul 29, 2018

With this savefile I have been able to reproduce the problem, thanks!

I have also found the place where the problem would probably be:

def _move_tick(self, resume=False):
"""Called by the scheduler, moves the unit one step for this tick.
"""
assert self._next_target is not None
if self._fife_location1 is None:
# this data structure is needed multiple times, only create once
self._fife_location1 = fife.Location(self._instance.getLocationRef().getLayer())
self._fife_location2 = fife.Location(self._instance.getLocationRef().getLayer())
if resume:
self.__is_moving = True
else:
#self.log.debug("%s move tick from %s to %s", self, self.last_position, self._next_target)
self.last_position = self.position
self.position = self._next_target
self._changed()
# try to get next step, handle a blocked path
while self._next_target == self.position:
try:
self._next_target = self.path.get_next_step()
except PathBlockedError:
# if we are trying to resume and it isn't possible then we need to raise it again
if resume:
raise
self.log.debug("path is blocked")
self.log.debug("owner: %s", self.owner)
self.__is_moving = False
self._next_target = self.position
if self.blocked_callbacks:
self.log.debug('PATH FOR UNIT %s is blocked. Calling blocked_callback', self)
self.blocked_callbacks.execute()
else:
# generic solution: retry in 2 secs
self.log.debug('PATH FOR UNIT %s is blocked. Retry in 2 secs', self)
# technically, the ship doesn't move, but it is in the process of moving,
# as it will continue soon in general. Needed in border cases for add_move_callback
self.__is_moving = True
Scheduler().add_new_object(self._move_tick, self,
GAME_SPEED.TICKS_PER_SECOND * 2)
self.log.debug("Unit %s: path is blocked, no way around", self)
return
if self._next_target is None:
self._movement_finished()
return
else:
self.__is_moving = True
#setup movement
move_time = self.get_unit_velocity()
UnitClass.ensure_action_loaded(self._action_set_id, self._move_action) # lazy load move action
self._exact_model_coords1.set(self.position.x, self.position.y, 0)
self._fife_location1.setExactLayerCoordinates(self._exact_model_coords1)
self._exact_model_coords2.set(self._next_target.x, self._next_target.y, 0)
self._fife_location2.setExactLayerCoordinates(self._exact_model_coords2)
self._route = fife.Route(self._fife_location1, self._fife_location2)
# TODO/HACK the *5 provides slightly less flickery behavior of the moving
# objects. This should be fixed properly by using the fife pathfinder for
# the entire route and task
location_list = fife.LocationList([self._fife_location2] * 5)
self._route.setPath(location_list)
self.act(self._move_action)
diagonal = self._next_target.x != self.position.x and self._next_target.y != self.position.y
speed = float(self.session.timer.get_ticks(1)) / move_time[0]
action = self._instance.getCurrentAction().getId()
self._instance.follow(action, self._route, speed)
#self.log.debug("%s registering move tick in %s ticks", self, move_time[int(diagonal)])
Scheduler().add_new_object(self._move_tick, self, move_time[int(diagonal)])
# check if a conditional callback becomes true
for cond in list(self._conditional_callbacks.keys()): # iterate of copy of keys to be able to delete
if cond():
# start callback when this function is done
Scheduler().add_new_object(self._conditional_callbacks[cond], self)
del self._conditional_callbacks[cond]

As far as I understand it now:

The movement and pathfinding of the ships (and other units) happens in the python code.
This code only works with integer coordinates and updates once every few steps.
Because this would look very shocky when drawn (since the ships would jump from one square to another without staying in between) the Fife pathfinding is used to visually move the ship from one square to the next.
However, the Fife pathfinding can do a lot by itself and there is also a lot that can go wrong there.
Somehow some movements do not happen and when it can move again it will move in a straight line to the correct position.

I believe that the easiest solution would be to set the location of the fife instance to the actual position of the ship whenever a new step is taken.
The worst that could happen then is that the ship jumps from one square to another.

Another solution would be to make the actual position also work with non-integer coordinates.
This would make the pathfinding somewhat more complicated and maybe more things as well.

@LinuxDonald

This comment has been minimized.

Copy link
Member

LinuxDonald commented Jul 29, 2018

@jmdejong do you intressted to work on it/fix it?

@jmdejong

This comment has been minimized.

Copy link
Contributor

jmdejong commented Jul 29, 2018

Fixing the underlying problem in a clean way would require either a lot of fife troubleshooting to make sure both pathfinders work well together, or it would require to replace the fife pathfinding with another mechanism to smooth movement.

Currently I'm not going to do that, but I can make sure that the locations sync up if they would get too far apart, effectively solving the symptoms of this problem.

The ships/units might jump a square sometimes, but if the problem is rare enough, that won't be noticable.
Also, the problem would be most common when the game is sped up, and in that case you wouldn't notice a little jump anyways.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.