bugBattle for Wesnoth - Bugs: bug #21966, OOS - "unfound location for...

 
 
Show feedback again

bug #21966: OOS - "unfound location for source of movement"

Submitted by:  SlowThinker <slowthinker>
Submitted on:  Thu 24 Apr 2014 12:49:21 PM UTC  
 
Category: BugSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Multiplayer
Status: Need InfoPrivacy: Public
Assigned to: NoneOpen/Closed: Open
Release: 1.10.xOperating System: unknown

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Sat 07 Jun 2014 09:30:55 PM UTC, comment #21:

Yes those lines look correct.

i dont know exactly how this was handled in in 1.10.x but in 1.11.13+ not executing the complete move if it was stopped by any reason is exactly the expected behaviour.
(The following is molst likely not true for 1.10.x versios)
Let A be te currently acitve side and B be the other side.
The reason is:

In 1.11.15+ it might happen, if side A does a movement, that the movement action is sended to client B before it's execution is finished on client A. This happens if a mp_sync (random/[message][option]/ ...) is used durign teh move (enter_hex events). Especialy side 1 doesn't know how far the movement will go (wheter it will be stopped by sighted event especialy), so it just sends the full movement an relies on the other side calculating the same destination hex. If this is not the case then the OOS will not be detected now.

If the movement doesn't invoke mp_sync (this is especialy true for all undoable moves) then client A knows where the movemnt ended when it sends it, becasue it is sended later. In this case it still sends the data of the full (possibly not completed) move and relies on the other side calculating the same destination hex, but it also adds some checkup data so that the other client can veryfy wheter the destination hexes are the same on both client and give an oos message if thats not the case.

Daniel <gfgtdf>
Project Member
Sat 07 Jun 2014 03:22:28 PM UTC, comment #20:

@ any Wesnoth dev:

so what exactly happened? Are next lines correct?

- In turn 3 Blop's client allowed a too long move (for an unknown reason).
- The move has been sent via the network (and it was stored in the replay)
- The Quietude's client received the too long move and cut it. But it didn't raise any exception/error/OOS at this moment.
- The OOS appeared next turn (turn 4), when the clients expected the unit to stand on different locations and the unit moved.

And in case the lines above are correct, is the behaviour of the Quietude's client intended or is it a bug? (I mean the Quietude's client ignored the problem in turn 3)

SlowThinker <slowthinker>
Tue 03 Jun 2014 07:54:54 PM UTC, comment #19:

a militia needs 2 moves on a bridge.

see comment #15, the OOS happened before you teleported.
I guess the OOS was caused when Quietude's client didn't find a militia on the source hex of a movement - 5,51 (it expected the militia at 5,52)

SlowThinker <slowthinker>
Tue 03 Jun 2014 06:48:59 PM UTC, comment #18:

It was a 3 versus 3, so side 5 was a player side.

I just read your first post again and realised that you are talking about turn 3.
6,55 is a brigde (flat) in the replay and also as far as I know.
So the militia moved to 5,51.

However, the error did occur after I had teleported the turn after.

Felix <blob>
Tue 03 Jun 2014 04:26:29 PM UTC, comment #17:

I am confused:

it looks Blop was the hosts:

it looks Quietude was the host, at least when the game ended:
Explanation: Side 5 is an AI side, and the host should control it.
Blop might disconnect during the game and so lose the control, but a search of a string "disco" yields no result. Or is there another string that one needs to look for?

SlowThinker <slowthinker>
Tue 03 Jun 2014 02:17:48 PM UTC, comment #16:

from which file was the game reloaded? Meaning which side saved the game that was reloaded later ?

Anonymous
Tue 03 Jun 2014 11:22:16 AM UTC, comment #15:

1.
Blop, do you remember whether your militia ended at 5,51 or 5,52 in turn 3?

