continue spinning until the next time around because the check for moving too fast was only
done after the polyobject had been rotated once.
- Reduced the potential for overflow when setting up the speed of a rotating polyobj.
SVN r4332 (trunk)
int SpawnDecal(int tid, str decalname, int flags, fixed angle, int zoffset, int distance)
Traces a line from tid's actor until hitting a wall, then creates a decal there. Returns the
number of decals spawned.
* tid = Which actor(s) to start the trace at.
* decalname = Which decal to spawn.
* flags =
* SDF_ABSANGLE = Angle parameter is an absolute angle. Otherwise, it's relative to the origin actor's angle.
* SDF_PERMANENT = Decal ignores cl_maxdecals. Otherwise, it will eventually disappear.
* angle = Direction in which to search for a wall. Defaults to 0.0.
* zoffset = Offset from the middle of the origin actor for the Z height of the decal. Defaults to 0.
* distance = Maximum distance to search for a wall. Defaults to 64.
SVN r4330 (trunk)
- Fixed: ACSStringPool::InsertString()'s overflow check was far too low.
- Fixed: When ACSStringPool::InsertString() triggered a garbage collection, it ignored the
newly freed space and expanded the array anyway.
SVN r4328 (trunk)
- fixed: UDMF's ZDoomTranslated namespace needs to set the DUMMYSWITCHES flag so that it remains compatible with Doom-format ZDoom maps.
SVN r4325 (trunk)
of taking an actual sound name as its second parameter, it selects the sound to play based on
the actor playing the sound and the selector passed as the second parameter.
SVN r4323 (trunk)
* The standard C functions strcmp and stricmp (aka strcasecmp), which double up as strncmp and strnicmp if you pass a third argument.
* The BASIC-like functions strleft, strright, and strmid, which extract parts of a string to
create a new string.
SVN r4313 (trunk)
counterparts except that (1) PlaySound requires you to specify a sound instead of defaulting
to "weapons/pistol", and (2) StopSound defaults to CHAN_BODY instead of CHAN_VOICE.
SVN r4306 (trunk)
major change to ACS's workings. However, I had an epiphany yesterday and just had to do this, since it seems like too big a deal to hold off until a later release:
- Dynamically generated strings returned via strparam and get(user)cvar now last as long as they
need to. They do not disappear at the end of each tic. You can now safely store them in
variables and hold on to them indefinitely. In addition, strings from libraries no longer
require you to load the exact same libraries in the exact same order. You can even store a
library's string in a world variable and retrieve it on another map that doesn't load the
library at all, and it will still be the correct string.
- ACS library IDs now only get 12 bits instead of 16 so that each string table can hold up
to about a million strings instead of just 65536. This shouldn't be a problem, although it
means that save games that had strings with the larger IDs stored in variables are no
longer compatible. Since many saves don't involve libraries at all, and even many that do
are not actually affected, I'm not bumping the min save version. The worst that can happen
is that you get no text at all where some was expected.
SVN r4295 (trunk)
counterparts, except that they return strings. Like strparam, the strings they return are
only guaranteed to be valid for the tick they are called during. (Note that these work with any
cvar, not just string ones.)
SVN r4293 (trunk)
counterparts except that their value argument is an ACS string. (Note that they work with any
type of cvar, not just string cvars.)
- Make UCVarValue::String point to a constant string.
SVN r4292 (trunk)
* int GetUserCVar(int playernum, "cvarname")
* bool SetCVar("cvarname", newvalue)
* bool SetUserCVar(int playernum, "cvarname", newvalue)
GetUserCVar is analogous to GetCVar, except it returns the value of a user cvar for a
specific player. (All user cvars can be examined using the playerinfo console command.)
SetCVar sets a cvar to a new value. If the cvar is floating point, then newvalue is treated
as a fixed point number, otherwise it's treated as an integer. SetUserCVar is the same, but
for a specific player's user cvar.
SetCVar and SetUserCVar can only change cvars created via CVARINFO. They cannot alter built-in cvars.
If you use GetCVar or SetCVar with a user cvar, they will act on the copy of the user cvar
for the player who activated the script. e.g.
GetCVar("gender")
is the same as
GetUserCVar(PlayerNumber(), "gender")
If you get the value of a floating point cvar, it will be returned as a fixed point number.
Otherwise, it will be returned as an integer.
SVN r4283 (trunk)
- 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)
number to represent a flag combination is stupid unreadable now that there's more than just
the two possibilities it had when it was first written.
SVN r4278 (trunk)
