bugBattle for Wesnoth - Bugs: bug #21082, Replay crash (exits wesnoth) in...

 
 
Show feedback again

bug #21082: Replay crash (exits wesnoth) in Legend of Wesmere, scenario 3

Submitted by:  Tan <tanthree>
Submitted on:  Fri 30 Aug 2013 08:39:16 PM UTC  
 
Category: BugSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Replays
Status: InvalidPrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Release: 1.10.6Operating System: debian sid

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

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

 

Sat 12 Apr 2014 07:17:09 AM UTC, comment #3:

Hello again.
Long time no read.
In the past 7 months I have been playing through a total of 15 campaigns between mainline and unofficial/add-ons, since 1.10.2. Three months ago I updated to stable 1.10.7. I decided to re-replay those replaysaves, as well as those replaysaves I collected from playing up to current date, just for the sake of checking progress myself.
Only a pair replaysaves for scenarios, from TRoW (rise of W) finally played fine, no issues; the rest of them are messed up because of cheating, and I found the culprit -more details in following lines. (One scenario is when Haldric I fights the nagas just after the dragons; the other is in the trolls cave after meeting elfic Kalian: enemies movements follows the same order as replaysave code; but unfortunately cannot remember the issue with there replaysaves)
The rest of problematic replaysaves stay the same, messing up somewhere during the replay.
Well ...
Lets just say I want to share my experience when meeting issues due to cheating.
After giving myself a view of replaysave's WML-code, the text/plain inside a replaysave file, and with a little of patience and time, I got some understanding of the effect of cheating over replaysaves. I can give a summary of my findings when reading the WML code of the troublesome replaysaves:

1st
During most of my playthrough, I DID mess with some units' movements. I realized that when cheating using 'unit movements=<value>', one does not change the restrictions that the current terrain aplies to the unit in question.
For example, lets say 'UnitA' has max_movements=5 in its feature/parameters file, in /units directory of the campaign presumablely. Next, during a play of a certain scenario with ':debug', I select that UnitA, then ':unit movements=8' so to change its avalaible movements to 8 ('its', referring to the UnitA), then I make UnitA do the move, for instance during Turn 11 of 20, using all its movements only during that Turn. Lets say also, my UnitA was in position (1,1), and the move's destination is (4,4) using the original max_movements, and (6,6) with the modified mnax_movements=8, and assume a particular terrain. The replaysave stores this sequence of movements, i.e. the cheated one, with destination at (6,6). Next, lets say I finished that scenario, so the replaysave is created afterwards. I then replay that replaysave, all Ok during the first 10 turns (I tell you, I let the replay fastforward until the Turn Number of interest, estimated in time --a feature for replayview that makes me select "play replay until turn number=##" would come in handy here--); then at Turn 11, my UnitA is replaying its move. At the time using my own replaysaves I could not make realize of which units did which movements at which turn: paralel viewing replaysave + replaysave code line-by-line was out of question for me, so I let the game telling me hints of out-of-sync. For this example, that hint came at Turn 12, where the message read something amnong the lines of
"(6,6): Unknown source of movement/attack"
(Note the hardship: it does not Tell me WHICH unit!)
(Example "Unknown source of movement/attack for UnitA" would be very helpful, instead of guessing which unit, or paralel-viewing replaysave + code)
I discovered this by changing parameters/movements for only one unit during :debug, the rest of units are not modified through cheating, finished a certain easy scenario, and then playing the corresponding replaysave. After the fact, I revised through many of the problematic replaysaves I stored during this time, confirming the discovery.
SOLUTION for this issue involves manual-editing the replaysaves' code (not hard at all, but surely timeconsuming), or playing the entire scenario again with no tampering of 'movements=##'.