2.
I just realized the save of your reloaded game won't help.
(Details:
I downloaded your reloaded game from
http://replays.wesnoth.org/1.10/20140423/Conquest-_Surdmark_(telep.,_long_dist.)_+__(requires_Conquest_Minus_or_AE)_Turn_9_(11274).gz
(there are problems with the replay, but it has nothing common with our problem: it happens because of https://gna.org/bugs/?19603)

The file still contains the too long move of a green militia in turn 3, and the OOS in turn 4:
... but it didn't spoil your game because it happened prior to the game start.

)

SlowThinker <slowthinker>
Tue 03 Jun 2014 10:21:27 AM UTC, comment #14:

Precisely turn 4, side 3 (green), just like I said.
There was no "corruption" in my save after the OOS and I indeed think that I did the reload.

Felix <blob>
Tue 03 Jun 2014 09:48:11 AM UTC, comment #13:

I meant: at which turn/side did you start the reloaded game (and got no problems anymore)?

SlowThinker <slowthinker>
Tue 03 Jun 2014 12:50:04 AM UTC, comment #12:

It was right after the error occurred (turn 4).
As the unit moved correctly for my side, the reload resolved the OOS.
I had only moved another one unit and had not yet recruited.

Felix <blob>
Mon 02 Jun 2014 11:10:39 PM UTC, comment #11:

Blop, the game you reloaded (and that was not corrupted) was from which turn?

SlowThinker <slowthinker>
Mon 02 Jun 2014 11:05:01 PM UTC, comment #10:

I will try to reconstruct what was happening, in my best knowledge:

I was not the host of the initial game.
The error occurred right when I moved the spearman that just got teleported.
I did not encounter any errors prior to that and the error did not reappear afterwards.
The error was resolved by reloading.
Apparently I do have a save, but only after the reload has happened and during purple's turn 4 start.
And I do not cheat or use any other modifications.

Regards, Blop

Felix <blob>
Mon 02 Jun 2014 10:58:42 PM UTC, comment #9:

I will try to reconstruct what was happening, in my best knowledge:

I was not the host in the initial game.
The error occurred right when I moved the spearman that just got teleported.
I did not encounter any errors prior to that and the error did not reappear afterwards.
The error was resolved by reloading.
Apparently I do have a save, but only after the reload has happened and during purple's turn 4 start.
And I do not cheat or use any other modifications.

Regards, Blop

Anonymous
Mon 02 Jun 2014 02:25:16 PM UTC, comment #8:

@Anonymous:
My save is from replays.wesnoth.org, and I think players didn't have when they informed me about the problem.

>It is also possile that ... this is related to your addon.

I checked all use of u.max_moves and manipulation with u.moves:
In one moment of turn 1 I reset moves to max_moves in a moveto event. But then the event is removed.
It could cause a problem only if BfW was buggy and would resuscitate the mentioned moveto event.

@Blop (the green player):
You wasn't the host, right?
Did you mention any problem prior the OOS in turn 4?
You have no your own save of the game?

SlowThinker <slowthinker>
Mon 02 Jun 2014 01:01:10 PM UTC, comment #7:

well its known that OOS error messages appear as soon as you use the currupted data not in the moment when that data is created and thats where the actual error happened.

If the is a too long [move] in the replay then stopping erarly is exactly the intended behaviour.

It is for example possile that a unit can move 7 moves and the player invoked a move and was halted by a "enemy unit sighted" in this case (at least in 1.11.13+) the replay also contains a move that was not completed (7 moves) and stopping eralier on all clients thus not causing oos in the intended behaviour. In your case it this might not be the case but also giving an OOS message if a unit stops due to lack of moves left cannot be done like that, because it is for exampe possile that an wml enter_hex event lowered the number of moves of the unit.

If we want to know "why this happens"/"how we can fix that"
then we need to know why the other client caclulated such a move as possible (or why the unit had a different muber of max_moves on the other client). It is also possile that this has been fixed in 1.11+ or that this is related to your addon.

Do you get the same error when you watch a replay that he saved and in a replay that you saved?

Anonymous
Mon 02 Jun 2014 09:57:09 AM UTC, comment #6:

>well the reason seems to be that somewhere an impossible move was issured. Which usualy causes an OOS.


Maybe you didn't read my original submission in a detail. The first problem happened prior to the OOS:
- it looks until turn 3 of the green side everything is OK
- turn 3 of the green side appears OK if you watch the replay visually, but [move] in the savefile doesn't correspond to the visual replay
- only in turn 4 of the green side the OOS is fired.

(More info can give you the original player who controlled the green side: his name is Blop, he is registered in the Wesnoth forums, and I just sent him a link to this gna page.

But I suspect he won't give you more info than me:
I think his turn 3 appeared to be OK, exactly as my replay of turn 3 appeared OK.
)

SlowThinker <slowthinker>
Sun 01 Jun 2014 09:30:22 PM UTC, comment #5:

well the reason seems to be that somewhere an impossible move was issured. Which usualy causes an OOS. I don't know the reason and i already said my 2 guesses below. Without way to reproduce the reason for the invalid move on the replay there is nothing we can do.

Marked as need info.

Daniel <gfgtdf>
Project Member
Fri 25 Apr 2014 10:10:50 PM UTC, comment #4:

I didn't play the game, but players informed me because I was the maintainer of the add-on.

>"unit moves=n cheat"

I don't understand ... You mean he could cheat? No, I know him, he is a serious player.

One more info: the player who moved the unit was not the host very likely (I am sure he wasn't the host in the game beginnning)

SlowThinker

Anonymous
Fri 25 Apr 2014 09:41:21 PM UTC, comment #3:

did you own the unit during the original game ? Or could it be the the player who owned the unit just used a unit moves=n cheat?

Anonymous
Thu 24 Apr 2014 04:18:07 PM UTC, comment #2:

> that rather ssems to be a bug during the original game than in the replay.

Yes, the OOS was reported in the game already (and again in the replay).

>i sometimes have such errors when the unit got a "quick" trait in the original game

The unit that caused OOS was resilient+strong.
(In fact these traits were not full traits:
In Conquest Minus I clear all traits from a variable before [unstore_unit] is applied, but Game Inspector still shows them and one of them ('healthy') keeps its effect. No trait is shown to players in the right-side panel.
)

SlowThinker <slowthinker>
Thu 24 Apr 2014 02:43:03 PM UTC, comment #1:

i sometimes have such errors when the unit got a "quick" trait in the original game, but not ine the replay due to OOS in the rng. But i suppose since your unit already has 7 moves in the replay that might not be the case.
If the unit was able to walk to 5,51 that rather ssems to be a bug during the original game than in the replay.

Anonymous
Thu 24 Apr 2014 12:49:21 PM UTC, original submission:

Summary: an impossible movement of a unit is registered and saved into a replay, and next turn it causes an OOS error "unfound location for source of movement"

Look at this replay
http://replays.wesnoth.org/1.10/20140423/Conquest-_Surdmark_(telep.,_long_dist.)_+__(requires_Conquest_Minus_or_AE)_Turn_4_(11243).gz
and this move of the greenside in turn 3:
This move was impossible because Spearman had 7 movepoints and the cost of x,y=6,55 was 2 movepoints.

The replay is correct visually, and the unit ends at 5,52 in place of the impossible hex 5,51.

But in turn 4 of the green side this mismatch causes this OOS error:
unfound location for source of movement: 5,51 -> 2,50

A note: I encountered this OOS warning during past years in various Wesnoth games, although it was very sparse.

SlowThinker <slowthinker>

 

(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by blob (Posted a comment)
  • -unavailable- added by gfgtdf (Posted a comment)
  • -unavailable- added by slowthinker (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 01 Jun 2014 09:30:22 PM UTCgfgtdfStatusNone=>Need Info
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup