1.0.6 RC1 Testing Bugs/Issues #1712
Comments
|
Snap building doesn't snap properly, at least on metal floors, they snap slightly below where they should have: |
|
So I converted/upgraded an existing database and there seems to be a problem with the order things are getting spawned in, or gravity or something. If you have helicopters sitting on metal floors they have a tendency to explode or fall through the metal floors (or the floors haven't been created yet). This is what happens right after a server restart and the first player logs in: This is what it would have looked like under normal conditions: |
|
@ndavalos try commenting out line 254 in server_monitor.sqf: |
|
@icomrade that sort of fixed it, this is the end result: The helis in the air are normally sitting on the floors, haven't moved them in months lol. I can provide you with a database if you want to play with it, well maybe not lol, all my objects still have coins in the inventory, I had to change the inventory function in server_monitor.sqf to handle that. |
|
Well that's interesting, they should load in exactly when the DB has them saved. The database would be helpful for this so if you can provide it that would be appreciated. I'm in the epoch discord if you want to send it to me there, or PM me on the epoch forums http://epochmod.com/forum/profile/11576-icomrade/ |
|
@ndavalos Alright, ifor you're planning on doing that base your new Dll on this repo: https://github.com/icomrade/DayZhiveEpoch if you want to merge in your changes I can add you as a collaborator so they get added to the pull request at the original repo which mine was forked from |
|
@icomrade lol unfortunately I don't do c, I probably should have learned it at some point, maybe on day...I work in Delphi (pascal) professionally, so that's what it'll be written in :) |
|
@icomrade so after experimenting with spawning in vehicles, this sort of solves the problem with things blowing up when spawned, and sets their proper location. It also spawns vehicles in faster: This was just experimenting though. createvehicle with position [0,0,0] is actually faster than specifying the position when creating it, then do a setdir/setpos after. Only problem is things spawned in on pitched terrain don't sit on the terrain lol. So if a vehicle is on a hill it will be level instead of having it actually resting on the terrain, I'm sure it has to do with the enablesimulation I put in. If I take that out, they sit on the ground properly. Using this method also had very little in the way of destroyed vehicles after spawning in. I think only 4 of them blew up. Also note, the m240 nets at the base in the cave all appeared where they're supposed to be placed after using this method. It still caused a couple helis to explode that were on metal floors, but something to look at if you're going to look at that issue. It was merlins that blew up @003131 in the database I provided you. |
|
SetVelocity is used to sit the vehicle on the ground properly, it initializes physics after spawn in. That's why after you commented that line out some vehicles were floating in the air. I'm more concerned as to why you have some vehicles spawning in 10 feet above the platform they were landed on. There may be some inconsistencies between saving and spawning vehicles. |
|
@icomrade I'm not sure if they're spawning in with CAN_COLLIDE, or not, didn't bother logging that. If they are, then yeah they should go exactly where you put them, if not then the engine will adjust things. Edit: as a side note, I did setpos myself where one of the merlins was in the db and it was exact. I'll have to do that with one of the floaters. |
|
@icomrade so I wrote my own function in a dll to load up the list of objects to spawn. Takes 1-2 seconds for it to load the array, but I'm not sure if you would even want to do this since it is very unconventional. The contents of the file look something like this: It's very unconventional, but it prevents repeated calls to a dll, and is extremely fast. Something to think about I guess. It also overcomes the 4096 byte boundary for returning data. I looked at the code in hive and it appears to be doing some stuff that you could actually just schedule an event on the database to handle every night or whatever. The fixing uids I actually have an event scheduled to do that: Not sure what to tell you about the increase of time though, populateObjects should do as little as possible. You may consider moving most of the code in there that doesn't involve returning objects to a separate function. When arma loads an extension, that extension stays in memory, so anything that is in memory for the dll will remain. For instance, if you open a query object, that object retains it data and state until the arma server process actually exits. At no point does arma unload the dll. The method I worked out was:
I think part of the problem is you're opening and executing queries for every single record in object_data from server_monitor. That's a lot of overhead, especially when you are hitting mysql 7k times. I would suggest the first call to hive where it gets the object count should execute all that extra code you have in populateObjects, then populateObjects simply returns objects and whatever REALLY needs to be done while doing that. You'll have to evaluate what is absolutely essential for populateObjects to do. |
|
The hiveExt already loads everything in one query and iterates through the elements to ensure the data is valid and builds an array of objects to send to the server to spawn in SQF. I think the ObjID Fix is best executed sever restart, but in reality I suppose it doesn't really need to be, but I don't know if the overhead of this is noticeable. On another note using code blocks is helpful, surround your code with 3 back ticks: ``` All of the objects/strings/pointers etc. should be destroyed and removed from memory once the initial load of the object_data table is done. I'm not sure why it wouldn't be cleaned up by the compiler since once populateObjects finishes everything referenced is no longer in scope and similarly so with streamObjects. I may be missing something, plus I'm not all that experienced with C++ so I probably wouldn't be able to identify the problem. Also I think the biggest issue with increased load time is the modified servermonitor file, I noticed whether the DB was new, empty or populated the minimum load time is ~30 seconds. We definitely need to look into performance optimization. |
|
@icomrade Which, I don't do c++, but from reading the code it appears to open a query each call: But again, I don't do c++ so I could be misinterpreting that in populateObjects as executing the query each call, or misinterpreting what server_monitor is doing in relation to calling the dll. The rest of server_monitor is taking too long as well. The script is getting suspended during execution causing it to take around 80 seconds to spawn in 7k. There's some stuff that could probably be done to fix it completely. @eraser1 mentioned maybe moving to an fsm to spawn things in unscheduled and control the entire process better. |
|
@icomrade also, change the query to load the objects to only get those with damage < 1 to reduce the object count instead of having to evaluate it in sqf. |
|
That SQL query is only executed once, I think the subsequent calls of child 302 return a single object. once the initial load of the object_data table _srvObjects is no longer empty so it should go to the else condition. https://github.com/icomrade/DayZhiveEpoch/blob/master/Hive/Source/HiveLib/HiveExtApp.cpp#L300-L343 I have a server_monitor.sqf that I was testing that uses spawn and tries to create vehicles in multiple threads in parallel. I still have to tweak it, but on average it saves ~10 seconds with 4000 objects in the DB. Edit: I do agree there is a lot of overhead with this method but I believe there is a limit with the amount of data callExtension can return as mentioned here: #1197 So I don't know if this is going to be an issue with returning everything in one array. |
SQF threads never really run "parallel", only a single statement of SQF is ever executed in any given instant. It appears to be saving time either because of lots of other SQF "threads" that have been spawned from other scripts, thereby artificially increasing the priority of object spawning, simply by the presence of more threads, or you simply measured the time of completion of the server_monitor code, which doesn't measure the actual time taken to spawn the objects. |
|
I just managed to spawn in 7k+ objects in 30 seconds and set all the properties on them after the fact in 20 with the method I developed last night. I changed my methodology to create an sqf to load up the object array with actual objects and create them. After the engine runs it, it signals the clients that login is ok and spawns a thread to update all the properties on the objects like damage, hitpoints, inventory etc. |
|
@icomrade some suggestions for optimizing:
As @eraser1 suggested, using an fsm to create the objects probably will significantly lower the cost of spawning everything in. My new method (not the fsm) takes anywhere from 40-60 seconds to spawn everything and add inventory as opposed to 2 minutes. |
|
Between a well written server_monitor.sqf and a well written FSM version I doubt there will be a meaningful difference. Rewriting the whole server startup process as an fsm may be more beneficial but since server_monitor.sqf is relatively simple in its condition checking there may not be a huge benefit. Even just moving simple things to the HiveEXT like typename checks will probably offer more performance benefit than moving to an fsm. |
|
That is actually my point. Running the entire server startup sequence unscheduled could make a very significant difference. Also, not just the server startup sequence, but I also found that running the player login system helped with player login times significantly under load. |
|
I did some profiling of the various functions of server_monitor and the engine was pausing the script anywhere from 20ms to 100ms randomly while setting up objects. Some objects would create and update in 1ms, some 20ms and some 100ms. So running scheduled is going to have some issues, especially when you have around 6 or 7k objects. |
|
A couple of observations on the server_monitor performance. changing server_monitor to call compile instead of execVM decreases the total callExetension time for the HiveEXT by 5x (3s vs 15s for 4100 items). I believe the max number of loop iterations in a called environment is 10,000 so it's probably not an appropriate change. I've moved some stuff and changed some stuff and was able to shave some time off load in, but it's still far from where it should be. with 4100 objects the |
|
@icomrade few suggestions:
OR use an fsm :P Figure out what is critical for clients to log in and do that first, do the rest after you let clients log in. If you log the tick time for every part of object creation, you'll see the main reason everything takes so long is because the engine is suspending the thread anywhere from 20-100ms while server_monitor is doing it's thing. This is killer when you have a large number of objects. The reason each iteration through the object array is taking 200 seconds is the engine suspending the thread. Pretty much every millisecond counts to getting the server ready for clients. |
This only applies to while loops, not "forEach" or "for" loops. |
|
@icomrade got 7k objects read in and spawned in 17 seconds using my method. |
|
@ndavalos is there anything you've done that is different than the current server_monitor. If you've changed something reply with a link that points to the line number and file |
|
Tested now with M240. After 5 mags in the left side the SUV did not blow up. A HMMWV blows up after 3 mags. So basically you have to hit the SUV directly on the front engine. Am I totally wrong here or is a bit too much? Perhaps Im just too familiar with the old epoch vehicles and it seems only for me too much. |
|
Armor of the SUV is 25 unless you are using an upgraded SUV (armor upgrade gives 60 armor), the HMMV is 40. if the SUV doesn't get damaged from the side I don't think it's something that can be fixed from the configs, the model itself would need to have the engine hit points modified. |
See: #1712 (comment) That should be all of them @ndavalos let me know if I missed any.
|
@icomrade this file: #include "scheduler.hpp"
sched_spawnCheck_init = { []spawn{} };
sched_spawnCheck = {
HIDE_FSM_VARS
if (scriptDone _this) then {
_this = [] execVM '\z\addons\dayz_code\compile\player_spawnCheck.sqf'; // stuffed with "sleep" commands, can't put it in scheduler
};
_this;
};but that is defined as a variable in compiles: player_spawnCheck = compile preprocessFileLineNumbers "\z\addons\dayz_code\compile\player_spawnCheck.sqf"; Is there any way of making that use what's defined in compiles instead? I need to override this function, but by doing it this way, I can't without overriding a bunch of other stuff as it currently stands just to get to this one function. |
|
you'll need to edit sched_init.sqf or create a folder of the structure exactly replicating the path of _base (in sched_init.sqf) and place your custom sched_spawnCheck.sqf in it. so it would be [Mission root]\z\addons\dayz_code\system\scheduler\sched_spawnCheck.sqf. you will also need to overwrite player_spawnCheck |
|
@icomrade I was hoping it could just be changed to sched_spawnCheck_init = { []spawn{} };
sched_spawnCheck = {
HIDE_FSM_VARS
if (scriptDone _this) then {
_this = [] spawn player_spawnCheck '; // stuffed with "sleep" commands, can't put it in scheduler
};
_this;
};Since player_spawnCheck is defined in compiles already, makes it much simpler to override the function without having to replicate the scheduler. I'm basically adding 1 line to that file to do an extra check for plot poles and safezones to prevent loot and zombies from spawning within plot pole radius (or safezone radius). If it's not a good idea due to spawn adding a new scheduled environment then that's ok and I'll just replicate the scheduler, unless of course you feel like adding one thing to spawncheck to check to see if a variable is defined and executing the code in the variable for additional checks people can add without having to override the code. Something like: if !(isNil "DZE_ExtraSpawnCheck") then {
_doNothing = _position call check_spawning_distance;
};
if (_doNothing) exitwith {}; |
|
@ebaydayz Well, execvm adds a thread to the main scheduled environment, spawn creates a new thread and scheduled environment (that runs alongside the main scheduled environment). That's really the difference between the two (aside from calling convention and error reporting). I don't really see a problem with that one being spawned, hell it might even improve it's performance instead of stacking it in the main scheduled environment. Either way I can deal with it, just tossing out some suggestions since it's already compiled in compiles as a variable, but that variable isn't being referenced anywhere in the mod. The other alternative would be good too, or some variation thereof. I wouldn't mind having that one little thing in there (however it's implemented) to allow for additional checks on whether or not to run the spawning code. That way I'm not overriding an entire file to add 1 line of code :) |
|
You don't have to replicate the scheduler, I don't think I let on that you have to recreate the folder structure. Same concept behind the BIS Init error fix I added to the missions, since the path in https://github.com/EpochModTeam/DayZ-Epoch/blob/master/SQF/dayz_code/system/scheduler/sched_init.sqf doesn't have a preceeding \ it can be overwritten by a file in the mission. Also look at the referenced file to see why just overwriting only the compile won't work. |
|
@icomrade Ah, I see the missing "" at the beginning of the base path. I would however prefer not to override any code if at all possible. It's just a pain to deal with, so I try and avoid it, especially for a 1 line change. @ebaydayz I believe I was basing my assumption about scheduled environment based on the comments on spawn in the wiki. |
|
Honestly it's not a big deal, adding a replication of the file vs overwriting the compile is a difference of 2 lines of code in this case. |
|
@icomrade actually what I was referring to is second option of adding something to player spawn check instead of having to override anything. That way if there's a base change in the mod, there's no need to try and keep things in sync So in player_spawncheck.sqf something like: if !(isNil "DZE_ExtraSpawnCheck") then {
_doNothing = [_position, _spawnableObjects, _speed, _radius, _spawnZedRadius, _maxlocalspawned, _maxControlledZombies, _maxWeaponHolders, _currentWeaponHolders, _inVehicle] call DZE_ExtraSpawnCheck; //return result is assigned to _doNothing
};
if (_doNothing) exitwith {}; |
|
I modified the Hive to write to a file and have the server read form it, eliminating the need for callExtension nested in a loop. The file is named uniquely per startup based on the init key and is placed in the A2 root directory. Unfortunately I cannot truncate or delete the file until the next restart since OA locks the file once it is read by the engine. I'm concerned that this is a security issue as there's essentially a plain text DB dump of the objectData table sitting in the OA directory. I'm curious if anyone knows of a way to unlock the file once it's loaded by OA, or even write to the file using in sqf. #include, preprocessfile, loadfile all lock the file, htmlLoad won't work since the dedicated has no display, if there's a non-locking way to read a file I'd love to know of it. On a performance note this only saves 2-3 seconds with 7000 objects, but it will fix #1197 if this was the issue (I feel it's unlikely). |
|
Nah there's really no way to unlock the file. I'm leaving them with the same name and deleting them in the dll before writing a new one on restart. Most people run their db on the same machine, so there's really no difference, they'd have the credentials for the db anyways since you don't encrypt them in the hive.ini file. I use a specific folder for the file, not the root, you can load from a specific directory just using "\mydir\myfile.sqf" . I'm getting a consistent 20-30 second startup with my server_monitor and dll, hive gives me about 75 seconds + so I think your problem is elsewhere not the iterations if hive only takes a few seconds normally now. |
|
I didn't expect a huge performance increase since the loop only took a couple seconds to complete anyway. I'm curious as to why there's such disparity in the load times experienced with the 2 versions of the server_monitor file. Looking at the server_monitor you sent me a while ago, you removed all the worldspace crap which I've been looking to do for a while and you've also removed that config lookup which is intensive, also a lot is missing so I assume the rest is handled elsewhere. I don't think moving the networked commands (setvariable) to a spawn is making a difference since I completely commented them out with no meaningful difference. Also, did I assume you tested with the server_monitor I committed yesterday, it should be quite a bit better than previous versions. |
|
When the Hrotor from a heli is to 100% damaged the chopper can still fly. This is an old epoch bug perhaps an arma bug? Can we fix that? |
|
@icomrade just tested the new server_monitor etc. Loads you in within a minute with 7.5k objects. I got a retrying authentication though at some point, not sure what that was about. Otherwise it's loading fairly well. |
|
I remember two old epoch or arma2 bugs. Im not sure from which it comes. When someone eject from a flying little bird, the little bird gets heavyle or fully damaged. Switching between the gunners in a flying chopper can result in ejecting from the chopper without a parachut. E.g. When you are on the left gun from a UH1H and you switch to the right gun there is a chance that you just fall out of the chopper without a parachut. Tested with UH1H and Mi17. |
|
Those are both issues we won't be able to fix unfortunately and they are outside of the scope of the project. While fixing A2 OA bugs that exist in the base game is great, it's no always possible. |
|
Just a question, is there any way to prevent beta clients from joining? People have been using the beta client to gain an advantage over others with stuff like DMR zeroing and increased accuracy range and a few other weapons that don't work like they do in the normal arma client. The beta also causes a lot of problems with AI etc. Some of the people I've had testing have noticed strange behavior out of zombies when using the beta. I've told them to use the normal client and things start working properly again. |
|
I got the Mozzies fixed up, ended up figuring out a way to overwrite the base vehicles without needing a _DZ class, I'll probably do the same thing with the pook guns so we can get rearming added. I'm not going to touch mozzie health, I feel it's a slow and very vulnerable vehicle that will probably have the pilot shot out before blowing up from damage, so changing the health is probably irrelevant. |
|
Took me a second to understand why briefcases were disappearing, might be interesting changing the "precious stones" descriptions to their actual value since their description is useless. |
|
Strings for objects are set in the configs, not quite sure we can alter the text to display the value since it's dynamic. |
Post all issues pertaining to the first release candidate of the Epoch 1.0.6 update here.
Known issues from the previous topic:
Bunny hop with no weapon triggers an invisible weapon switch (bug in vanilla)Some ammo types have no right click re-combine optionDO NOT run test buils with infistar or other mods that are not updated to work with 1.0.6. You MUST use the new HiveExt.DLL if you are running a server, the new dll requires visual c++ redistributable 2015.
The text was updated successfully, but these errors were encountered: