Additional Item Attachment, patch #4596 (project wesnoth):
File name: 0001-fix-num_box-and-its-documentation.patch Size:2 KB
___
Reply to this item at:
http://gna.org/patch/?4596
___
Additional Item Attachment, patch #4596 (project wesnoth):
File name: 0001-num-box-add-support-for-up-down-arrows.patch Size:1 KB
___
Reply to this item at:
http://gna.org/patch/?4596
___
Follow-up Comment #1, bug #21697 (project wesnoth):
so you want to be able to call random or [unit] from lua filters?
the nomral rule is that you shall not change the gamestate during an
(possibly) unsynced event, which [unit] normaly does.
i argee that wesnoth.synchronized would be a useful
Follow-up Comment #2, bug #21697 (project wesnoth):
Simple: For some filter, I have a unit table (not a proxy unit) and I want to
check its movement cost on a particular hex using wesnoth.unit_movement_cost.
So I make a proxy unit with wesnoth.create_unit(), but that (by default)
desyncs the RNG.
Follow-up Comment #3, bug #21697 (project wesnoth):
Another one: You could have a complex menu that allows you to create and
customize a unit (possibly with some legitimately random elements), then
passes the unit to the other players as the return value of
wesnoth.synchronize choice.
Follow-up Comment #4, bug #21697 (project wesnoth):
For random numbers in ability filters specifically, it is probably wrong to
use them, but if my ability filter is complicated and calls other parts of my
code, and one of those parts uses random numbers, I want to see that as a
warning message
Follow-up Comment #1, bug #21776 (project wesnoth):
the preload event event is normaly meant to intilialize things that are not
prsitent in savefiles. For instance Lua environments, wml variables ARE
persitent thats why you get OOS errors, it would be good if you gave us an
example where you get
Follow-up Comment #2, bug #21776 (project wesnoth):
There is no OOS in the game. An OOS may occur in the replay though, because
the replay is not synchronized with the real game.
This is because preload events are skipped in the replay.
In the example below, after the 'preload' event runs 2nd
Follow-up Comment #3, bug #21776 (project wesnoth):
so you realy want to have reloading an influence on the players game?
thats currently not realy supported so i'd rather call that a feature request
than a bug.
People currently use preload events to initialize lua envornemts, and load
data
Follow-up Comment #4, bug #21776 (project wesnoth):
I named it a bug because I expected the replay should replay the game exactly
how it went in reality.
people would have to check wether their envoronment is already loaded in
every preload event then.
I cannot imagine how any problem could
associated to the unit map
tests is now:
20140311 20:13:09 error engine: Trying to add - Orcish Grunt-4294967294 -
4294967294 (2,2) over - Orcish Grunt-4294967294 - 4294967294 (2,2). The new
unit will be assigned underlying_id=1 to prevent duplicate id conflicts.
20140311 20:13:09 warning unit
Follow-up Comment #5, bug #21776 (project wesnoth):
If the real game had no problem and the replay is equal to the real game
then the replay must be problem-free too, musn't it?
but in the game the lua variables are deleted during reload, in the replay
that doesnt happen. And the prelaod events
12 matches
Mail list logo
