Scaramanga

This will break salvage for everything that's not a car. I prevented this by adding the following around line 8.
_hitpoints = _vehicle call vehicle_getHitpoints; if (((typeof _vehicle) isKindOf "Bike") or ((typeof _vehicle) isKindOf "Motorcycle")) then { _hitpoints = ["HitLFWheel","HitLBWheel"] }; if (((typeof _vehicle) isKindOf "ATV_US_EP1") or ((typeof _vehicle) isKindOf "ATV_CZ_EP1")) then { _hitpoints = ["HitLFWheel","HitLBWheel","HitRFWheel","HitRBWheel"] };

Thank you very much for point me in the right direction. Now it's working pretty good :)
 
I solve it following your instructions. This is what I did:
1. I opened the file "Crafting_Defines.hpp" and went to line 122. (class RscListBox)
2. I deleted all that class, from line 122 to 161
3. I saved it, uploaded it and tested it. And it worked fine. No errors and server loading ok.. :)
 
NOTE: This happened because Im using Epoch Admin Tools on my server. Otherwise, this procedure wouldnt be necessesary.
 
Now, I just have to think about how to introduce this new advanced building feature to my server's economy :)
 
Thanks hogscraper for your help and for your incredible script. I'll keep testing it and I'll report any issue :)
 
Have a nice day.

You are launching the game with -showScriptErrors parameter.

Did you try the search above?
http://epochmod.com/forum/index.php?/topic/15562-dze-buildinglimit-questionshelp-increase-30m-size/?hl=%2Bbuild+%2Blimit#entry116479

I have a little problem with the Banks: I am getting kicked for Public Variable Restriction #3
 
This is my publicvariable.log (last entry):
21.08.2014 02:54:48: Fluffy Unicorn w/ Razor (79.254.119.89:2304) ef7a878a43795fe0c10f80f7b99c1fff - #3 "PVDZE_bank_Save" = [<NULL-object>] This is my publicvariable.txt (first 3 lines):
//new 5 "" !"PVDZE_" !"norrn" !"usec" !="remExField" !="remExFP" !="drn_AskServerDynamicWeatherEventArgs" !="norrinRAlie" !="BIS_effects_gepv" !="dayzPlayerLogin" !="dayzPlayerLogin2" !"PVAHR_" !="PVAH_AdminReq" !="PVAH_WriteLogReq" !="PVDZE_bank_Save" 1 "norrn" !="norrnRACarUp" !="norrnRAPicUp" !="norrnRaDrag" !="norrnR180" !="norrnRalie" !="norrnRLact" !="norrnRALW" !="norrnRDead" !="PVDZE_bank_Save" Can anyone say me why i am getting kicked? I already removed the !="PVDZE_bank_Save" in the "norrn" line but it didnt help.

Keep your eyes peeled today and this week. I've got free time to develop today. ;)

Quick update.

Ill be uploading benchmarks and teaser footage by late tomorrow.

So far I havr had massive success with this project. I am not normally one to gloat but thr DZHC works with things I didnt think possible.

A quick technical overview for those interested. The HC now works via its own PBO. Files are still needed in the mission file and server pbo but these are just compiles and variables. All HC handoffs can run via the HC pbo which means TINY mission files and protected scripts :)

I have currently ported zombie spawning and WAI with absolutely no technical difficukty. Took 5 minutes to modify them to work.

And perhaps the most awesome and unexpected news of all:

Buildings running PURELY on the HC only. Clients seem to recieve it in a stream. The advantages so far are a 25% improvement in client FPS and much quicker load times for players.

Im currently running tests with 100's of AI and zombies statically spawned. I will also run tests using non-static spawns and report back FPS details.

I have also forked the epoch git and I plan to integrate the system into the base code following the coding practices currently employed by the dev team (init variables to enable/disable etc). If your interested VB, ill send a link to that fork once I am confident it will work.

Signing off for the night gents and ladies!

Hi all,
 
I just wanted to post to share a project that I am almost finished and get some input/suggestions as to the degree of features and flexibility I will add.
I'll start by providing a current overview of what this can and cant do, and leave the floor open for criticism, suggestions and the like.
 
I started this after becoming frustrated with the lack of decent modifiable headless clients available for ARMA and ARMA mods alike. Each HC was designed with a particular purpose in mind and was not easily configurable. I then decided that the HC's available simply were not going to cut it and set out to write my own - But with a few differences.
 
