Rob2

Just fixed for the next patch that is due out very soon.

Sorted by Awol, download bornholm.h from Here
Will be included in the next update.

I have been working on a dropin replacement so Epoch can use another db engine, had it workingwith MySQL + Sqlite.
Currently, the dll is writing all "Epoch Data" to a database, it requires no extra changes to files and uses none of Epoch's current code.
I have only implemented "SET" so far but it is running side-by-side on a live server. I also added a tool to import a Redis db too ;)
 

Yep,
 
I can also say, that we have frame drops (or maybe even more like a 2-5 seconds freeze) here and there. We also thought about this. That it seems to occur when AI/sappers are spawning...
Server is only a small server with 2-4 people atm...
 
BR
Rob

OK,
 
after recognizing, that the vehicles purchased from this trader are falling from the air, I added some debugging output and saw, that the trader was spawning the vehicle on the nearest heilpad.
 
However, the location from the helipad is 90m in the air...
 
a3_epoch_server_settings.pbo => configs => maps => bornholm.h
 
change
{ "Land_HelipadCircle_F",{ 14152.4,11356.6,92.9393},0.100796 }
to
{ "Land_HelipadCircle_F",{ 14152.4,11356.6,0.00000},0.100796 }
 
Problem solved.
 
 
However, how to communicate this to the epoch team? Do you see this here? :)
 
BR
Rob

Think someone posted a fix in that thread.

Hello,
 
Epoch 3 has still the same issue like Epoch 2, that the building parts snap to a 10cm grid at server restart, when building at areas that are more than 10000m away from map center. (Note: Y-database-coordinate does not matche the ingame map).
 
The cause is, that in the database the coordinates are stored with 6 digits. For example 9424.68/2156.76 (m). Or another example 1243.57/536.567.
 
The problem is, when you build more than 10km away from the database coordinate center, it only save 15365.2/21564.5 (m). With that alle objects snap to a 10cm grid on the next restart of the server.
 
 
Is there a good cause that the system is not using at least 7 digits?
 
 
In Epoch2 there was a server side script, that fixed the issue, by converting the coordinates to a string before putting them into the database:

 
Maybe that format would be an option, if there is a hardcoded limit to 6 digits. However, I dont know how big the performance impact is.
 
But it would be nice to finally eleminate the "Snap to 10cm" problem.
 
BR
Rob

Message passed on, Awols fixing it now, future updates won't have it :)

Check out the commandMenu settings (security_checks.h in the a3_epoch_server_settings.pbo). This is a whitelist based check so you should be able to add "#USER:ActionMenu" to the allowed array.

 
class commandMenu { menus[] = {"","RscSelectTeam","RscTeam","RscMoveHigh","#GETIN","#RscStatus","#WATCH0","RscCombatMode","RscMenuReply","RscCallSupport","#CUSTOM_RADIO","#User:BIS_fnc_addCommMenuItem_menu","RscRadio","RscReply","#ACTION","RscMenuFormations","#WATCH","RscGroupRootMenu","RscMainMenu","RscMenuMove","RscWatchDir","RscWatchMoveDir","#User:BIS_Menu_GroupCommunication","RscMenuStatus","RscFormations"}; };

Hello,
 
Epoch 3 has still the same issue like Epoch 2, that the building parts snap to a 10cm grid at server restart, when building at areas that are more than 10000m away from map center. (Note: Y-database-coordinate does not matche the ingame map).
 
The cause is, that in the database the coordinates are stored with 6 digits. For example 9424.68/2156.76 (m). Or another example 1243.57/536.567.
 
The problem is, when you build more than 10km away from the database coordinate center, it only save 15365.2/21564.5 (m). With that alle objects snap to a 10cm grid on the next restart of the server.
 
 
Is there a good cause that the system is not using at least 7 digits?
 
 
In Epoch2 there was a server side script, that fixed the issue, by converting the coordinates to a string before putting them into the database:

 
Maybe that format would be an option, if there is a hardcoded limit to 6 digits. However, I dont know how big the performance impact is.
 
But it would be nice to finally eleminate the "Snap to 10cm" problem.
 
BR
Rob

Hello,
 
Epoch 3 has still the same issue like Epoch 2, that the building parts snap to a 10cm grid at server restart, when building at areas that are more than 10000m away from map center. (Note: Y-database-coordinate does not matche the ingame map).
 
The cause is, that in the database the coordinates are stored with 6 digits. For example 9424.68/2156.76 (m). Or another example 1243.57/536.567.
 
The problem is, when you build more than 10km away from the database coordinate center, it only save 15365.2/21564.5 (m). With that alle objects snap to a 10cm grid on the next restart of the server.
 
 
Is there a good cause that the system is not using at least 7 digits?
 
 
In Epoch2 there was a server side script, that fixed the issue, by converting the coordinates to a string before putting them into the database:

 
Maybe that format would be an option, if there is a hardcoded limit to 6 digits. However, I dont know how big the performance impact is.
 
But it would be nice to finally eleminate the "Snap to 10cm" problem.
 
BR
Rob

Hello,
 
Epoch 3 has still the same issue like Epoch 2, that the building parts snap to a 10cm grid at server restart, when building at areas that are more than 10000m away from map center. (Note: Y-database-coordinate does not matche the ingame map).
 
The cause is, that in the database the coordinates are stored with 6 digits. For example 9424.68/2156.76 (m). Or another example 1243.57/536.567.
 
The problem is, when you build more than 10km away from the database coordinate center, it only save 15365.2/21564.5 (m). With that alle objects snap to a 10cm grid on the next restart of the server.
 
 
Is there a good cause that the system is not using at least 7 digits?
 
 
In Epoch2 there was a server side script, that fixed the issue, by converting the coordinates to a string before putting them into the database:

 
Maybe that format would be an option, if there is a hardcoded limit to 6 digits. However, I dont know how big the performance impact is.
 
