Thanks for your great work :)
Just a hint:
If you want to make your mission bullet proof, against the latest "BIS_fnc_MP - hack":
Insert this line
"BIS_fnc_MP_packet" addPublicVariableEventHandler {};
in the init.sqf at first line.
I tested it with your mission and it works great...
I wish everybody a happy new year!
In 2013, i will no longer spend as much of my time in dayz improvements/development.
I hope my work helped some of you to enjoy this game a bit more.
All improvements currently presented here (and some more :) will be part of 1.7.5.
I am curious, what...
You are right, lowering the update frequence is a bad idea, i forgot all the player tracking tools depending on frequently DB updates too.
My logs show me player_sync events at least each 12 sec per player, and each player_sync event is triggering a db update. You wrote you have state updates...
I am not involved in the development of hiveext.dll.
But i know the hiveext.dll update mechanism and can confirm your observations.
I think, it is possible that the FIFO queue inside this .dll can be very long (querys have higher priority), if we have slow I/O and very many updates (full...
... there are many ways and which is the best for you depends of your setup ...
Generally i would say, if you don't have a dedicated DB server and additional a very slow I/O (HDD),
you could use some of your left RAM for DB speedup.
Some InnoDB settings allow you to adapt buffer size and other...
... hmm ..., broken legs with the "conservative" publicEH.sqf? That is a bit surprising for me.
There was a early "experimental" version, where i got some reports of healed broken legs, which appear broken again, with immediate logout/login (db update to late or incomplete).
The "improved"...
1/ no, a faster login is already in 1.7.4.4, the "instant login" will be in 1.7.5 when finished, or here now (readme.md is up to date)
2/ yes, yes, "brocken legs" was a earlier problem with the first publicEH.sqf and is solved with the current version
I found that it is possible to redefine config classes.
So if we, for example, just would change the "Locality Event" message, we just have to do the following:
In our cfgVehicles.hpp (dayz_code) we insert the following redefing code as first define in class "CfgVehicles":
class...
... anti hack stuff is not really my terrain, i don't have a public server, so hacking is not really my problem ...
But this start to interesting me, since TheLaughingMan told me, that my MPFramework-hook,
which i just implemented to speed up the login, blocks the "remote execution" hack.
I...
... hmm..., i think you are not wrong here, it could be hard for the scheduler to get a load of 200 additional fsm's in a short period, if this occurs.
And you could be right too assuming, that the fsm will not be immediate terminating if the scheduler is heavy loaded (up to some seconds).
So...
.. ok, i checked this "local event",
Results:
1. it only occurs if player disconnects/died
2. the .fsm terminates immediate
3. we can't eliminate this (diag_log message), because the related file is not in community hand
... thanks much for your report, there must something in the experimental EH a bit to risky ...
I moved the "usecMorphine" EH back the server and client section in publicEH.sqf.
If you like, you can try with the experimental again.
Edit: It seems it is triggered for killing zombies too (in my log files it is very frequently with one player).
I think you are right, the execution of this FSM here looks like heavy wasting of resourses.
We should really investigate this !!!
... hey, very good catch ...
My notepad++ didn't find it, because of binarization.
You should contact R4ZoR49, he is currently reworking the zombie stuff.
... currently, i havn't ...
I am reworking (speed up) currently the loot spawn system and to make my life easier when testing my code,
i disabled the zombies totally ;)
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.