There's simply never enough of them and they are used far too infrequently to justify the hassle of tagging along two TMaps per class.
For what they provide, single global lists that handle all player classes at once are fully sufficient.
The math in DCanvas::FillBorder does not always work out so better clean the entire screen before drawing a fullscreen image to ensure that the menu blend is always drawn over something valid.
CVAR with this flag can be set in console or from command line when sv_cheats is enabled
There is no such restriction for changing its value from ACS, via SetCVar() and related functions
'cheat' modifier can be used in CVARINFO lump to create variable of this kind
The idea is, when status bars are moved to ZScript that only this small wrapper class needs to be dealt with and the implementation can be left alone. SBARINFO is far too complex to be scriptified, but having it inherit directly from DBaseStatusBar and access its member variables severely limits the options of dealing with the status bar code. This way, it only accesses some globally visible functions in DBaseStatusBar and no variables.
- renamed the global ST_X and ST_Y variables because it is far too confusing and error-prone to have the same names inside and outside DBaseStatusBar.
This was done to ensure it can be properly overridden in scripts without causing problems when called during engine shutdown for the type and symbol objects the VM needs to work and to have the scripted version always run first.
Since the scripted OnDestroy method never calls the native version - the native one is run after the scripted one - this can be simply skipped over during shutdown.
The original implementation just printed a mostly information-free message and then went on as if nothing has happened, making it ridiculously easy to write broken code and release it. Changed it to:
* Any VMAbortException will now terminate the game session and go back to the console.
* It will also print a VM stack trace with all open functions, including source file and line numbers pointing to the problem spots. For this the relevant information had to be added to the VMScriptFunction class.
An interesting effect here was that just throwing the exception object increased the VM's Exec function's stack size from 900 bytes to 70kb, because the compiler allocates a separate local buffer for every single instance of the exception object.
The obvious solution was to put this part into a subfunction so that it won't pollute the Exec function's own stack frame. Interesting side effect of this: Exec's stack requirement went down from 900 bytes to 600 bytes. This is still on the high side but already a lot better.
- instead add a list of SpecialInits to VMScriptFunction so this can be done transparently when setting up and popping the stack frame. The only drawback is that this requires permanent allocation of stack objects for the entire lifetime of a function but this is a relatively small tradeoff for significantly reduced maintenance work throughout.
- removed most #include "vm.h", because nearly all files already pull this in through dobject.h.
* everything related to scripting is now placed in a subdirectory 'scripting', which itself is separated into DECORATE, ZSCRIPT, the VM and code generation.
* a few items have been moved to different headers so that the DECORATE parser definitions can mostly be kept local. The only exception at the moment is the flags interface on which 3 source files depend.
- _FPU_GETCW is defined for more than just x87. Don't use it if the
control word for the target architecture doesn't support _FPU_EXTENDED
or _FPU_DOUBLE defined, e.g. pretty much anything but x87. If I had been
using glibc on PowerPC instead of Apple's libc, I probably would have
noticed this sooner, since _FPU_GETCW is part of glibc.
- handle a 'restart' CCMD a bit more controlled. Instead of throwing an exception in the CCMD handler it now just flags D_DoomLoop to return.
If the exception is thrown within the CCMD this can easily happen deep inside the renderer when it calls NetUpdate. But since the software renderer with its use of global variables is not equipped to be yanked out of lile this it could leave broken data behind that caused glitches or even crashes on subsequently played maps.
This cuts down on as much message noise as possible, outputs everything to a file specified as a parameter and then quits immediately, allowing this to run from a batch that's supposed to check a larger list of files for errors.
Multiple outputs get appended if the file already exists.
- This isn't a real file or even a name, but the game would try and load
it, including running through various permutations, potentially resulting
in loading the current directory as an archive.
This requires quite a bit more thorough cleanup. I got it to the point where the titlepic appears after restarting, but it still crashes when starting the game so there's more data that needs to be cleaned up...
Conflicts:
src/p_mobj.cpp
(This stops right before moving the conversation IDs into MAPINFO because that feature is quite conflict-heavy and will have to merged by itself.)
Conflicts:
src/d_main.cpp
src/info.cpp
src/p_local.h
(Had to merge this all by itself because it was creating too many merge conflicts when combined with other stuff.
UpdateSounds will not be called during screen wipes and the entire setup of this function suggests that this is not advisable at all.
The OpenAL stream updates were done deep inside this function implicitly.
This caused music to stop while a wipe was in progress. So in order to allow uninterrupted music playback during screen wipes the music updates need to be handled separately from sound updates and be called both in the main loop and the wipe loop.
I think that the OpenAL music updating should be offloaded to a separate thread but at least it's working now without causing interruptions during wipes.
- 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.
This has an important implication:
Previously the config was loaded before IWADINFO so in order to allow the config to access the data this had to be switched around.
This means that zdoom.pk3 will not be looked for in the global IWAD search paths anymore, but since it shouldn't be there to begin with it should be an acceptable compromise.
As a result the old 'Group' property could be removed and all other means to get a section name were disabled.
As an example, if the code gets 'doom.doom2.commercial' it will use the following sections in this order:
global.autoload
doom.autoload
doom.doom2.autoload
doom.doom2.commercial.autoload.
- Multi-directory archives (e.g. zips) now support filtering lumps
depending on the loaded IWAD. The search rules are the same as for the
Autoload entries in the user's ini. For instance, if you are playing
Doom 2, the following filters will be applied:
* "filter/doom2/*"
* "filter/doom/*"
They will be renamed to strip out the "filter/doom2/" and "filter/doom/"
parts and will be ordered so they take precedence over any files not
inside a filter/ directory. Any files inside another filter/ directory
(e.g. "filter/hexen/*") will be ignored.
- 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.
Conflicts:
src/CMakeLists.txt
src/b_think.cpp
src/g_doom/a_doomweaps.cpp
src/g_hexen/a_clericstaff.cpp
src/g_hexen/a_fighterplayer.cpp
src/namedef.h
src/p_enemy.cpp
src/p_local.h
src/p_mobj.cpp
src/p_teleport.cpp
src/sc_man_tokens.h
src/thingdef/thingdef_codeptr.cpp
src/thingdef/thingdef_function.cpp
src/thingdef/thingdef_parse.cpp
wadsrc/static/actors/actor.txt
wadsrc/static/actors/constants.txt
wadsrc/static/actors/shared/inventory.txt
- Added register reuse to VMFunctionBuilder for FxPick's code emitter.
- Note to self: Need to reimplement IsPointerEqual and CheckClass, which
were added to thingdef_function.cpp over the past year, as this file no
longer exists in this branch.
Even when '+logfile' argument was omitted, the console would print 'Could not start log', because 'logfile != NULL' was used as a check for the presence of '+logfile' argument, but the internal buffer of FString is never NULL, so the right check is 'logfile.isNotEmpty()'.
While I'm at it, I fixed another bad check for 'pagename'.
- added version check for Windows 8. I also would have liked to add 8.1 but due to some incredibly stupid changes in the version API it's no longer possible to reliably retrieve the correct Windows version for later builds.
- 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.
- Fixed: You could not set any CVARINFO-defined cvars from the command line
because command line console commands were executed before wads were
even loaded. Off the top of my head, I can't think of anything that would\
break by having them get executed after wads are loaded.
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.
- Separated CVAR_MODARCHIVE into CVAR_MOD|CVAR_ARCHIVE so that mod-defined cvars can still be
identified when they aren't meant to be archived.
SVN r4281 (trunk)
of the form:
<scope> [noarchive] <type> <name> [= <defaultvalue>];
Where <scope> is one of:
* server: This cvar is shared by all players, and in network games, only select players can
change it.
* user: Each player has their own copy of this cvar, which they can change independently.
To prevent the cvar from being written to the config file, add noarchive to its definition.
<Type> is one of:
* int: An integral value. Defaults to 0.
* float: A value that can include a fraction. Defaults to 0.0.
* color: A color value. Default to black ("00 00 00").
* bool: A boolean value that can hold either true or false. Defaults to false.
* string: A string value. It's not too useful for mods but is included for completeness. Defaults to "".
<Name> is the cvar's name and must begin with a letter and may only include alphanumeric
characters and the underscore character.
If you wish a non-standard default add an = character after the cvar's name followed by the
default value you want to use. Example:
server int mymod_coolness = 10;
- Fixed: FStringCVar::SetGenericRepDefault() did not make a copy of the input string.
SVN r4280 (trunk)
* HUDMSG_NOTWITH3DVIEW : This message does not appear when the 3D view is active.
* HUDMSG_NOTWITHFULLMAP : This message does not appear when the fullscreen automap is active.
* HUDMSG_NOTWITHOVERLAYMAP : This message does not appear when the overlay automap is active.
These flags may be combined, so for example: HUDMSG_NOTWITHFULLMAP | HUDMSG_NOTWITHOVERLAYMAP
would prevent the message from appearing if any form of automap is active.
- Added HUD message layers, which are ORed into the type field:
* HUDMSG_LAYER_OVERHUD : This is the default and standard behavior. The message appear on
top of most HUD elements. This definition is just included for completeness' sake; you
don't need to explicitly use it.
* HUDMSG_LAYER_UNDERHUD : The message appears underneath other HUD elements, such as the status bar.
* HUDMSG_LAYER_OVERMAP : The message appears on top of the fullscreen automap. At the moment,
this layer is functionally equivalent to using the flags HUDMSG_NOTWITH3DVIEW | HUDMSG_NOTWITHOVERLAYMAP.
However, if Blzut3 decides to implement support for drawing the automap permanently on a
second screen, messages on this layer will move to that screen with the automap and be permanently
visible as long as the map is visible on that other screen.
These are not flags, so for example HUDMSG_LAYER_UNDERHUD | HUDMSG_LAYER_OVERHUD is not valid.
SVN r3821 (trunk)
