Since door management uses the inventory field to store doorFriends the
last condition was always returning false and locked doors would never
get damage set on them.
The big list of removals in setvariableval.txt and publicvariableval.txt
were duplicates. Other removals are covered by the new regex filter.
Still needs work. If you encounter kicks please post the restriction
type and number along with the log line in the 1.0.6 testing issue.
Updates that were in the 1.0.5.1 release are now included in the main
epoch.sql file, since all servers should have applied them by now.
All new updates since 1.0.5.1 release are now in 1.0.6_Updates.sql.
@icomrade - configFile and missionConfigFile are in different scopes.
Admins can overwrite any dialog in RscDisplay with their own version
included in the mission without getting "class already defined" errors.
I tested to make sure it is possible. So there is no benefit to having
these includes in description.ext.
Varchar(512) was truncating certain vehicle hitpoints and preventing
vehicle loading. The HiveExt dll handles hitpoints as a string which has
a char limit far greater than 512, so simply updating the column should
fix the issue.
Also update the ChracterID column for #1371 - new Hive dll will be
required
Since we are keeping "everything takes up one gear slot" weight should
be enabled by default. Moved to init.sqf so admins can easily change it.
Also added RedRyder and Anzio_20 weight.
Duplicate categories are now marked instead of being listed multiple
times. This makes the configs far easier to maintain. Admins can still
expand each individual category for further customization.
Also moved the dayz_epoch_b stringtable into a dayz_epoch package in the
dayz_code stringtable.
This makes it easier to maintain and search for code strings. Epoch_b
only holds extra models and textures now.
Tool breaking is disabled by default.
Also made all scripts use Epoch sledge, which is a different model from
vanilla sledge.
PK_DZ was a duplicate of the new PKM_DZ.
The hive call in server_publishObject is the same between vanilla and
Epoch. The only difference is vanilla uses the _inventory area for
owner, lock code, etc. variables where as modular Epoch items just store
an empty array there.
The object classname does not need to be sent in the PV because it can
be obtained on the server.
PVDZE_veh_Publish was not used.
It should no longer be necessary to load dayz_vehicles in the
mission.sqm addons. It was taken out of mission.sqm in vanilla around
1.8.
The dayz_logo_ca.paa file was identical to loadingscreen.paa
The protective box is not needed on Chernarus.
If other maps need it we are better off spawning a permanent box around
the debug area once, instead of constantly creating new boxes every time
a player logs in.
Achievements are saved in the state field, so we don't have room to save
friendlies there anymore. DZE_FriendlySaving is removed for now. I will
add it back later with a save to player profile instead.
The dayz_players variable is not used for anything. There were several
other unused variables in server_playerLogin.sqf.
It makes no sense to rename the identical DayZ PVs to have an E in their
name. I don't see any good reason it was done in the first place. All it
accomplishes is breaking script compatibility between the two mods and
requiring different publicvariable.txt filters. The only time it makes
sense is for custom Epoch variables that aren't used in vanilla.
All admins have to do to update custom scripts is swap the names
according to the change log.
Note I've submitted a pull request to replace PVDZ_veh_Save with
PVDZ_obj_Save in official too because they are duplicates.
See:
634214570c
@icomrade - IMO we should use the new blood type system and take out the
config variable. It is not something that can be easily switched between
because it requires manually changing the loot tables and traders which
adds some big files to the mission. Some admins will get confused when
they change the config variable and it doesn't change the loot spawns or
traders.
Admins can make bloodBagONEG abundant on their server if they
don't like it. I think most people will want to use it since it is a
nice extra realism feature and consistent with 1.8.7. We can still leave
the ItemBloodbag class defined in cfgMagazines so admins can go back to
using it if they wish. 1.8.7 even took out the class completely.
