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)
DECORATE). Then you can use:
* Bounce
* Bounce.Floor
* Bounce.Ceiling
* Bounce.Wall
* Bounce.Actor
* Bounce.Actor.Creature
Partial matches work just like Pain states, so if an actor bounces off a floor and you don't
have a Bounce.Floor state, but you do have a Bounce state, it will use the Bounce state.
Conversely, if you only have a Bounce.Floor state but no Bounce state, then the actor will
only enter the Bounce.Floor state when it bounces on a floor; bouncing off anything else will
not cause it to change state.
SVN r4250 (trunk)
When set, the actor will run this state during its first tick. This means Spawn
states may now run an action function if you set this flag. Note that this action function
is executed during the actor's first tick, which is not the same as when it is spawned.
SVN r4240 (trunk)
once in the level struct and then use that for sectors with a NULL skybox. This fixes zpack's
E2M3 so that when it removes its sector stacks, you will get the default skybox in their
place, since stacked sectors and skyboxes use the same pointers in a sector.
SVN r4224 (trunk)
the camera is on. Mostly, this means testing the distance of the camera to the plane rather
than computing the plane's Z at the camera and comparing that with the camera's Z.
SVN r4220 (trunk)
TOUCHY flag set, or checking the position of the unmorphed version will kill the morphed
version, since they will both exist in the same place at the same time, and TOUCHY is
really touchy about that.
SVN r4219 (trunk)
infighting is disabled; let the normal conditions apply. Otherwise, you end up with situations
where monster-fired projectiles can collide with pickups.
SVN r4198 (trunk)
whatever spawned the random spawner already took care of this.
- Added a maxdist parameter to P_CheckMissileSpawn() to help ensure that it doesn't completely
move the spawned missile outside of its shooter (and potentially beyond a wall the shooter
might happen to be standing next to).
SVN r4194 (trunk)
