C++11 forbids conforming compilers from performing the deprecated
conversion from a string literal to non-const char* or wchar_t*. Most
compilers however still do it by default because not doing it breaks
lots of legacy code. We don't have any of this legacy code anymore, so
we can disable the conversion.
The lpClass parameter isn't used, and it is valid to pass NULL for it.
It is, however, not valid to pass a string literal, because the
conversion to nonconst char* has been deprecated in C++ for a long time
and doesn't exist anymore in C++11.
Quoth MSDN: "The Unicode version of this function, CreateProcessW, can
modify the contents of this string. Therefore, this parameter cannot be
a pointer to read-only memory (such as a const variable or a literal
string). If this parameter is a constant string, the function may cause
an access violation."
It can, however, be NULL, which does the right thing automatically.
It seems like an odd decision to add a layer of indirection to this,
especially since it's just a pointer to int instead of a pointer to a
larger structure.
This messes up so many things as one could have expected. Instead we do the sensible thing and enable it only in the test scenario. For future reference all sequences involving an elevator and NPC clonks are broken with this feature.
The red color channel calculation could overflow into the sign bit,
which is undefined behavior. At least one compiler takes advantage of
this and assumes it cannot happen, resulting in incorrect results.
BltAlphaAdd looks similar, but does in fact not have this bug because it
shifts the color channel far enough that multiplication can't overflow.
The script now just sets visibility per player (VIS_Select) instead of creating one dummy object per player. It also uses the object directly instead of indirecting everything through an effect (the effect couldn't be used on other objects anyway).
..because the library wasn't actually USING the holding callback at all. And it had/has its own CON_Aim hackery anyway. No need for the control-library internal CON_Aim stuff then (I could imagine this might just lead to issues at some point).
Otherwise the situation could arise where you used a ControlUseStart object (the wallkit) but noholdingcallbacks was still set to true (because e.g. you used a hammer before). Then you would not be able to move the preview.
This is described in a comment to the referenced bug.
Otherwise, you could open a menu on mouse-down, which would then block the mouse-up event. The control system (not the script but the engine!) would then never know that the button was released and issue a key event with repeated=1 when you pressed the button the next time.
This could lead to issues.
If the gamepad code initialized the SDL video subsystem, GTK+ crashed in
libX11. Or something along those lines.
Making the optional subsystems using SDL for gamepads and audio use
SDL_InitSubSystem and only the SDL Application port do the full SDL_Init
is the proper way to do things in any case.
It used a mix of tabs and spaces for indentation, and tabs to separate the
columns, which doesn't work with variable tab sizes and variable column
widths. Use tabs for indentation and spaces for column separation.