Jump to content

faatal

Fun Pimps Staff
  • Posts

    2,592
  • Joined

  • Last visited

  • Days Won

    93

faatal last won the day on January 18

faatal had the most liked content!

Personal Information

  • Location
    Indiana, USA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

faatal's Achievements

Leader

Leader (12/15)

3k

Reputation

  1. Allan committed a fix for it and similar blocks today. He changed the colliders and xml tags, so path raycasts can now see the colliders. It was a general fix for things falling through the world, which also effects vehicles. One of our testers retested vehicles and it is better, but he still found cases of them moving, so more testing when I get back to it.
  2. The problem was that falling AI that had a path to the player were not trying to enter destroy area due to a bug. They would only enter destroy area on a long path, which is a fairly low percent. Now that the code is fixed, you are seeing the full extent of it working as intended. Falling zombies also don't just enter destroy area, but can trigger others into destroy area. Dedi is no different than SP, since AI only runs on the server, but with the increased zeds multiple players will get, it means increased chances the of them triggering each other. This just sounds like the percents need to come down and maybe cap the sharing.
  3. Yep, that is what I did, time based shifting that I typically ran at .2 seconds. Stress testing is important and programmers often don't abuse their systems enough. The rays are not hitting the ground. The ground does not have a rigid body. It is just a mesh collider.
  4. Rigid bodies are not the problem. They collide using their collider just fine. When ray/sphere casts to the ground fail in large sections of the world, then objects relying on them for physics fall through or in the case of vehicles, think they are falling through and move back. The code I did is visibly fixing it 100% in the case of the player and zombies, but I just don't know about vehicles and turrets yet, because I have not seen one move in days, which does not prove it is fixed, just that it might be fixed.
  5. Nope, as far as I can tell this is a Unity bug with the internal physics collision data. Origin shifting moves all the transforms at one time, there are no delays. It works most of the time, but when it fails, all physics casts in parts or all of world fail repeatedly frame after frame until something changes that causes the physics collision state to update. Even the editor Physic Debug mode won't highlight the collider when you mouse over it. Strangely, rigid bodies, their colliders and world colliders still collide fine, which is why a vehicle would not fall through the world, but the raycast to check if a vehicle fell into or off the world would fail and try to fix it. It appears I now have it fixed by detecting failed raycasts and shifting again and checking again. I did move the shift to FixedUpdate, but that alone did not fix it.
  6. No, but we move the CC around in many cases and it is not an issue and it would not help AI or vehicles, since they don't use Unity's CC. Raycasts also break.
  7. There was a reason the origin was changed to shift more often. Weapons shaking in hands. If we could do it less often, we would. Even if shifted much less, it still causes the physics bug, so still needs to be fixed.
  8. What I posted before is about that issue: "All or most of the issues with players/zombies/turrets/vehicles falling through ground appear to be caused by the world origin shift. It happens about 4 times more often in a20, so these bugs are more apparent. It seems to be a random Unity physics update problem after the origin changes, causing physics casts to fail. I've tried a ton of stuff and added a rapid origin shifting mode to repro it quickly. I now have the Origin code doing extra physics updating that reduces the problem to one frame and a raycast which detects when it happens, so I can try even more adjustments to fix it. " This is not an easy bug to fix as it is an internal Unity engine issue with their physics values not updating after we shift the world origin. After a week of experiments trying to repro it and come up with fixes, it seems better, but it still is not 100% fixed, so come Monday I'll be trying more things. We have to shift the origin or you get jittering animations as you move away from the world zero point.
  9. There should be no changes to that. They should just be firing away with whatever part they target and random hit variation each weapon has and possibly hitting the demo charge.
  10. Stability fix is done. The second issue we found was actually just a display issue with the show stability view, which is now fixed. All or most of the issues with players/zombies/turrets/vehicles falling through ground appear to be caused by the world origin shift. It happens about 4 times more often in a20, so these bugs are more apparent. It seems to be a random Unity physics update problem after the origin changes, causing physics casts to fail. I've tried a ton of stuff and added a rapid origin shifting mode to repro it quickly. I now have the Origin code doing extra physics updating that reduces the problem to one frame and a raycast which detects when it happens, so I can try even more adjustments to fix it. I've not started on it yet. There are bugs that need fixing first for a20.1 and we are still sorting out what is going into a21 and who is doing what as we have added several new programmers to the team.
  11. The main issue is fixed, but testers found some secondary recalc issues, so I'm going to look at it again. There will be an experimental, but not until a collection of issues are fixed. It will be announced in the forums when released.
  12. It was not a large amount of work. I was the only one who worked on it and I probably just spent a few days on it. I work on a lot of different stuff, so it gets hazy over the years. Digging is also not just for horde nights. It is useful to the AI in POIs when you get below them and down would be the best path. We don't spawn hordes so they can do nothing. The intent is for them to reasonably try to get to you and you to reasonably try to defend against it. If you don't want to interact with hordes, then turn them off, which is why the setting is there. One of our devs was even playing a game with them off recently, since he was trying something different. Shooting a crossbow is quiet, not silent. Feral sense makes it 2.5x as loud to zombies (dog and zed bear are slightly different multipliers), so your quiet is not that quiet. It was OP, so you should have to put points in stealth and use appropriate gear to be effective. It is. Things falling through world and stability issues (half fixed) are my top two bugs.
  13. Sure, it was not a good test of a low end system, because it is not a low end system, but that is all I had the time to test. We know tree high detail LOD complexity is an issue with gfx and shadow fill rate, but artists don't want ugly trees. We have a very capable programmer looking at trees and we shall see what he finds. Yes, I've noticed that player trees could use more space between them. I have no interest in spending time making old school circle shadows. Would rather people just turn shadows off on low end systems. There is no clear cut indoor vs outdoor. Occlusion outdoors often hides objects behind buildings, which applies more so in cities, so I'm not spending time trying to guess which is better. Low end CPUs could have it default to off, but that needs research, which I am not spending time on that now. Zombies have varying degrees of dumbness in their pathing based on a settings in xml which also covers a random range. They tend to abort long paths, put less value in block health differences and can't open doors. Bandits will try long paths, fully consider block health and open doors. They will also spawn in smaller numbers.
  14. Not in my testing. If I was in stealth and quiet enough, nearby zombies did not wake. Distance from zed being a big factor.
×
×
  • Create New...