Both the slash key and the numpad slash key were displayed as 'Key /',
so it's not obvious to the user which key actually has been bound. Let's
display them as 'Key /' and 'KP /' instead. Same for other KP keys.
Before, if the PacDrive32.dll provided by Ultimarc wasn't found,
stepmania would attempt to write to the Pac-Drive anyway, resulting in a
call on a null pointer.
This adds a quick check against PacDriveConnected during the update, and
checks if the pacdrive functions exist before calling them.
I will say, the version of this that didn't have break statements had
way, way more flashy light patterns than the boring, correctly
functioning version of this.
Also, the preference now defaults to "minimaid"
The currently proposed light ordering presents a problem for those who have bought a LumenAR or have followed the OpenITG standard for wiring lights. With this change, the default ordering stays the same, but users have the option to define "openitg" or "lumenar" as their preferred light ordering in Preferences.ini under the newly defined "PacDriveLightOrdering" preference.
This adds Lua hooks to CryptManager for libtomcrypt's SHA256 hash
function. It follows along with the C++ patterns Glenn wrote a decade
and a half ago for CryptMananger's MD5 and SHA1 hooks.
StepMania's CMakeProject-tomcrypt file has been updated to build with
sha256 symbols. Invoking cmake to build with system tomcrypt works fine
as-is.
Note that these functions return binary formatted strings, but themers
can convert to hexadecimal format using the global Lua function
BinaryToHex().
The hashing functions that CryptManger currently exposes to Lua
return hash strings formatted in binary. Themes using those hash
functions may want to compare hex strings.
RageUtil already had a BinaryToHex utility; this commit exposes it
as a global function, following along with other utility functions
in RageUtil.
Silence the following warning message:
src/NotesWriterSM.cpp:260:11: warning: control reaches end of non-void function [-Wreturn-type]
This warning had meaningful implications for some reason.
When I compiled the current version with stack protector enabled,
GCC optimized out successful return from the function, and encouraged
undefined behavior far less intuitive than an unspecified value.
Whenever saving a steps file on a -DCMAKE_BUILD_TYPE=Release build,
the game printed a message about stack protection violation,
and aborted itself, even though no violation took place.
GCC version:
gcc (Gentoo 10.2.0 p1) 10.2.0
this isn't actually a good solution, really RageVColor shouldn't be
doing this conversion at all and should be refactored/removed.
this gets gameplay running a bit smoother, much closer to holding 60fps
These elements are normally automatically updated when a new Lua.xml is
generated using the --ExportLuaInformation command line argument, but
I've manually updated them here. It works for now.
Running --ExportLuaInformation will generate a new Lua.xml file with
everything available to Lua, including some repetitively-named functions
ported from notitg that were manually condensed down within Lua.xml.
We want to keep these condensed parts, so ExportLuaInformation should
probably be fixed/replaced in the future.
These "grouping"s aren't part of the spec in Docs/Luadoc/Lua.xsd, so
they won't appear when Lua.xml is viewed in a web browser, but can still
be used by external API doc applications until ExportLuaInformation is
improved.
Crystal Squirrel