bugBattle for Wesnoth - Bugs: bug #20322, Private units created with Lua...

Show feedback again

You are not allowed to post comments on this tracker with your current authentification level.

bug #20322: Private units created with Lua cause OOS in replays

Submitted by:  Simon Forsyth <alarantalara>
Submitted on:  Fri Nov 23 02:20:46 2012  
Category: BugSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Replays
Status: FixedPrivacy: Public
Assigned to: Daniel <gfgtdf>Open/Closed: Closed
Release: 1.11.0Operating System: OS X

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

Wed Oct 8 17:45:24 2014, comment #7:

assuming to be fixed.
(in 1.12 and master) since pr 121/141 was backported in 1.11.13

Daniel <gfgtdf>
Project MemberIn charge of this item.
Wed Apr 9 17:28:08 2014, comment #6:

probably fixed in pr 121/141 (1.13-dev):
calling rng form unsynced context ike AI calcuation, select events, preload events, now automatictly uses rand() instead of the synced rng. This is true for [set_variable]rand=, but also for units trait/names creation.

Daniel <gfgtdf>
Project MemberIn charge of this item.
Mon Dec 3 22:28:54 2012, comment #5:

Or maybe not. The AI appears to run at "odd" times.
I just ran into something that demonstrates that "side turn" events run after the AI starts actions.

That is, the AI ran, found its recruitment list and picked a unit.
Then a side turn event changed the recruitment list (possibly before the unit actually was recruited).
The the AI ran again and found the new recruitment list.

It seems plausible that the same thing is happening turn 1 with the AI - that it runs before some important event takes place regarding RNG synchronization and some of its actions could cause OOS problems.

Simon Forsyth <alarantalara>
Project Member
Mon Dec 3 15:08:41 2012, comment #4:

Apparently this report represents more than one bug.
The included sample code does indeed no longer cause problems.

However, the case where I originally found the problem still has OOS occur.

I originally found the problem in Lua AI code. Several private units are created to determine reachability of hexes before choosing which unit to recruit and where to recruit it. (See instances of wesnoth.create_unit() in data/ai/lua/generic-recruit_engine.lua for examples.) When the RNG was involved in creating these units, an OOS error occurred in the replay.

I then tested it with the very simple code you saw below and discovered that it appeared to reproduce the problem, which is why I included it. You should be able to reproduce the original error by getting rid of any instance of 'name = "X"' from data/ai/lua/generic-recruit_engine.lua and playing one turn of a multiplayer game vs the Experimental AI.

Simon Forsyth <alarantalara>
Project Member
Mon Dec 3 04:53:06 2012, comment #3:

In my tests, it was not creating a unit in Lua that was the culprit, but utilizing the RNG in a turn_1 event. I might have missed something though, so could you give this a retest?

(I also found and fixed a problem when the RNG is used in start or prestart events. That might have affected other tests involving Lua-created units.)

J Tyne <jamit>
Project Member
Mon Dec 3 04:40:24 2012, SVN revision 55800:

Correct the timing of turn_1 (et al.) events in a replay.

Might fix bug #20322.

(Browse SVN revision 55800)

J Tyne <jamit>
Project Member
Mon Nov 26 18:41:06 2012, comment #1:

This does have the workaround of ensuring that any private units created contain no random content (name, gender, traits, etc.)

Simon Forsyth <alarantalara>
Project Member
Fri Nov 23 02:20:46 2012, original submission:

Lua has the ability to create private units that do not appear on the map. If such units are created, they affect the state of units created later, causing OOS errors as they do not appear in the replay (having never been on the map).

Adding the following event to any scenario can reproduce the bug in its associated replays.

name=turn 1
code = << wesnoth.create_unit({type = "Mage"})

Simon Forsyth <alarantalara>
Project Member


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 shadowmaster (Updated the item)
  • -unavailable- added by gfgtdf (Posted a comment)
  • -unavailable- added by jamit (Posted a comment)
  • -unavailable- added by alarantalara (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.


    Error: not logged in



    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun Oct 12 12:16:30 2014shadowmasterOpen/ClosedOpen=>Closed
    Wed Oct 8 17:45:24 2014gfgtdfStatusReady For Test=>Fixed
      Assigned toNone=>gfgtdf
    Wed Apr 9 17:28:08 2014gfgtdfStatusNone=>Ready For Test
    Tue Feb 26 00:17:24 2013jamitAssigned tojamit=>None
    Sat Dec 8 23:08:05 2012jamitStatusReady For Test=>None
    Mon Dec 3 04:53:06 2012jamitStatusNone=>Ready For Test
      Assigned toNone=>jamit
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup