ProGEEK

OS: Windows Server 2016 Hardware: Irrelevant, this is a code bug ArmA: latest Version 64bit Exile: 1.0.4a Throwing this in here from Discord - Issue and Fix: Hm, i keep getting Max hacks in progress error message when the hack completes @ 100% and is the only hack happening on the server - Max hacks is set to 1 (We dont want more than one at any one time going on, on our server). Looked over the code, and noticed that the check for hacks doesnt ignore the current player that is mid-hack(edited) in ExileClient_action_hackLock_condition Shouldnt _concurrentHacks = {_x getVariable ["ExileIsHacking", false]} count allPlayers; be (So that it ignores what the current player is doing, but checks what all other players are doing.) _concurrentHacks = {!(_x isEqualTo player) && _x getVariable ["ExileIsHacking", false]} count allPlayers; Since ExileClient_action_hackLock_condition fires off every few seconds, and this gets set later on in that file: player setVariable ["ExileIsHacking", true, true]; Tested the above change, and it fixed my issue. Hack in progress and another couldn't start. Hack succeeded without the error. Bumped max concurrent hacks to 2, 1st and 2nd hacks worked fine, 3rd was unable to start as expected

Just stumbled onto this issue myself. This is a good workaround for now. Why they're referencing an object by a non-unique column is beyond me, They should be using the vehicle ID in all queries etc, that at least is already unique and directly identifies the vehicle..

Got it working. Seems the issue was the format used when uploading the file. Didn't like Text/ASCII. Uploaded in BINARY format and now works.

Several times yes. Mind PMing me your XM8 DLL files ?

Mine has 7bc9df374246b540f596cd24e651b2d906be8792 6179c1ebf9c6d442d47f32e4a4b9ac6cb41f2105

XM8_x64.dll is giving me Malformed Config File (Using the dll that Kuplion linked to back in October) 21:39:06 CallExtension loaded: XM8 (C:\A3Servers\ExileLingor\@ExileServer\XM8_x64.dll) [|t_aX] 21:39:06 "ExileServer - XM8 mesage sent: {""r"":[""XXXXXXXXXXXXXXXXX""],""m"":""protection-money-paid"",""t"":""Meseeeeeeks""} ([1,'Malformed config file'])" Have renamed the file to XM8_ExileXM8Key.cfg as per the instructions: Key works fine with the 32-bit DLL Anything Im missing? or does this DLL simply not work yet ? This DLL also is not blocked. Running on Windows Server 2016 Standard, all vcredist packages installed (both x86 and x64 versions where available)

= DELETED = Caused by overridden code

I found in my testing / implementation that the following error only occurred on our production server, and not our test (Our test server is much faster than our prod) and I think its because Occupation was initializing before DMS postinit had completed (Or in some cases, even started) 14:14:26 Error in expression <etLocs select (_attempts - 1) } else { [DMS_MinMax_X_Coords call DMS_fnc_SelectR> 14:14:26 Error position: <DMS_MinMax_X_Coords call DMS_fnc_SelectR> 14:14:26 Error Undefined variable in expression: dms_minmax_x_coords 14:14:26 File x\addons\dms\scripts\fn_FindSafePos.sqf, line 70 I have created a pull request with my code that fixes this for us, which is does by spawning a non-blocking thread for the occupation init, then waits until DMS_MinMax_Y_Coords has been defined (As that appears to be the last variable that is defined in the DMS post-init) Since putting in my fix, the error-spam from this function went away and the script has been spawning box's with guards as expected. https://github.com/secondcoming/a3_exile_occupation/pull/1 May be of some use to you

Epidemic Exile PvE Server located in Sydney, Australia We feature: Cup Units, Weapons, Vehicles AI Missions Town Invasions Roadblocks Supply Drops 400 piece build limit Recruitable AI

I'm so in!

The seem to go invincible if they pass through a trader zone ive noticed

Dunno about the generic expression error, but the error in your extdb log is caused by the UNIX_TIMESTAMP() in the exile.ini file in the @ExileServer\extDB\sql_custom_v2\ folder I found that by removing the UNIX_TIMESTAMP() that the DATE_SUB(NOW(), INTERVAL ? DAY) is wrapped in fixed it for me. So DELETE FROM territory WHERE last_paid_at < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL ? DAY)) becomes DELETE FROM territory WHERE last_paid_at < DATE_SUB(NOW(), INTERVAL ? DAY) I did this for all the delete methods that had it. (deleteOldContainers, deleteOldConstructions, deleteOldVehicles and deleteUnpaidTerritories) Back up this file and your DB first though, just in case..

I didnt wipe our DB, i upgraded it using the script in the releases section of the forum. SQL Update Script for 0.9.4 Only issues we are having is from third-party scripts (Stuff we've added or modified that is not part of or overrides core parts of Exile) Cant blame Exile for third party scripts not working (Its nothing to do with them) Refuelling heli's doesnt work, but the Arma 3 1.54 update broke that for us

Works fine on my server

I think I may have found an issue with the following exile.ini cleanup commands: deleteOldContainers deleteOldConstructions deleteOldVehicles deleteUnpaidTerritories I have tested this on the territory table using the deleteUnpaidTerritories command. (I have a territory last_paid_at set to 2015-01-01 for testing purposes) Adapted to be a select instead of a delete (I removed the DELETE keyword and added SELECT * so i could see what was being returned/wht would have been deleted): SELECT * FROM territory WHERE last_paid_at < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 14 DAY)) Produces the following warning and returns no results: "Incorrect datetime value: '1448678464' for column 'last_paid_at' at row 1" Modifying the query to remove the UNIX_TIMESTAMP() block fixes this and I get the 1 result I was expecting: SELECT * FROM territory WHERE last_paid_at < DATE_SUB(NOW(), INTERVAL 14 DAY) With the original query, territories are not being deleted. Original: DELETE FROM territory WHERE last_paid_at < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL ? DAY)) Modified to work: DELETE FROM territory WHERE last_paid_at < DATE_SUB(NOW(), INTERVAL ? DAY) This testing was performed on a MySQL server with version 5.6.17