The C++ standard doesn't require us to stuff multiple statements
onto the same line, so we should avoid this for readability reasons.
This is especially true if one of the statements is controlled and
others aren't.
Some code here was indented like it still belonged to the loop
above, but never did, and was never intended to. This is an
excellent argument for why braces are good, especially for
statements which span more than one line.
We're not using the <locale.h> header anywhere besides including it
for no purpose, so we can drop the test (and the inclusion).
Additionally, the header is part of standard C++.
Qt's moc generates another source file that includes this header without
including C4Include.h first. The generates source file thus doesn't
compile. It is unclear to me why this isn't an issue with our current
build setup (it is an issue with a meson-based build).
The branch information is necessary for upcoming automatically-updating
snapshots. For Travis, cmake will also pick up the branch name from the
C4REVISION_BRANCH environment variable.
As the timer tends to run more than once, you'd also very likely get the
error more than once. The timer also often determines the effect
lifetime, making a broken effect live forever.
This was especially annoying with one-off Schedule() invokations
that wouldn't even stop throwing errors after finishing the
designated number of repeats. Although fixing just that script
function would have been possible, I believe that a more general
solution for all effects is useful.
We already notified the user on warning/error that the mistake
happened in a different script than the one we were currently
compiing. It's not too difficult to figure out whether that other
script was added due to an #include or an #appendto directive, so we
can just show the user which one it is.
We also don't show warnings in #include'd scripts anymore, since
they get compiled individually anyway and all warnings will show up
there. This way we don't duplicate warnings several times.
When we introduce block scoping, using variables declared in a more
narrow scope from a block with wider scope will fail. Warn about
these so people can avoid it and fix their code.
While I do not agree with the idea of using straight assignments in
the condition of a for loop, people are divided on the argument and
lots of old code uses it.
FatalError(Format(...)) was necessary previously. Actually it seems not
like a huge thing, but being able to format the string directly in
FatalError is a lot more convenient.
Renamed and documented the former function SetNextMission. Added a script wrapper for the old function that issues a warning. Renaming is based on the fact that the docu speaks of scenarios, and other functions, such as GainScenarioAchievement already use this terminology
This introduces a new diagnostic (suspicious_assignment) which
issues when an the compiler finds an assignment either where a
condition is expected or as the parameter to return.
The crypto "library" only consists of a single function at the
moment because that's all that users have asked for so far. It is
also highly experimental. We will make an attempt to keep the public
interface (i.e. the interface provided by Library_Crypto.c) stable,
but it might still change if necessary. The internal interface
(provided via the global _Crypto proplist) is not for public
consumption and will probably change at some point.
In Tower of Despair, the scenario saves per-room progress in the
player files. Players win individual rooms, but never the whole
scenario. Consequently, they currently have to give up to make sure
they don't lose their progress. This is not intuitive at all. With the
new flag enabled, players will be saved even if the scenario is aborted.
Pressing Ctrl+S while on the Credits screen will save everything to
Credits.txt in the current working directory. This is only meant for
developers modifying the credits; the shortcut isn't mentioned anywhere.
Nicolas Hake