2nd
If DURING a scenario play I tamper with the aquatic "squid" units, or in general any unit whose attack has the "swarm" attribute, then the replaysaves with those units are always screwed. I guess it has to do with the number of hits VS HP numeric relationship.
For example, suppose 'SquidA' with HP=1 of a max_hitpoints=60 (that means HP= 1/60) receives a unsucessful attack from 'TrollWarrior', the two hammerhits do not hit the poor SquidA. And SquidA does not reply/retaliate. Because the code does not allow a HP=1's squid to counterattack. At maxHP, the SquidA uses 10 swarm attacks, as its max_hitpoints=60 allow, so it means (assuming linearity) one hit avalaible per 6 HP, so zero chances to counterattack with HP<6. That gives problems if my tampered SquidA shows HP=-221 (negative) during the replaysave, when during the playthrough I modified it to be HP=282 !. With this HP my SquidA CAN reply any physical attack, and it was stored in the replaysave, but somehow when meeting those unallowed numeric values result of tampering/cheating, playing the replaysave discards the sequence. And that means "unexpected behavior".
I realized this fact in "The rise of elementals" UMC campaign, with the "wirlwind" units. Applies also to any play with swarm-attack units (e.g. "Inky's Quest")
SOLUTION: (easy) set SquidA's max_hitpoints BEFORE starting scenario, or modify SquidA's parameter file; (hard) playthrough with no cheating of those involved units.

