2010-07-18T15:21:41Z!guillaume.melquiond@gmail.com
The hack causes problems now, since I want to load helper.lua previously
already and the comment says that it should be removed in 1.11.
I *think* the reason for the hack was to avoid loading wml-tags.lua twice
in case that a replay and/or (perhaps) savegame is loaded which was
created with a BfW version previously to 2010-07-18T15:21:41Z!guillaume.melquiond@gmail.com,
since those replays/saves seemed to have recorded the commands for
loading the core lua files, which is no longer the case since back
then. Those replays/saves are no longer relevant, so everything hints
that I can safely remove this.
Searched all *.lua and *.cfg (embedded lua) files in data/ for occurences
of the deprecated stuff mentioned in
http://www.lua.org/manual/5.2/manual.html#8.2
The currently compiled-in define LUA_COMPAT_ALL appears to work
like so that both the old and the new syntax work at the same time
(without errors or warnings), while the old one will be an error after
removing it.
If the tag is used to modify the type= of several units at once,
it looks better to not kill the old units until the modified one
gets unstored, so that units don't disappear for the time of processing.
reported in the forum: http://forums.wesnoth.org/viewtopic.php?p=519174
since they break compatibility.
This reverts
2011-12-16T01:24:54Z!anonymissimus@arcor.de
2011-12-16T04:06:47Z!Majora700@gmail.com
2011-12-16T04:08:22Z!Majora700@gmail.com
2011-12-16T04:14:58Z!Majora700@gmail.com
2011-12-16T20:13:27Z!anonymissimus@arcor.de
2011-12-16T20:14:08Z!anonymissimus@arcor.de
2011-12-16T20:48:39Z!Majora700@gmail.com
2011-12-17T09:46:29Z!Majora700@gmail.com
In multiplayer, scenarios have default objectives sent from the host
to the other clients as [scenario]objectives= t_string, and this doesn't
know about silent= but must be shown anyway.
I do not want such workarounds to be added. shadowmaster's campaign
was still functional nevertheless. If there's an annoying bug
and nobody has the time or knowledge or energy to fix it then we must
just accept that it lingers around any annoys us.
Since capture_village already has an inline SLF, I don't want to add
a SSF at the same level since keys and tags could conflict in the future.
In case that both inline side= and [filter_side] are present,
emit an error.
Not sure whether inline side= should be deprecated; no need to break
backwards compatibility for now.
Add SSF support along the way. No deprecation for default side=1 needed,
since if left empty, an array with all starting locations is created,
side 1 being the first element and $array[0].something is the same as
$array.something.
(I used the same trick for [store_side] already.)
thonsew: The lua interface is not your playground. This is not the way
I want the lua files or its C++ interface to be modified. You are
invited to talk with me on IRC.
some of the main reasons:
-Your revisions contain lots of unneccessary changes, some of which
break existing lua or wml without a reason. Do you ever look at the
diffs?
-Your revisions pack a lot of unrelated stuff together into one.
2011-09-21T21:44:58Z!thonsew@yahoo.com makes sense in some parts and is what you should have
done in the first place.
This fixes all of the lua errors in wesnoth -t. This does not fix all
of the errors in Anonymissimus' multiplayer add-on, which are due to
references leaking through the arbitrary code hole in wml-tags.lua:250
1. Created a t_token metatable along with support code for indexing,
garbage collection, tostring, tonumber, comparison and concatenation.
2. Adjusted string comparison and lookup in lua code to work with
either t_token or string.
This addresses in part bug #18631, bug #18695. Before this lua was
treating all t_token as either tstrings or strings.
...t_token in place of std::string. t_token compares, copies, copy
constructs and hashes in 1 operation instead of proportional to the
length of the string.
