With localization for non-Latin languages on the support list the multibyte API doesn't cut it anymore. It neither can handle system text output outside the local code page nor can an ANSI window receive text input outside its own code page.
Similar problems exist for file names. With the multibyte API it is impossible to handle any file containing characters outside the active local code page.
So as of now, everything that may pass along some Unicode text will use the Unicode API with some text conversion functions. The only places where calls to the multibyte API were left are those where known string literals are passed or where the information is not used for anything but comparing it to other return values from the same API.
# Conflicts:
# src/rendering/hwrenderer/postprocessing/hw_postprocess.h
# src/win32/base_sysfb.cpp
# src/win32/i_main.cpp
# src/win32/win32basevideo.cpp
# src/win32/win32glvideo.cpp
# Conflicts:
# src/version.h
# src/win32/i_main.cpp
# src/win32/i_system.cpp
# src/win32/optwin32.h
# src/win32/win32gliface.cpp
# wadsrc/static/language.enu
src/c_dispatch.cpp:143:5: warning: delete called on 'FDelayedCommand' that is abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor]
src/tarray.h:582:5: warning: delete called on 'FDelayedCommand' that is abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor]
src/tarray.h:574:5: warning: delete called on 'FDelayedCommand' that is abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor]
Doing this intermingled with the thinkers is highly unsafe because there are absolutely no guarantees about order of execution.
Effectively it ran these commands right in the middle of the playsim which could cause all sorts of synchronization issues, because CCMDs are part of the UI, not the playsim.
- pass a const string to AddCommandString.
This function manipulated the input buffer, leading to all sorts of code contortions to make sure that the passed parameter is clean for that.
This function will now create a copy of the passed parameter which it can manipulate without complicating its calling code.
# Conflicts:
# src/c_dispatch.cpp
Unlike the other classes, the places where variables from this class were accessed were quite scattered so there isn't much scriptified code. Instead, most of these places are now using the script variable access methods.
This was the last remaining subclass of AActor, meaning that class Actor can now be opened for user-side extensions.
This is to ensure that the Class pointer can be set right on creation. ZDoom had always depended on handling this lazily which poses some problems for the VM.
So now there is a variadic Create<classtype> function taking care of that, but to ensure that it gets used, direct access to the new operator has been blocked.
This also neccessitated making DArgs a regular object because they get created before the type system is up. Since the few uses of DArgs are easily controllable this wasn't a big issue.
- did a bit of optimization on the bots' decision making whether to pick up a health item or not.
This also means that the remaining scriptification of the menu is on hold. The player menu would require even more access to critical game data, which is a no-go, and the other remaining menus offer little benefit from getting scriptified.
This function will truncate everything that is larger than LONG_MAX or smaller than LONG_MIN to fit into a long variable, but longs are 32 bit on Windows and 64 bit elsewhere, so to ensure consistency and the ability to parse larger values better use strtoll which does not truncate 32 bit values.
Needless to say, this is simply too volatile and would require constant active maintenance, not to mention a huge amount of work up front to get going.
It also hid a nasty problem with the Destroy method. Due to the way the garbage collector works, Destroy cannot be exposed to scripts as-is. It may be called from scripts but it may not be overridden from scripts because the garbage collector can call this function after all data needed for calling a scripted override has already been destroyed because if that data is also being collected there is no guarantee that proper order of destruction is observed. So for now Destroy is just a normal native method to scripted classes
- For most cvars, this is equivalent to calling GetGenericRep() to get a
string.
- For float cvars, it uses %g instead of %H, because %H is generally more
information than is needed.
- replace all implicit conversions from FString to const char * in the header files (so that it can be test compiled with the implicit type conversion turned off without throwing thousands of identical errors.)
- For backward compatibility, you need to indicate that substitution is
allowed in the string by prepending it with a % character:
alias asay "say %\"%1\""
The above will substitute the alias parameter.
alias asay "say \"%1\""
The above will not substitute the alias parameter but use the string
literal "%1" directly.
- Old mess:
* Execute autoexec files right away.
* Execute -exec files right away.
* Execute command line commands right away.
- If, during any of the above, an unknown command or a set of an
unknown variable is encountered, store it for later.
- Pullin commands are directly executed and add to the list of files
to load.
* Do a little setup, including parsing CVARINFOs.
* Retry saved commands in case CVARINFO added a cvar they refer to.
- New, less messy, mess:
* Parse autoexec files into an array.
* Parse -exec files.
* Parse command line commands.
- During all of the above, exec commands are also parsed into the
array immediately rather than being saved for execution later.
- Pullin commands are parsed into a different array. The pullin
command doesn't actually do anything directly anymore.
* Add all the pullin files to the list of files to load.
* Do a little setup, including parsing CVARINFOs.
* Execute every command that was parsed in the preceding steps.
- Fixed: Using +set cvarname and +cvarname on the command line would not
work if cvarname was defined in CVARINFO. This should be the proper way to fix
it. Rather than move all command line execution after loading CVARINFO,
keep command line execution before wads are loaded. If an attempt is
made to set an unknown cvar or to run an unknown command (which could
potentially be shorthand for setting an unknown cvar), save it and try
running it again after all CVARINFOs have been handled.
- Command-line console commands are executed before a level is entered, so
trying to use +warp to position yourself at a specific location will not
work. We now specially handle this command so that it does work.
The 'unix' identifier isn't defined when '-std' is passed to the compiler (tested with gcc and clang), so use '__unix__' which is well enough documented.