3rd
There are some custom-crafted scenarios, all except one up-to-now from UMC campaigns, where one can't simply play the replaysave normally, because that replaysave was not written properly to begin with! Best solution I found is to play with care when using cheats! In others, it's just a matter of luck, meeting a rare condition which triggers undesired behavior.
Let me cite some examples from my own:
First from mainline,
**LdW-El_asedio_del_Ka’lian (LoW -Siege of Ka'lian)
Something changed between versions (1.10.2) and (1.10.6), somehow it continues to crash at Turn 4.
error replay: unfound location for source of movement: 32,6 -> 31,10
warning replay: Warning: Missing path data found in [move]
error display: Tile at 33,10 isn't on the map, can't scroll to the tile.
warning replay: Warning: Missing path data found in [move]
warning replay: Warning: Missing path data found in [move]
error replay: unfound location for source of movement: 32,7 -> 27,7
error replay: unfound location for source of movement: 32,7 -> 27,6
warning replay: Warning: Missing path data found in [move]
error replay: unfound location for source of movement: 32,9 -> 32,4
error replay: unfound location for source of movement: 32,10 -> 29,11
error replay: unfound location for source of movement: 32,10 -> 29,9
error replay: unfound location for source of movement: 31,10 -> 26,11
wesnoth: /build/wesnoth-1.10-VyABRP/wesnoth-1.10-1.10.7/src/actions.cpp:613: void place_recruit(const unit&, const map_location&, const map_location&, bool, bool, bool, bool, bool): La declaraci?n `resources::units->count(recruit_location) == 0' no se cumple.
Abortado
So, it is campaign-dependand, and thus NOT-A-BUG it seems.
Following next are some examples from UMC campaigns:
**S-Healer_And_Slayer_repetición (from UMC-Swamplings)
Part 2 of scenario, after taming 5 bats, does not start because characters (goblin & whitemage) do not reposition to their stud/campament; so the scene where the whitemage dies poisoned and the goblin selecting some potion does in fact not play in the replaysave.
**S-Meet_Mister_Blydd_repetición
Turn 21 (or whichever turn where goblin/bomber almost set-off the bomb), replaysave complains with " illegal recall:'Pronk' not found within recall list".
Pronk is a unit stored from previous scenarios from this campaign, and all replaysaves for scenarios within this campaign where I recall Pronk always complains with this message in the event of recalling him.
**SE-The_Swampland_repetición (from UMC- Saving Elensefar)
Unreplayable: othelo game is 2-turns per player, SO replaysave only does movements for Player, and not Computer, rendering indeed unreplayable in any form.
Solution is in the hands of this campaign's maintainer. No cheats involved nor needed in any way.
**SE-Isle_of_Alduin_repetición
Uunreplayable: side-2 units do not move.
I.e. mages does not come out from houses. And computer's units gets in the way of houses. Events happened during play, that replaysave did not store.
**FoaP-Fate_of_a_Princess_repetición (from UMC- Fate of a Princess)
This one is interesting.
At (14,23) there is a teleport. In the replaysave a certain unit (for ex. a Shyde) there did not move because teleport's destination at (2,16) was already occupied, where in the original playthrough, if such destination is already occupied, the next unit that steps in (14,23) emerges at any non-occupied hex next to (2,16), lets say, (1,16). This "any" hex could not be stored in the replaysave as a value result of evaluation or a random one, because it would make invalid the purpose of a replaysave, to store every movement as a fixed, constant set of parameters, and not variable, unknown ones. The teleport instantly teleports without taking into account a fixed destination fro the replaysave to store.
Temporal solution is to add a [move][/move] line in the replaysave with a new "teleport" move to a fixed position, for the involving unit, in this case the Shyde.
Again, campaign design. Or I just had bad luck. And no movements=## used here.
**RotE-Guild_Entry_repetición (from UMC- Rise of the Elementals)
Replaysave cannot call elementals (campaign-dependence~?)
Explanation: the elementals simply do not appear in the replay: Vallin stands there alone in the cave doing its movements correctly. Replay does not finish properly because defeatins some elementals trigger next event, which in this case of replaysave, the event never comes.
**RotE-Revenge_repetición
Messed from turn 4 onwards: Mal-arthim does not turn into wisp upon destruction (campaign-dependence~?)
In playthrough: killing any unit with a Wisp for the first time, converts the slayed unit into a new wisp. In replaysave: no new Wisp is generated through killing with Wisps, so conflict with present units arises for replaysave.
**DalO-Un_embrujo_en_invierno_repetición (DiD -Haunting in Winter)
When rebel ghost appears, it kills mine's, as if invalidating HP cheating.
Does not happen when playing cleanly i.e. without cheats.
**Militia-The_Fair_repetición
UNREPLAYABLE NORMALLY: transform effect of Potion.of.Polymorph (PoP) is random/non deterministic.
Explanation: when I watch replaysave in some afternoon, unit who gets PoP transforms into Unit#463. When re-playing replaysave during some other afternoon or evening, the very same unit transforms instead into Unit#864. So NOT-A-BUG, mostly campaign-design.
**Militia-World_War_repetición
UNREPLAYABLE: Terrain is randomly selected once unit steps on a canvas tile; team leader's selected terrains include castle-wall-like tile, inaccessible to every unit, so movements towards those uncovered terrains are all void.
UNREPLAYABLE without care: avoid moving leader unit until most canvas-terrains are uncovered ->
DISCOVER: do NOT delete ANY autosaves until scenario finished. [mostly SOLVED]
So, DO NOT DELETE AUTOMATIC SAVES MANUALLY until after the scenario is finished.
Tested: if I'm at Turn 53, with autosave#53 to autosave#1, those 53 files using space, then close program, next morning I reload replaysave from autosave#53 AFTER deleting autosave#1 to autosave#50. During replaysave, the canvas tiles when stepped on, they transform into different terrain than originally, thus causing problems during replayview.
Those are the most relevant examples.

4th
Finally, ANY replaysave involving scenarios WITHOUT A MAP, are ALWAYS bound to crash the program.
Though there are replaysaves for certain nonmap scenarios where playing replaysave always load "empty" map i.e. a map with no events or objectives; only those do not make wesnoth crash.
SO, those 5 attachments are in fact replaysaves for non-map scenarios. Besides, their text sintax are different from the normal, scenarios-with-map ones.

So in the end, now I do not consider my original post to be related to bugs in the main program. Instead, an inability of this wesnoth program to replay picture-scene-only scenarios with no-map is a possibility here. My conclusion is that, being in the stable branch of program, usign cheats has some undesired effects on replaysaves, so that one has to "play with care" while using those cheats. A double-edged sword indeed.
I ask some moderator to please close this bug, as, to my thinking, those issues were NOT-A-BUG, but mostly a non-negative method of work for replaysave feature.
Thank you very much for your attention.
All the best
Tanthree.

PD: Excuse me, my english.

Tan <tanthree>
Thu 05 Sep 2013 03:31:14 AM UTC, comment #2:

The crash in the original submission occurred because the replay said to recruit a unit in a space that was already occupied. I have not yet looked into why that space was occupied, but it would not be surprising for it to be a consequence of the replay being out of sync (which presumably was caused by the cheats). Version 1.11 might be able to replay the game better, but basically your replay is corrupt. (I'll leave this report open for now though, since it might be worth verifying that there is not something else going on.)

The second post describes a completely different problem that should be its own bug report (if it isn't already reported -- those messages look familiar).

J Tyne <jamit>
Project Member
Wed 04 Sep 2013 08:35:33 PM UTC, comment #1:

Hello.

Thank you anyone for viewing this.
I now present a summary of errors from loading some scenarios of this campaign, that I have recolected in the past days, together with their respective savereplay files.
I ran wesnoth from terminal, and (as I do not know anything debug or the like) just copied the LAST messages just before the game aborts itself, all from one terminal session-window.

Replay file: LdW-Consejo_con_duras_re..._repetición[d0]
Last message from terminal:
Invalid WML found: [player], [player] not supported at scenario toplevel
wesnoth: /build/buildd-wesnoth-1.10_1.10.6-2-i386-VDrBnF/wesnoth-1.10-1.10.6/src/game_display.cpp:1308: void game_display::set_team(size_t, bool): La declaraci?n `teamindex < teams_.size()' no se cumple.
Abortado

Replay file: LdW-Revelaciones_repetición[d0]
Last message from terminal:
20130830 17:06:16 error display: Failed to send visual notification: The name org.freedesktop.Notifications was not provided by any .service files
Invalid WML found: [player], [player] not supported at scenario toplevel
wesnoth: /build/buildd-wesnoth-1.10_1.10.6-2-i386-VDrBnF/wesnoth-1.10-1.10.6/src/game_display.cpp:1308: void game_display::set_team(size_t, bool): La declaraci?n `teamindex < teams_.size()' no se cumple.
Abortado

Replay file: LdW-La_alianza_repetición[d0]
Last message from terminal:
Invalid WML found: [player], [player] not supported at scenario toplevel
wesnoth: /build/buildd-wesnoth-1.10_1.10.6-2-i386-VDrBnF/wesnoth-1.10-1.10.6/src/game_display.cpp:1308: void game_display::set_team(size_t, bool): La declaraci?n `teamindex < teams_.size()' no se cumple.
Abortado

Replay file: LdW-Hora_de_gloria_repetición[d0]
Last message from terminal:
Invalid WML found: [player], [player], [player] not supported at scenario toplevel
wesnoth: /build/buildd-wesnoth-1.10_1.10.6-2-i386-VDrBnF/wesnoth-1.10-1.10.6/src/game_display.cpp:1308: void game_display::set_team(size_t, bool): La declaraci?n `teamindex < teams_.size()' no se cumple.
Abortado

Replay file: LdW-Decisión_del_consejo_repetición[d0]
Last message from terminal:
Invalid WML found: [player], [player], [player] not supported at scenario toplevel
wesnoth: /build/buildd-wesnoth-1.10_1.10.6-2-i386-VDrBnF/wesnoth-1.10-1.10.6/src/game_display.cpp:1308: void game_display::set_team(size_t, bool): La declaraci?n `teamindex < teams_.size()' no se cumple.
Abortado

The ONE thing I noted is those messages are too similar (I won't say identical), so I suppose that this "bug" is a one-thing issue that could be resolved with a one-process patch or something of that nature, if that's the case.

The messages previous to last ones put here are just generic syncronization messages, the same along this campaign. I played wesnoth spanish version, 1.10.6; the '[d0]' in the replay saves are just naming conventions.

Also, before posting this bug, I read the changelog and took note of all the changes into this campaign, and no line of it is related to what happens here with these replays. Also, when cheating, I just do it with HP & money, and finally with the unit-advances=(100 - max_level_number) command.

If I can mention something about this 'bug', is this: teamindex<teams_.size() is too restrict of a condition, why abort? At least, what happens on the complement of that sentence? Are that messed up those replaysaves?

Thank you.

(file #18872, file #18873, file #18874, file #18875)

Tan <tanthree>
Fri 30 Aug 2013 08:39:16 PM UTC, original submission:

Hello:
I'm new in BFW, and I play it from time to time.
I'm no expert in strategy games, so I use cheats in order to play action-game-style (try to conserve fighters for all the campaign) and advance the story, so after finished then watch my replays as if watching movies (well, that was the plan).
I was playing version 1.10.2, and recently updated to 1.10.6. I finished the first 4 campaigns in cronologic order, plus some add-on campaings, in wesnoth 1.10.2.
Then, I decided to watch those saved replays I got to this date. One-by-one. Enjoying stuff.
So far, all replays from TRoW & anOrcishIncursion are OK, no problems, all play fine except for many OOS "error" messages that I do not mind too much (because I used cheats).
Then, this 3rd (cronologically-wise) campaign, LoW, the first two scenarios play fine, until the 3rd scenario, where just starting turn-4 closes the program!

I started wesnoth from Commandline, and I got these as last lines:
------------------------------------------------------
(...many OOS-sync messages before.)
20130830 14:03:48 error replay: SYNC: In attack Orcish Assassin (19,26) vs Elvish Archer (19,25): the data source says the defender survived while in-game calculations show it perished (over-riding game calculations with data source results)
20130830 14:03:50 error replay: unit 'Goblin Knight' is too expensive to recruit: 32/-145
20130830 14:04:07 error replay: unit 'Goblin Knight' is too expensive to recruit: 32/11
20130830 14:04:07 error replay: unit 'Orcish Crossbowman' is too expensive to recruit: 26/-21
20130830 14:04:08 error replay: unit 'Orcish Warrior' is too expensive to recruit: 26/-47
20130830 14:04:08 error replay: unit 'Orcish Slayer' is too expensive to recruit: 33/-73
20130830 14:04:08 error replay: unit 'Orcish Warrior' is too expensive to recruit: 26/-106
20130830 14:04:08 error replay: unit 'Goblin Knight' is too expensive to recruit: 32/-132
20130830 14:04:08 error replay: unit 'Orcish Warrior' is too expensive to recruit: 26/-164
20130830 14:04:08 error replay: unit 'Orcish Slayer' is too expensive to recruit: 33/-190
20130830 14:04:08 error replay: unit 'Orcish Slayer' is too expensive to recruit: 33/-223
20130830 14:04:08 error replay: unit 'Goblin Knight' is too expensive to recruit: 32/-256
20130830 14:04:15 error replay: unit 'Orcish Warrior' is too expensive to recruit: 26/-288
ALSA lib pcm.c:7832:(snd_pcm_recover) underrun occurred
20130830 14:04:29 warning replay: Warning: Missing path data found in [move]
20130830 14:04:29 warning replay: Warning: Missing path data found in [move]
20130830 14:04:29 error replay: unfound location for source of movement: 32,7 -> 27,7
20130830 14:04:29 error replay: unfound location for source of movement: 32,7 -> 27,6
20130830 14:04:29 warning replay: Warning: Missing path data found in [move]
20130830 14:04:29 error replay: unfound location for source of movement: 32,9 -> 32,4
20130830 14:04:30 error replay: unfound location for source of movement: 32,10 -> 29,11
20130830 14:04:30 error replay: unfound location for source of movement: 32,10 -> 29,9
20130830 14:04:30 error replay: unfound location for source of movement: 31,10 -> 26,11
wesnoth: /build/buildd-wesnoth-1.10_1.10.6-2-i386-VDrBnF/wesnoth-1.10-1.10.6/src/actions.cpp:613: void place_recruit(const unit&, const map_location&, const map_location&, bool, bool, bool, bool, bool): La declaraci?n `resources::units->count(recruit_location) == 0' no se cumple.
Abortado
---------------------------------------------------------
And that's it.
I'm attaching the replay file (packed) so that anybody can help me with this.
Regards.
Tan3

Tan <tanthree>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #18876:  LdW-Decisión_del_consejo_repetición[d0].gz added by tanthree (60kB - application/x-gzip - I added these 5 files because I though their error messages were related with those from watching replay of scenario#3.)
file #18873:  LdW-La_alianza_repetición[d0].gz added by tanthree (54kB - application/x-gzip)
file #18802:  LdW-El_asedio_del_Ka’lian_repetición[d0].gz added by tanthree (58kB - application/x-gzip - Replay from scenario #3, LoW campaign. Replay from wesnoth version 1.10.2.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jamit (Posted a comment)
  • -unavailable- added by soliton (Updated the item)
  • -unavailable- added by tanthree (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):

     

     

    Follow 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 12 Apr 2014 09:17:38 PM UTCjamitStatusNone=>Invalid
      Open/ClosedOpen=>Closed
    Wed 04 Sep 2013 08:41:16 PM UTCtanthreeAttached File-=>Added LdW-Decisión_del_consejo_repetición[d0].gz, #18876
    Wed 04 Sep 2013 08:35:33 PM UTCtanthreeAttached File-=>Added LdW-Consejo_con_duras_re..._repetición[d0].gz, #18872
      Attached File-=>Added LdW-La_alianza_repetición[d0].gz, #18873
      Attached File-=>Added LdW-Revelaciones_repetición[d0].gz, #18874
      Attached File-=>Added LdW-Hora_de_gloria_repetición[d0].gz, #18875
    Mon 02 Sep 2013 10:30:10 PM UTCsolitonSeverity4 - Important=>3 - Normal
    Fri 30 Aug 2013 08:39:16 PM UTCtanthreeAttached File-=>Added LdW-El_asedio_del_Ka’lian_repetición[d0].gz, #18802
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup