There is no point in having CfgBuildingPos.hpp in dayz_epoch_b too. It
was identical to the one in dayz_code and can be included in the mission
from there.
@icomrade couple questions:
1. Why keep a CfgLootLegacy? I know they are very different formats, but
it will just make things messier and more confusing. Also it will be a
PITA to maintain and update two different sets of loot tables in the
long run. I don't think catering to lazy admins is a good enough reason.
It's not that hard to convert to the new format.
2. Why not use the new _DZ weapon classes in the loot tables like
PDW_DZ, AKM_DZ, etc.?
3. Why not use the new box names like DZ_AmmoBoxRU, DZ_AmmoBoxUS,
DZ_MedBox, etc. in the loot tables?
4. Why remove the attachments from the loot tables?
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.
The only difference between this and the previous version is:
1. Container tags removed
2. Comments added back in
3. str_usract_watch_toggle, str_usract_watch and str_itemwatch are not
commented out. These should not be duplicates if we are using the new
languagecore.xml (according to the comment). If it is a duplicate we
should fix it on 1.8.7 too (after confirming it there).
Using the unmodified file directly from 1.8.7 dayz_code makes it easier
to compare for future updates.
Needed to add it to variables.sqf lists.
@icomrade - Any reason FireBarrel_DZ was removed? I think we still need
it, since it is an epoch buildable class, unless we merge it with
Land_Fire_barrel.
These changes are consistent with the 1.8.7 files.
@icomrade - Why did you change all of the scope = public; to scope = 2;
in dayz_code? They should be identical since that is included in the
basicDefines.hpp above all configs. We should stay consistent with 1.8.7
and use the human readable names if possible.
Also any reason you left out these extra CfgActions?
@icomrade - I'm going to start reviewing and testing the commits you've
done here. I'll commit any fixes and additional 1.8.7 stuff that is
needed to this 1.8.7-Rebase branch. Once we have it in a functional
state we can merge it into master if that's good with you.
Let me know if you are working on any files in particular so we don't
duplicate efforts. I'll be in discord while I'm working here too.
The journal is now functional. Preliminary strings are added for the
1.8.7 crafting system, but it is disabled for now.
I've messaged @marceldev89 (ziellos2k) and @AlbyBDPK on the DayZ forums
to ask permission to use fn_updateCraftUI, player_checkRecipe and
player_craftItemGUI. Are you guys okay with us including these in DayZ
Epoch 1.0.6?
@raymix in most of your helper functions you are using exitWith {}; in
the same way the main player_build uses it. The problem is exitWith
inside of a called function only exits that function, not the parent
script it was called from.
When a helper function exits the main script continues on with undefined
variables and other problems. The easiest solution was to just remove
these helper functions for now. I just directly substituted their code
back into the main modular_build file and removed the passes to and from
them.
We should consolidate player_build and modular_build into one file first
since they are about 80% identical. After that we need to integrate
plot4life. Dividing player_build up into smaller sub functions like this
can be left for last.
I tested this thoroughly and can confirm the undefined errors are fixed
now.
NearObjects "All" counts things like local plot markers, weapon holders,
ambient life, etc. We only want to count buildables. The radius should
also start at the plot pole if available, not the player position.
Thanks to Epoch forums user jOoPs for pointing this out. I will fix this
in modular_build.sqf too.
Tested and confirmed working.
Tested while autorunning:
- getting knocked out
- breaking legs
- running into water
- getting into and out of vehicles
- climbing a ladder
- dying
- antiTP enabled
- running up steep hills
- as player zombie
Everything works as expected. This does allow you to run up and down
pretty steep hills, but if you try to scale something too steep you will
break your legs as expected.
A five minute knockout timer for combat logging is far too long. Most
players will just leave the server and join another. Two and a half
minutes is more bearable.
This is identical to the lingor mission. The only change is "ibr_dingor"
added in mission.sqm. Admins can use the lingor files for dingor. The
two maps are the same apart from the desert skin. There are currently no
servers running dingor at the time of writing this.
This is an exact duplicate of the smd_sahrani_A2 mission. The only
difference is the "oac_core" addon in mission.sqm. That addon is no
longer used in any of the current versions of the map.
I put all the old trader city mission.sqf files from
dayz_server\missions\ in the TraderCitySources folder for reference. I
renamed the folders to instanceNumber.mapName to be more organized.