CServer::GetClient() will never return NULL as it returns address of client in array. Removed extraneous checks as its misleading, and added const where possible.
The rebuild was wrong, the reported issue was that during auto-aim, the rotation speed is higher than original with a weaker magnet. Since the dissasembly and decompile of this function wasn't correct, along with not being able to reproduce the issue locally, it was hard to debug the problem (the difference between the rebuild and the original implementation was very small, where only experienced players noticed it). Since I have concluded that we don't need this function rebuilt as nothing else in the function needed adjustments, we can therefore just hook it and add the multiplication scalars on the computed joy angles. This now seems to yield correct behavior based on new tests that were performed with these changes.
The loader no longer loads from WinMain as this caused problems during shutdown. It was switched back to LauncherMain with several adjustments to make it work perfectly for both initialization and shutdown.
Optimization by only calulcating it when its used to avoid calculating it for nothing when we end up moving to the next edge. This is only used when the link is established.
The rebuild should be correct, but to rule out any problems we might have after releasing this build, we should have a simple option to force the old implementation.
The game can now be ran fully offline by providing '-offline' to the command line arguments. The engine will auto execute 'system/autoexec_offline.cfg' which overrides other autoexecs to ensure the game runs offline. The system/autoexec_offline.cfg file only overrides the variables it sets.
CustomPakData_t::numHandles was never decremented on unload, causing pakId == PAK_INVALID_HANDLE to be true and triggering the assert. Due to this, we either never unload resources properly on subsequent unloads and loads, or we would run out of pak slots as numHandles will reach MAX_CUSTOM_PAKS. Also added a comment explaining why this loop isn't ran in reverse.
The prune code will prune everything marked unlinked, but unlinked means that that polygon doesn't link to another, it doesn't mean its useless. Therefore, if we have an island that is unlinked, but still want to keep it, we should be to. The polygon should only be considered dead when its unlinked and disabled, which only happens through the prune tool. This allows for pruning and cleaning single polygon navmeshes.
dtHint::triangle should be triangles as it can contain more than one triangle, renamed it to 'tris' to keep consistency with the rest of the code base. Also fixed its comment explaining what its size is.
Add more comments to describe what they do, Hull_s::scale is now confirmed to be extentScale as the game uses this to query points on the NavMesh, its also being used to build navmeshes based on the tile headers in Titanfall 2 navmeshes and their hull constants.
There was a bug where some rays went through triangles, albeit rare. The issue was that overlapping chunk indices were truncated if the number exceedes the maximum of the stack buffer. The intersection code was originally also written to ignore back faces, but we need back faces, the intersection code has been rewritten with a known robust algorithm and the index buffer has been increased and made static. The rays no longer go through triangles.
These new values give better results after commit 247a99765ce669434513558e44bba632a55135d1 and b41141018e9be3c28cdbc74d1fc7e3b8ec876c6d. The new cell heights can be used after we fixed the culling of neighbor spans. For the larger tile size: since we can only reliably link to neighbor tiles we need to increase the tile size to ensure full traverse link coverage. Respawn by default uses 512x512 tiles, however, given that a link can be as large as 2550.0 in world units, a tile size of 1024x1024 in the x-y plane should give more than enough room to connect links to their fullest extends to neighboring tiles when we also take the Z into consideration. This change greatly benefits traverse types that perform "ACCROSS" activities, e.g. flat traverse links.
This causes many problems in titanfall and apex maps due to the large voxel sizes we have to use to generate navmeshes. A single unwalkable voxel makes a large difference. disabling these feature results in much better results. The problems this test filters away can be fixed with setting proper cell heights in our case.
Fixes https://github.com/recastnavigation/recastnavigation/issues/317. This can happen when we mave multiple spans in the X row. So far this crash only occured in Capitol City in Apex Legend's Worlds Edge map, where there are internal polygons in high rise buildings with 10 or more floors equally placed on top of another.
Increase to 29 bits for span limits, previously this was 13 and since the next field in the struct was a pointer, we end up using the 4 bytes padding so the struct size didn't increase. The reason for this increase is that rcSpan::smin and rcSpan::smax overflow when building a navmesh with a low cell height. This is especially an issue with maps that contain mountains. For the season 1 kings canyon map, the tiles containg the polygons for the firing range will be entirely flat due to the massive height difference between the base map and the firing range which resides under the map, causing it to be clamped to the previous MAX_HEIGHT value.
Slightly more fine tuned for better results, especially between type 10 and 21, make AI climb on lower ledges and perform higher jumps on higher ledges. Also ensured full coverage for all "accross" traverse activities by closing all min/max distance gaps.
During new tests, not starting from the neighboring tile at north caused some smaller links to not establish, which is roughly 30 links in angel_city.bsp. This patch makes it always start from north without any alternation and yields the best results during all tests.
rdClassifyDirection never got intercardinal sides causing it to be unreliable and inaccurate. rdClassifyPointInsideBounds and rdClassifyPointOutsideBounds are tested and confirmed correct during every case, switched use to rdClassifyPointInsideBounds instead and removed rdClassifyDirection for the start side of the neighbor tile lookup. For the links: the base side is always the opposite of the land side.
Big optimization as you cannot link to the same polygon, you also cannot link to the same triangle. This drops polyCount number of iterations on polygons per tile.
The library used signed 32bit integers and single precission floating points to represent build times, but on long build times this will overflow. Added a dedicated time type while promoting it to double precission and adjusting all use cases throughout the library.
Go over each neighboring tile starting with the tile facing the edge normal, and then its oposite, and perform the same alternation on the next tiles. This link pattern gives the best and most consistent results by trying to link all sides equally. In order to guarantee maximum coverage, the link count multiplication has been increased from 8 to 32 per detail mesh bound as this new approach is creating an incredible amount of new links. Some of the links will end up not being used, but these will be removed during the prune stage.
- Portal kink point is now always offset twice the walkable radius to account ledge spans and center of hull to ledge, any extra is put on top with the default being 4.f to account for irregularities.
- Make sure we have enough clearance over the kink point and lower start point of the portal so that the NPC does not clip into overhead obstacles when performing an animation.
- Make sure we don't link a portal from underneath geometry by performing a raycast from the edge's mid point, and 2 additional ones if the link's span is larger than 100.f in world units.
This allows for getting the direct side of a side by doing side-1, side+1, etc.. A useful case would be to get tiles at sides facing the normal of an edge on our own tile and doing anything with these tiles.
If there's no movement on the x-y plane between sp and sq, there will be no magnitude, and thus also no discriminant. The code however will continue as it only checks if discriminant < 0. Due to this, the code will no longer take the origin and radius of the cylinder into account and that will cause any ray that extends above or below the cylinder to be a hit, regardless of where it was emitted from in the world. If we have no magnitude, we should always check if the start point resides inside the cylinder area on the x-y plane and determine from there whether to perform a vertical intersection test.
