Follow-up Comment #3, bug #21082 (project wesnoth):
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.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?21082>
_______________________________________________
Mensaje enviado vía/por Gna!
http://gna.org/
_______________________________________________
Wesnoth-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-bugs
