PC Alpha 20 Dev Diary
- Thread starter madmole
- Start date
- Status
Jost Amman
Well-known member
If you think it's a bug, then file a bug report and put screenshots of the "AI view" to prove your point. I think it's the best course of action.
faatal needs a bug report to act upon, then maybe he'll find out it's a bug with the "destroy mode" and fix it.
Vedui
Active member
In my experience playing Alpha 20, they all have in common that they act decidedly like Matrix Buggy Software Entities very often that need to be deleted
They have behaviour that clearly is not intended, and unrelated to being dumb or smart. For instance:
1) Charging the player, gets stuck on a tree (or a 1 wide block) and instead of moving aside, just beats on it. Even with the player moving to stand watching right next to it.
2) Rushing towards the player. Then running away from the player. Then running perpendicular to the player. Then again towards the player. This can repeat making for a super jerky and buggy path.
3) Running towards the player. Player moves a few blocks. Zombie arrives at player position and stops, then starts leisurely walking (having obviously lost track of the player in the span of 5 seconds, despite no obstructions, daylight, etc).
4) Player jumps. Zombies run off to beat on a random tree or pillar, as for a moment the player is now not in the exact spot it was, being 1 meter up in the air.
There seems to be something seriously wrong with the pathing, OR the zombie AI is hitting a lot of unintended decision tree branches struggling to adapt in a reasonable fashion. While we had some of this in Alpha 19, it's almost comical with how this makes zombies act decidedly non-zombie like.
A "dumb" zombie I can understand trying to break through rather than path a convoluted path. This is not what is happening
Jost Amman
Well-known member
Did you experience this in SP or MP?In my experience playing Alpha 20, they all have in common that they act decidedly like Matrix Buggy Software Entities very often that need to be deleted
They have behaviour that clearly is not intended, and unrelated to being dumb or smart. For instance:
1) Charging the player, gets stuck on a tree (or a 1 wide block) and instead of moving aside, just beats on it. Even with the player moving to stand watching right next to it.
2) Rushing towards the player. Then running away from the player. Then running perpendicular to the player. Then again towards the player. This can repeat making for a super jerky and buggy path.
3) Running towards the player. Player moves a few blocks. Zombie arrives at player position and stops, then starts leisurely walking (having obviously lost track of the player in the span of 5 seconds, despite no obstructions, daylight, etc).
4) Player jumps. Zombies run off to beat on a random tree or pillar, as for a moment the player is now not in the exact spot it was, being 1 meter up in the air.
There seems to be something seriously wrong with the pathing, OR the zombie AI is hitting a lot of unintended decision tree branches struggling to adapt in a reasonable fashion. While we had some of this in Alpha 19, it's almost comical with how this makes zombies act decidedly non-zombie like.
A "dumb" zombie I can understand trying to break through rather than path a convoluted path. This is not what is happening
I'm asking because I only play SP and I only experienced n.1 once in a long time.
I don't know why other people see these anomalies so often.
If it was an MP issue, it could be explained maybe with the pathing data is not being synced properly between host and client? Just a guess.
Kalex
Active member
Beelzebubs Ghost
New member
I've seen this also.
I stood beside a Mo (ground level) who had targeted a friend of mine, who was on the roof of a second floor motel (we built the second floor.)
I was literally stood about 7 blocks away from it while it looked at me and tried smashing a wall in to get to her.
I had to approach it and get into the same block space before it decided to target me (in spite of me being stood in an open space).
Strange...
I stood beside a Mo (ground level) who had targeted a friend of mine, who was on the roof of a second floor motel (we built the second floor.)
I was literally stood about 7 blocks away from it while it looked at me and tried smashing a wall in to get to her.
I had to approach it and get into the same block space before it decided to target me (in spite of me being stood in an open space).
Strange...
The Gronk
Colon Pounder
Rigidbody's also need a special consideration when teleporting although I have little doubt fataal knows this already.
The root cause of this is likely that the unity physics are updated during FixedUpdate() instead of the Update() function. This means that unless everything is moved during a single iteration of the Update() function then the physics engine is likely to have several iterations before everything is moved.
bladewalker27
New member
Any chance of an experimental release this week? Or is it too early to tell?
faatal
Fun Pimps Staff
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.
mr.devolver
New member
Every game needs its meme. Fallout 4 had Preston Garvey: "General, another settlement needs our help! I'll mark it on your map!", so traders of 7 Days to Die may just need that one extra farm cleared out of zombies, just one more farm cleared and you're good to go up that POI quality ladder...
The Gronk
Colon Pounder
FixedUpdate() is called and all physics are completed before the normal Update() function starts. If you're raycasting during Update() this is likely the cause of the problem, as far as I remember a teleported rigidbody isn't calculated properly until after the next FixedUpdate() cycle.
If you don't want to put all of your raycasts in FixedUpdate(), which would be very sensible to avoid if at all possible, the only kludge I can think of is setting up a trigger in update that runs your raycasts in the following iteration. That's an ugly kludge though and makes me feel dirty just typing it (not in a good way).
Good luck with that, not a bug I'd like to tackle
Perhaps shifting the movement of the origin to FixedUpdate() might cure it? Have the mechanism for detecting a required movement in Update() as usual but move everything at the start of the next FixedUpdate() iteration? That might work without being too expensive on system resources.
Last edited by a moderator:
faatal
Fun Pimps Staff
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.
mr.devolver
New member
faatal
Fun Pimps Staff
The Gronk
Colon Pounder
Yep, when the editor debugs break there ain't anything you can do.
It sounds like they've put the rigidbody's to sleep, that still wouldn't explain why the raycast would work from a different position though.
Maybe try and kludge it with Rigidbody.WakeUp() on important objects? Might be worth a shot.
Glad you got _some_ of the bugs fixed though
faatal
Fun Pimps Staff
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.Yep, when the editor debugs break there ain't anything you can do.
It sounds like they've put the rigidbody's to sleep, that still wouldn't explain why the raycast would work from a different position though.
Maybe try and kludge it with Rigidbody.WakeUp() on important objects? Might be worth a shot.
Glad you got _some_ of the bugs fixed though
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.
Jost Amman
Well-known member
Anyway, that's great new IMO!
Good job... if anything is still bugging out after this, we, the players may catch it after hours of gameplay (which you can't spare because you need to use your time otherwise).
bdubyah
Well-known member
So messed around with making a custom part, which was a new billboard piece. It seems that parts are added directly onto tiles, so the only way I could add my new part would be to include the whole tile with it. Is this correct? Would it be possible to make it so parts can have a list to choose from or something along those lines? From what I saw looking at a vanilla countrytown tile that had a billboard, you have to pick a specific one, and the only control over it is whether it spawns at all or not. Seems like a fairly simple way to add more variety if you allow all the billboard parts to be able to spawn there using a group or tag or something.
[SIZE=14.6px]@The Gronk, you wouldn't happen to be looking for a new job? I'm sure another dev in the team wouldn't hurt. 
[/SIZE]
[/SIZE]
Damocles
New member
When I implemented such an origin shifting, I used a "stress mode" where the origin shifted every couple of steps, and also randomly every couple of seconds, shifting it by a random amount. This was giving good quick feedback for bugs in the positioning, easily visible by objects getting stuck, falling or shaking, or traces missing the geometry.
- Status