Fixed random

[rmj]

I have a scenario where certain units and objects are placed according to the random number generator. If I restart the scenario all the units and objects are in the same position. What must I do to ensure that these are placed by newly generated random number?

Is there a difference between placing the code in a prestart event vs. a start event?

What of a macro in a utilities file? Is a random number generated there fixed?

Thanks.

[SFault]

Have you checked out the SCATTER_UNITS macro from utils.cfg? I'm quite sure you could use it as it is or after minor modifications for the units.

There's also the SCATTER_IMAGE macro in terrain-utils.cfg. That might be suitable for the objects.

[Max]

this wouldn't help unless there's some user action that makes use of the rng (e.g. a fight) before using SCATTER_UNITS. the seed for the RNG is restored if you load a save game.

here's some related discussion:
http://forums.wesnoth.org/viewtopic.php?f=21&t=34030

[Anonymissimus]

Seems using lua's math.rand and wesnoth.synchronize_choice gets you around it, since it doesn't use the seeds saved in the savegame, while synchronize_choice ensures multiplayer and replay synching:

Code: Select all

	[event]
		name=side turn
		first_time_only=no
		[lua]
			code=<<
			local res = math.random(99)
			wesnoth.message(wesnoth.synchronize_choice(function() return { value = res } end).value)
			>>
		[/lua]
	[/event]

I reloaded the scenario without getting the same results again.

[rmj]

If one has this:
[event]
name=turn 10
. . .
variable equals some random
[/event]

then am I correct in understanding that this random number has been seeded on loading rather than at turn 10?

Seems using lua's math.rand and wesnoth.synchronize_choice gets you around it, since it doesn't use the seeds saved in the savegame, while synchronize_choice ensures multiplayer and replay synching:

I have no understanding of lua. What would be the code to get a couple of variables? I am thinking of the possibility of redefining macros so that instead of having the random number in the coding, the lua random number would be fed to the macro. That is, instead of {DO_THIS} and {DO_THAT} I would have {DO_THIS X} and {DO_THAT Y}

[Anonymissimus]

I have no understanding of lua. What would be the code to get a couple of variables? I am thinking of the possibility of redefining macros so that instead of having the random number in the coding, the lua random number would be fed to the macro. That is, instead of {DO_THIS} and {DO_THAT} I would have {DO_THIS X} and {DO_THAT Y}

I suggest you bug Elvish_Hunter to add the tags he posted in the thread linked to by Max to the WesnothLuaPack. The random_number tag is certainly worthwile (for the reason stated in this thread and the one in that thread). The random_seed one is bit problematic since it probably needs to be executed from a preload event to make it work with reloaded games.

[Sapient]

Seems using lua's math.rand and wesnoth.synchronize_choice gets you around it, since it doesn't use the seeds saved in the savegame, while synchronize_choice ensures multiplayer and replay synching

If that's true, then should that not be the default behavior of [set_variable] rand= ? As it is, the current behavior doesn't seem very random.

On the other hand, sometimes you may want the random value to stay consistent when the scenario is reloaded, e.g. the scepter of fire should stay in same location if you reattempt the scenario.

Another problem would be that synchronize_choice isn't supported in start or prestart events (if I understood that other thread correctly).

[Anonymissimus]

On the other hand, sometimes you may want the random value to stay consistent when the scenario is reloaded, e.g. the scepter of fire should stay in same location if you reattempt the scenario.

Offtopic - I actually want it to be in a completely new location, since otherwise I have a factual advantage over the first time I played the scenario. And I could go simply straight for the scepter location, involving completely different strategy.

Another problem would be that synchronize_choice isn't supported in start or prestart events (if I understood that other thread correctly).

I found that it works starting with turn 1 events (seems consistent and not a bug). Perhaps this [set_variable]rand= seeding was done to allow earlier synchronization, perhaps with respect to MP campaigns (it doesn't work though, see http://gna.org/bugs/index.php?18746)

[Sapient]

Perhaps this [set_variable]rand= seeding was done

If I remember correctly, [set_variable]rand= was coded by Mordante to work around bugs with [set_variable]random=, and he had some reservations about it possibly not being random enough... which was why he didn't just change the behavior of [set_variable]random=. Perhaps this reloaded seed problem is what he was alluding to.

The only two advantages of the seeded set_var (that I can think of) are 1) less network communication / smaller replay size, and 2) prevent cheating by modified clients sending an altered synch choice. However, with #2 I imagine the cheat would need to be tailor made for a specific MP scenario, and then it would only work during your own turn.

[Elvish_Hunter]

I suggest you bug Elvish_Hunter to add the tags he posted in the thread linked to by Max to the WesnothLuaPack. The random_number tag is certainly worthwile (for the reason stated in this thread and the one in that thread). The random_seed one is bit problematic since it probably needs to be executed from a preload event to make it work with reloaded games.

Nah, no need to bug me. I just committed both tags in the Wesnoth Lua Pack, r12761.

I found that it works starting with turn 1 events (seems consistent and not a bug).

I also added a note about this in the HTML readme.

[Anonymissimus]

After wondering about it, it seems to me the functionality is too problematic to be put into easy-to-use wml action tags in the WLP and thus the tags should be removed or modified again.
Imagine someone exexcutes [random_seed] in a turn 1 event, saves the game, reloads it, executes [random_number] in a turn 2 event. The effect of random_seed will be gone! Thus random_seed would need to be executed from a preload event with first_time_only=no. But then, imagine the wml author goes straight to the turn 2 event but saves and reloads after executing it. In the turn 3 event random_number is executed again and it will return the same result as the call to random_number in turn 2 (provided arguments are the same). This is not what the wml author expected, since if he hadn't saved and reloaded between turn 2 and 3 events the result would be something else.

I imagine a way to solve it and to serve the two requirements (being able to seed the RNG via a wml action tag if necessary, and not getting the same results when restarting a scenario) would involve writing a new randomseed into the saved scenario data every time random_number is called, and reloading it every time the scenario is loaded (unless there is none in the saved scenario data, which means the wml author didn't seed the RNG so far in this scenario and no seed needs to be set, used or regenerated). The process probably requires modifying wesnoth.game_events.on_load from a [scenario][lua] tag.

[rmj]

So in lay language, what's going on?

[Elvish_Hunter]

After wondering about it, it seems to me the functionality is too problematic to be put into easy-to-use wml action tags in the WLP and thus the tags should be removed or modified again.

I think that, at least for now, I'll comment out the [random_seed] one. But I'll keep [random_number], as it does not require math.randomseed() to work. Fine?

So in lay language, what's going on?

A technical discussion on how to initialize the RNG and the issues that it may create.

[Anonymissimus]

After wondering about it, it seems to me the functionality is too problematic to be put into easy-to-use wml action tags in the WLP and thus the tags should be removed or modified again.

I think that, at least for now, I'll comment out the [random_seed] one. But I'll keep [random_number], as it does not require math.randomseed() to work. Fine?

I think yes.
It still fulfills the requirement in this thread (new random sequences after restarting the scenario).
In SoW I use math.random+synchronize_choice as well.

[Elvish_Hunter]

Done. In r12776 I commented out both the tag and its HTML documentation.