But it would be nice to finally eleminate the "Snap to 10cm" problem.
 
BR
Rob

Why do you care what he does with his server? rofl.

I would also suggest, to completely disable HT in the BIOS for debugging purposes.
 
HT "just" enables that idle resources of a core can be used from a 2nd thread.
 
As example a Core i3 has 2 "full" cores. With HT enabled it looks like 4 cores to the OS. However, these are not 4 "real" cores.
 
The effect of HT really depends on the calculations that need to be made. When you have a mainly single threaded calculation, it _can_ be better, to disable HT, so that this thread has the "full" core for itself and no scheduling of data needs to be done.
 
Just to rule out this kind of problems, I would completely disable HT in the BIOS and dont use the enableHT option.
 
With HT off each CPU in windows is a "full" core and if you manually set the affinity to one of the cores, the thread has a "full" core to work with.
 
 
PS: I dont want to say in general, disable HT for more performance! HT normally works good. But as I read the problems here, I would disable it for debugging purposes to rule out thread scheduling / affinity issues.
 
See also the first 3-4 post for a (imho) good writeup: Link1
and, if interested: Link2
 
BR
Rob

0.3.0.3 Build 9

Native Linux Support
Thanks to a once over by devd our backend codebase now compiles natively on Windows or Linux. We will now officially support both Linux and Windows Epoch servers. Also included is a modified for Epoch linux start script by BIstudio, and Nasdero.
 
Disabled CRC check
With this check disabled it is no longer absolutely required to update the backend dll with each server build. Updates will still be required from time to time as version checks will still ensure the proper version for compatibility.
 
Battleye Integration
Direct integration with Battleye means we now have the following features server side: Requires (IP,Port,password) to be specified via the epochserver.ini. Some features are for future EAH updates and documentation will be provided for use server side by modders.
shutdown - shuts down the server with the #shutdown command. lock/unlock - lock and unlock the server. message - Broadcast a message to everyone from BE say command. kick - Kick user with message. ban. - Ban user with message and duration. Scripted Server Restarts
When enabled this feature will broadcast a message 5 minutes before restart and lock the server. Then message every 1 minute, till it kicks everyone from the server with the message "Server Restarting" before forcing a restart. This will ensure everyone saves before the server shuts down. Default state of this feature is disabled, when enabled the server will restart every 4 hours (14400 seconds). This can be changed via the epochconfig.hpp.
 
Optimization and Data Reliability
Optimized writing/reading more than 8K chars to database and fixed an Issue with potential data corruption issue when saving data.
 
NPC Traders Roaming
By default traders and their markers should now move with as they move from work to home. Server side trader FSM updated to fix direction issues.
 
General Fixes
Removed "srifle_DMR_03_spotter_F" from loots.h as it is missing textures.
If a player logs out in a vehicle they will be moved to the nearest static trader city.

 
 
EAH 2.0
 
More Config Driven.
Most all security checks can now be enabled/disabled and/or configured via security_checks.h inside epoch_server_settings.pbo.
 
Whitelist Variable Scanner with Learning Mode.
This scanner has the ability to ban any user that has a global variable set that is not explicitly allowed via whitelist. This check is disabled by default as it requires some setup to prevent false positives. Before enabling the variable scanner you need to profile your server so the server knows what variables to trust. Learning mode should only be used with a trusted group of players then disabled after profiling is complete.
 
Battleye integration
With the integration of loadbans and loadevents, (BEC + watchdog) should no longer be required to use EAH.
 
Forced Quality and Viewdistance
This feature forces all players to have the same viewDistance and terrain detail. Changes can be made in server settings pbo.
 
 
-- 
 
 
0.3.0.2 Build 20 Notes [Fixed] Linux start script path was incorrect.
[Fixed] Typo in EAH that caused issues with Autoban #R2  [info] Recompiled epochserver.so on Debian 7.8 to increase Linux compatibility.  [Fixed] Windows EOL on epoch_linux_startscript.sh [Changed] Updated BE filters to resolve reported kicks since 1.44 was released.  (setvariableval.txt and publicvariable.txt)
[Changed] Bump requiredBuild to 130654 in config.cfg
[Changed] Updated Loots.h:
to spawn 150Rnd_762x54_Box for Zafir instead of 150Rnd_762x51_Box added 130Rnd_338_Mag to MachinegunAmmo class (cfgPricing was updated with client build 0.3.0.3)

Insert this to the client-only part of your init.sqf or put it in an external sqf-file and execute it via execVM-Call:
 
"dayzEpochRmvWreck" addPublicVariableEventHandler { private["_list","_iPos","_iType"]; _iType = (_this select 1) select 1; _iPos = (_this select 1) select 0; _list = nearestObjects [_iPos, [_iType], 3]; {deleteVehicle _x;} foreach _list; }; I gues you already use a customized remove.sqf? Then here are my changes...

Find the line that says "sleep 0.1;", BEFORE this line you add the following:
private["_notNearestPlayer"]; _notNearestPlayer = _obj call dze_isnearest_player; if (_notNearestPlayer) then { cutText ["Another player is to close - Canceled deconstruction", "PLAIN DOWN"]; r_doLoop = false; }; Now search for the line that says
if (_isMine) then { and after it you insert:
dayzEpochRmvWreck = [getPos _obj,_objType]; publicVariable "dayzEpochRmvWreck"; I hope i havent forgot anything, ah... you need to adjust your publicvariable.txt of battleye... just add !="dayzEpochRmvWreck" to the first kick-line.