Key Features
Standalone framework Multiple headless client support Server controlled headless clients Start/Stop headless clients in realtime. Assign priorities to headless client tasks Server/Client/Headless handover support Client framework for client specific variables Headless client automation system Minimal network usage Easy set up and configuration Object Orientated design for performance (To come, this one is HARD) AND my personal favorite;
Dynamic response to low client/server FPS. Ill go over some of these in a little more detail;
 
Standalone framework
 
None of the code is reliant on DayZ, Epoch or otherwise. It should easily be compatible with any ARMA server or modification.
 
Server controlled HC
 
The HC is controlled 100% by the server. The server issues commands, monitors the HC's connection status, issues the override commands and terminates any appropriate threads. I made it this way because there will be circumstances where interaction with the HC might be desired by the admin and automation of tasks required it. This will mean that you can override a particular HC's default function from within the game environment. 
 
Start/Stop HC in realtime
 
As a consequence of the above, the ability to control HC's is paramount. The HC already has an inbuilt automation system (see below) but allows for manual override at any time. This means admins actively monitoring their performance can kick in a another HC and offload a task currently assigned to another HC to it. If your HC is maxing its threads, you can manually hand-off some code to another HC to cope with the load. 
 
Assign priorities to headless client tasks
 
Each hand-off is deemed as a HC task. You can assign priorities to these tasks to ensure peak performance at all times. If a HC is struggling with load, it will dynamically seek to remedy the issue by offloading lower priority tasks to either the server, client or another HC.
 
Client framework for client specific variables
 
A set of event handlers designed to handle client specific variables (player etc). This is so even client scripts could technically be handed off to a HC for processing and only the end result gets processed on the client. This should result in massive FPS improvements for clients and server alike. 
 
Headless client automation system
 
Each HC is controlled by the server and the server is designed to dynamically allocate tasks to available HC's. It also makes sure that they are still connected and responds appropriately if a HC disconnects without warning. It knows exactly what tasks the HC was running and tries to reallocate these tasks to an available HC, and if none are available, it hands them back to the client/server and waits for a HC to connect. Once there is a HC available, its will reallocate these tasks back to the HC. 
 
Dynamic response to low client/server FPS.
 
Perhaps my favorite idea, this means that the server and clients actively monitor their FPS in bursts. If these values fall below their thresholds (configurable), then the server/client will kick in and request a HC hand-off. Both clients and server will have to assign which scripts are capable of an override and assign priorities to them, but the idea is simple. When the client/server suffers - offload everything it can to an available HC.
 
Minimal network usage/optimisation
 
All network messages sent and received are strict - they are only issued to the machine that actually needs them. The HC system is also smart enough to know when a message is being sent by a headless client and will queue other messages until it is ok to send them. This results in far better performance and minimises the risk of duplicate messages/threads being initialised. During periods of network congestion (Perhaps an ill fated basic.cfg) it will respond by reallocating the task back to the client/server (to prevent network lag at the locality the script belongs to).
 
 
 
 
 
Things that I want to implement;
 
Secure script system
 
The ability to encode your current scripts that are mission side (Buildings/AI/Whatever) so that they are harder to be stolen without your server.pbo. This will work based of UID's of the server (unsure if possible yet, its just an idea). 
 
Online Headless Compatibility Wizard
 
A wizard that allows you to post your current code and check for compatibilty issues with the headless framework (variables like player, addMagazine etc) and provide suggestions for how to fix the issues. 
 
 
Github link (Coming soon)
 
So guys and gals.... What do we think?

Having the same old guns are getn a lil boring...Think its about time to spice it up a lil? Id like to see the guns in overwatch added to epoch..NOW THAT WOULD BE EPOCH!

I was about to add some events for cleaning up old vehicles in my Database (1.2.0.5) when I noticed something really strange. It seems a lot of my vehicles automaticly get a new timestamp in the LastUpdated column every time the server comes up. This means removing these vehicles from database by using this value becomes quite problematic since I have no idea when they were last used.
 
I did some troubleshooting and it seems it only happens with vehicles that are not fully repaired. If I repair them it keeps the timestamp and does not change at server restart. If not repairing the vehicles updated the column, a workaround could be creating an event that repairs everything every day, but alas it does (Maybe there's a way around this in SQL?). There's also a couple of vehicles that are not fully repaired that this does not happen to. It occurs both on ordinary spawned and locked vehicles. My buildings are indestructible so I am unaware if they would have the problem as well if they were damaged.
 
I created a new server with a unchanged dayz_server.pbo and Mission folder and created a new empty database. The problem still occurs. Attached is an excerpt from HivExt.log when the problem is occuring on the new server (17:29:48).
 
Is this a known issue or am I doing something wrong?
 
 
LastUpdated_Troubleshooting_HiveExt.txt