The Gronk
-
Posts
2,435 -
Joined
-
Last visited
-
Days Won
17
Content Type
Profiles
Forums
Store
Articles
A20 Bugs
A21 Bugs
Events
Posts posted by The Gronk
-
-
35 minutes ago, Matt115 said:
Yep this hard to do good.
I'm playing now in DL2 and a lot of zombies you can easy kill using just sittng on elevetor
This _isn't_ hard to do well it's hard to make the AI do badly enough that it seems your expertise with a firearm and superior tactics are the deciding factor, they're not, that's my point.
You found an exploit, well done, people have just as many exploitable behaviours. If you gave the zombies a gun each with unfettered aiming I'm sure your lovely little hidey-hole would be of little use as a well aimed barrage of shots hit your head every time you popped up for a shot. You have a distinct advantage with a gun and you've already decided your best chance of survival is to run away and hit them from where they cannot hit you back.
2 -
23 hours ago, Grandpa Minion said:
i would say you got that backwards... Bandits are nothing like real life PvP players. A bandit will never have the ability to challenge the offense and defense that it takes to raid and defend a base. Competition in players is something a bandit would never supply. Thinking about the strategy how to attack a base and thinking about the strategy how to defend it is a factor bandits would never have. Basically a bandit would just be another zombie to kill on pvp servers.
I'll let you into a secret. Every AI you have played against has had its abilities crippled to make you feel better. Players have an easier time losing to another player than an unfettered AI. Some of the main advantages are listed below, allowing the AI to fully use any of these will instantly lead to screams of "unfair" and "implayable" by the players.
Perfect aim : An AI can work out exactly where to aim with a simple matrix rotation, in unity that even has a little helper-function. Depending on the system the programmer may have to randomize the aiming point a little before the shot to give the player a chance.
Perfect radar : The AI does not perceive the game world as you do, it knows where everything is and its weaknesses. If you think wall-hacks are cheating please be aware that to the AI the walls simply don't exist.
Perfect pathfinding : It takes time for a player to memorize the routes on a map, for the AI all routes are known and the default is to choose the shortest route regardless of how obvious it is or whether it can even be seen from where they are.
There are more but these should give an example of why we cripple AI for the players, programmers are only human and we like to win every now and again as well.
4 -
2 hours ago, Strykhar said:
@faatal Any slim chance we might see some conversion of the code to ECS or DOTS with Unity for zombie entities so that processing of those things can be done more efficiently opening up the possibility for massive piles of zombies?
ECS is nowhere near production ready and is unlikely to be for around 18 months.
The current codebase will be entirely replaced sometime this year and it only works with HDRP until then.
I'm waiting for it to be ready myself.
0 -
I think the last time I cracked a hash you were probably just starting your first day in security, I hope so, it's probably quite a bit longer though... I'm very old.
No doubt things are more stable now but I still question the sanity of running complex logic on the GPU. Debugging alone becomes exponentially harder.
UEBS is a unity game, why they haven't just chucked the logic into the job system I have no idea. That's exactly the sort of code it was created to run. I love it, the speed of a primitive language without most of the tedious memory management.
1 -
44 minutes ago, Quantum Blue said:
They are super sweet for 'hash cracking' and 'rainbow tables'.
You can program damn near anything you want in shader code, that wasn't my point.
Have you ever tried hash-cracking or crypto-mining _while_ rendering a high-def scene? It's the short road to a kernel panic or BSOD.
2 -
8 hours ago, SnowDog1942 said:
If you look on steam for UEBS 2, a game not out yet, one of the videos tells us that they perform AI for pathfinding for over 1 million individual on screen soldiers using the video card and would have been impossible using the CPU. I know its comparing apples to oranges but I was wondering if this was already being done or if something like this would help in 7 days to die?
You got me curious so I went and had a look. They're going to have a _lot_ of problems pulling that off. The demo's look good but without an indication of the hardware it's running on we're back to the old adage "any sufficiently prepared tech-demo is indistinguishable from magic".
They plan to run the pathfinding and physics on the GPU? What are they using to render the graphics? The CPU?
Graphics card prices are at an all-time high, no point in creating a system very few people have the ability to actually run.
They'll have issues with the basic data types. Current physics run on 32 or 64 bit numbers and already have issues with floating point accuracy. Transfering that to shader code leaves you with 16 bit numbers to play with which will only make the physics innacuracies worse.
Shader code has very little in the way of debugging tools, the system was never intended to do complex logic, findng bugs will be an absolute nightmare.
tl:dr
What they're attempting is possible but it'll be very difficult and littered with gotcha's. There are many reasons we don't run pathfinding and physics on graphics cards as a general rule and I'm sure they will have had to work through most of them 🙂
Update:
Turns out modern shader code _can_ run 32 bit numbers... assuming you have hardware that supports it. Shows how long it's been since I dug into shaders.
3 -
54 minutes ago, meganoth said:
So how do the brain stimulating devices replicate themselves and move over to the next guy bitten by a zombie? What is their energy source? I don't doubt that brain stimulating devices are possible, but I don't really see how they would explain zombies, neither Romero's nor the ones in 7D2D, without resorting to some form of magic.
Of all people I would have expected _you_ to remember their Clarkisms. 🙂
"Any sufficiently advanced technology is indistinguishable from magic"
Arthur C. Clarke
re: the post above
2 -
27 minutes ago, hiemfire said:
Gygax and his crew drew heavily from existing fables/myths so I don't doubt that they came across something that inspired those.
"Originality is only undiscovered plagiarism"
"Stealing from one source is plagiarism, stealing from several sources is research"
- Writers proverbs
🙂
3 -
58 minutes ago, hiemfire said:
Insects, like the ones that that fungus family is known to affect, have a central nervous system. A fungus of that family adapted, either via evolution or lab manipulation, to affect primates could result in what we see in game. Though isn't there a game already that is themed in a world with that type of zombie that was published by a fairly sue happy corporation?
You are indeed correct, I should have specified vertebrates as there are a few non-simian zombies in the game such as bears and vultures.
Perhaps you're thinking of the XCOM series? The early remakes had fungal zombies, as did halo with the flood infected marines.
You've got me curious as to the first instance of zombies being a fungal infestation although it's too late to do any research now. I wouldn't worry about copyright at all when it comes to this. I'm pretty sure the original version of fungal zombies will probably be in some obscure sci-fi book from the seventies or perhaps some crazy 2000AD comic from the eighties.
[disappears to confirm an ancient and dusty memory]
Dammit, the "Yellow musk creeper" and "Yellow musk zombie" from the first edition D&D "Fiend Folio" are a plant-based zombies instead of fungus based... pretty damn close though.
[closes ancient tome and slides it back amongst its brethren]
Anyone else have an early example of fungal based zombies?
0 -
26 minutes ago, Quantum Blue said:
Yes they do. But I still don't understand how you believe/knew they NEVER intended to deliberately use SI as part of their pathing 'feature'.
And I haven't been able to find anything like that in the A19 or A20 Dev Diary or EXP forums.
They have always said that Tower Defense was a part of the game. That means getting to the player. And that can be done in a number of programmatic ways which may or may not include SI.💀
Before the AI update to the current system a half-block had half the HP of a full block. The new pathfinding system required a half-block to have the same HP as a full block. Now you have a situation where a thin pillar of something is the same HP as a full cubic metre of it. Block HP is part of the SI calculation if memory serves.
Ideally a half-block should have half the HP of a full block but it was necessary to change this for pathfinding. How do I know this? I questioned the sanity of it when it was implemented and, if I remember correctly, you were here at the time.
0 -
11 minutes ago, mr.devolver said:
The virus is not capable to restore blood stream into brain to supply the brain with more oxygen and we all know that without oxygen the brain would soon die and there's no return. Nothing else would work either, the virus can't magically change how the human body works, certainly not to such extent as to modify its biological processes and what kind of chemicals it requires to function properly, so no other way would work to keep the body somewhat alive. Funny, the article which you linked to explains why what you say would be impossible, so please don't believe me, just read the article...
Okay, I'll jump on the speculative fiction bandwagon...
How about a fungus that's commonly mistaken for or referred to as a virus to due lack of knowledge or cultural bias? The hyphae would be able to create a network to pass nutrients through the body, although at a slower rate than normal blood flow. This would go a long way to explaining the slow movement, difficulty thinking, and abnormal behaviour of the zombie.
Something like Ophiocordyceps unilateralis for animals with a central nervous system.
4 -
1 hour ago, meganoth said:
So what category boss is Joss Whedon supposed to be?
A neckbeard with power it would seem. This is Gal Gadot's response to Mr Whedon's claim that she couldn't understand English enough to recognise threats and harrassment.
Neckbeards go into game development, furry's are sysadmin.
0 -
32 minutes ago, Gamida said:
I think I know which one you are referring to but to tell the truth I have had bosses over the years that could fit both of those descriptions. I have a feeling many here will have also.
This is game development, the number of Joss Whedon's per square metre is far above the average for any other industry. 🙂
0 -
27 minutes ago, Gamida said:
which is "the boss" as you said you only have to deal with one, the wife or the sprog?
One is capable of reason and compromise. The other is largely unreasonable and uncompromising due to an underdeveloped pre-frontal cortex and amygdala.
Which one of those sounds like a description of a boss? :-)
2 -
3 hours ago, Tete1805 said:
@The Gronk, you wouldn't happen to be looking for a new job? I'm sure another dev in the team wouldn't hurt.
No thank you, I'm currently enjoying my life as a house-husband raising my sprog. The hours are terrible but at least I only have to deal with one boss 🙂
4 -
9 hours ago, faatal said:
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.
A sleeping rigidbody will wake if another rigidbody gets close, otherwise they aren't calculated for collisions to save on cpu cycles. The failure of raycasts to interact with them is what leads me to believe they're asleep. I'll admit, without actually looking at the code I'm aiming in the dark here :-)
0 -
2 hours ago, faatal said:
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.
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 🙂
1 -
2 hours ago, faatal said:
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.
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.
1 -
On 1/16/2022 at 12:04 PM, Damocles said:
Do you set the CharacterControllers enabled state to false before shifting the origin? The physics engine does not like moving a CharacterController around externally when its active.
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.
0 -
6 hours ago, Burrfly said:
It's impossible to make a game where everyone likes all of it. Some people really like the new building system, while some people will prefer the current (in A19) (I personally do as well prefer the A19 building system with the wet concrete).
But it's totally okay. TFP are making a very epic game, and a lot of other cool things are coming which overal improves the game a lot (from as far as I've seen; A20 looks amazing - it's the most exciting I've been for a game (even though this is 'only' an update)).
They even interact with their player base. I've said it before but will say it again: The Fun Pimps are doing better than larger companies like Bethesda and WildCard. ARK Survival isn't even finished yet with the countless gamebreaking bugs, but WildCard only makes DLC's for money now. 7 Days to Die is more finished in alpha state than ARK Survival is in released state XD. (Although ARK can be a really great game, tho, I just hate that the devs don't focus on fixing and balancing the main game.)
So, thank you, TFP
A lot of the simplifications started to appear after TFP started using metrics to find out what the average player does. This doesn't sound like an "overall goal being steadily worked towards" and more like "knee-jerk reaction to current mechanics".
If you aim for average you will achieve it... in abundance.
1 -
7 hours ago, POCKET951 said:
As someone with almost 1000 hours in this game I liked the nuance of the system at first, but as started to build more bigger and complex bases and buildings, or if I wanted to finish upgrading a horde base before a deadline, It just became stressful and tedious and superfluous and annoying to deal with blocks that have RNG and invariable drying time. if I wanted to make a solid structure I would have to build in layers to make sure everything was reinforced concrete and it just sucks sitting there waiting for all the concrete to dry before you can move on to the next step of the project. and it isn't like you can drive away and it will dry on its own. you have to be in the area and if it's a horde base and I am waiting on concrete to dry and have nothing else to work on all I can do is wait or punch grass?
It just results in unnecessary tedious waiting and time wasting. I would much rather have a finished product quicker because my time is valuable and I have other things I want to do
My time is far more valuable, and if there making a change that gives me more time at the cost of a bit of complexity or nuance, I won't complain about it
They are also adding corner Bars/blocks which I am really happy about because it will save me alot of time making cages, instead of having to use advanced rotation and super finnicky placement of bars on the inside edge of an adjacent block to make corners in the current system.(It is tedious and it sucks)building in general will just be so much faster and more intuitive and I won't have to use as many Structural integrity gimmicks
Why not just fix the bug and retain the mechanic? Having to plan your building with plenty of time to spare is an extra pitfall to avoid late-game, adding extra difficulties should be something to add instead of remove.
0 -
2 hours ago, faatal said:
That picture covers those cases. Hard to see, but that is me placing a block on top of a plant. It would fall.
Are there plans to fix the gaping holes in SI for other blocks?
The main ones that spring to mind are horizontally stacked half-blocks and the resource pile, cement if memory serves, that has a mesh reaching half a block but still supports blocks placed above it?
It's been a bugbear of mine for a while.
0 -
8 minutes ago, Roland said:
File it as a bug report and the QA guys will let you know if it is a bug or not.
QA vets bugs for the developers. Developers don't vet bugs for QA.
Where am I posting this? The latest bug-reporting thread is surprisingly well hidden.
0 -
5 minutes ago, Matt115 said:
Well probably game just doesn't know about you base in this place , this is not a bug or feature just rng
This is the question. Should the supplies be buried within a claim block? The green bar in the background is how far the claim block extends from the central keep.
One side of the argument says that if it was buried within the untouched dirt below the farm blocks then there's a strong possbility that the character has just missed it and been unlucky.
The other side of the argument is that removing a random dirt block from a player's base can, if they're very unlucky, cause a failure in structural integrity. I lost two seedlings to this very issue while digging it out.
0
Alpha 20 Dev Diary
in News & Announcements
Posted · Edited by The Gronk (see edit history)
Grenades are a parabola until they come into contact with a surface, from there it's pretty simple newtonian physics to determine where they land. There are plenty of examples where games give you an indication of grenade trajectory before you release it and that calculation is the basis for the AI to aim.
The bad guys are often intentionally bad at aiming grenades because nothing annoys players more than when they think they're in cover and a grenade bounces off the wall behind them and lands at their feet.
The fact that you seem to think the AI is unintenionally missing indicates that the programmers have got the AI right to make it enjoyable instead of the player being killed in seconds by ricochet's and splash damage.
Many people here will have a cold shiver down their spine when I remind them of the horror that was the sniper jackals in halo 2.