You can stop loot spawning without having all the files needed for custom loot. I'm curious as to why you would want a server to not spawn any loot though.
For some reason Overwatch stuck with the 1.8 server_monitor code format, even though DayZ itself changed back in version 1.8.0.2. No idea why Overwatch kept it as it's a pain for script additions, you'll need to check the BB additions as they natively use _object which is no longer a defined...
Ok, in server_publishObject it calls a function from server_functions to do that check. Not sure where the REMOTE comes from as it's not listed in the diag_logs in that file. But yeah, it will pass that check anyway because it's in the allBuildables_class which you've added to the allowed...
I believe that check makes sure the item is in the deployable table of the DB (if you use Reality, if not then it may be named something else like Object_classes).
I'm not sure why it would have that issue, as I've never used Kikyou's improvements myself.
You wouldn't want to move them server side, but you can move them to the mission file (if you make the relevant edits to associated files such as compiles.sqf) and edit them in there yes. The changes above though don't harm anything so you don't need to edit anything other than the variable they...
Ah yeah, easy mistake, I got overzealous with my tabbing for the second if statement haha.
Switch the definers to 0 instead of array possibly.
So like this
_fuel = 0;
_code = 0;
Yeah deleting the foreign key check was always an option, I prefer not to delete the checks though because they help secure it against hackers using the DB to store all manner of things. Plus, this is all going to become redundant very soon.
What version of DayZ are you running again? I don't...
It did, but it only works with the official hive or the epoch hive as far as I'm aware. That's what the changes you carried out with replacing playerUID with characterID, playerUID remains constant but only some database schemas allow it to be used on deployables.
You can set that script up as...
That's normal behaviour, since characterID changes every time you die and get a new character.
Check my post here for a 'sort of' workaround. It's by no means a perfect solution, but it's only going to be temporary at this stage anyway.
No problem. I know from fixing this for somebody else, who was running Overwatch, that replacing those variables and editing the database is all that's required. Provided you did everything else all right haha.
Kikyou's improvements were designed to work with the Epoch hive, other DB schemas use variations on formatting and table layout.
I know that with Reality, there is what they call a foreign key check on the instance_deployable table. This check makes sure when writing the table that the...
For now, open player_remove and after
disableserialization;
Add
player removeAction s_player_deleteBuild;
s_player_deleteBuild = -1;
player removeAction s_player_deleteCamoNet;
s_player_deleteCamoNet = -1;
Should remove the action from their screen. Since the fn_selfActions is already set not to...
Thanks to Killzone_Kid I got an answer to this problem. I can use
missionNameSpace setVariable [format["%1",customDebug], true];
to set the variable that string is a place holder for.
If you already have a full compiles.sqf in your mission file, you don't need to add another for fn_selfActions. Just change the path in the existing one. Though if you do add another compiles.sqf it can have the same name provided it's not in the same folder.
Ok, so I'm working on something that uses a lot of hint displays. The problem is that a lot of people use custom debug monitors these days so I want to be able to hide the custom monitor when showing my hints and restore it after my hints.
That part is very easy to do and I've got it working...
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.